This section describes the _payment API contract for getting split info of the parent transaction in the Aggregator flow.

👍
Experience the end-to-end PayU Hosted > Split Settlements flow and instantly generate the complete code for seamless, zero-coding integration into your website.

New parameter (splitRequest) merchant needs to post in the payment request.

📘
Notes:

Total aggregatorSubAmt must be equal to transaction amount posted by merchant.

Merchant key posted in split request must belong to parent key.

Transactions are not allowed on child merchant accounts or child merchant keys.

You must specify two decimal places for each split, but ensure the sum of percentage of all splits is equal to 100 or sum of split amount is equal to transaction amount.

splitRequest parameter to be included with _payment API

The splitRequest parameter must be included in the _payment API along with the regular parameters. The following are the request parameters used for split settlements:

Parameter	Description
<glossary:key> `mandatory`	`String`Merchant key provided by PayU during onboarding.
<glossary:txnid> `mandatory`	`String`The transaction ID is a reference number for a specific order that is generated by the merchant.
amount `mandatory`	`String`The payment amount for the transaction.
productinfo `mandatory`	`String`A brief description of the product.
firstname `mandatory`	`String` The first name of the customer.
email `mandatory`	`String`The email address of the customer.
phone `mandatory`	`String`The phone number of the customer.
api_version `mandatory`	`String` Version of the API as 7 for Split Settlements.
pg `mandatory`	`String` The pg parameter determines which payment tabs will be displayed on the PayU page. For cards, 'CC' will be the value.
bankcode `mandatory`	`String` Each payment option is identified with a unique bank code at PayU. The merchant must post this parameter with the corresponding payment option's bank code value in it. For more information, refer to Card Type Codes and Supported Banks for Cards.
ccnum `mandatory`	`String` Use 13-19 digit card number for credit/debit cards (15 digits for AMEX, 13-19 for Maestro) and validate with LUHN algorithm. Refer to Card Number Formats and display error message on invalid input.
ccname `mandatory`	`String` This parameter must contain the name on card – as entered by the customer for the transaction.
ccvv `mandatory`	`String` Use 3-digit CVV number for credit/debit cards and 4-digit security code (4DBC/CID) for AMEX cards. Validate with BIN API.
ccexpmon `mandatory`	`String` This parameter must contain the card's expiry month – as entered by the user for the transaction. It must always be in 2 digits or in MM format. For months 1-9, this parameter must be appended with 0 – like 01, 02…09. For months 10-12, this parameter must not be appended – It should be 10,11 and 12 respectively.
ccexpyr `mandatory`	`String` This parameter must contain the card's expiry year – as entered by the customer for the transaction. It must be of four digits.
furl `mandatory`	`String`The success URL, which is the page PayU will redirect to if the transaction is successful.
surl `mandatory`	`String`The Failure URL, which is the page PayU will redirect to if the transaction is failed.
splitRequest `mandatory for Split Settlements`	`JSON`The JSON includes the split settlement details. For more information, refer to JSON Request Structure for splitRequest parameter.
hash `mandatory`	`String`It is the hash calculated by the merchant. The hash calculation logic is: `sha512(key\|txnid\|amount\|productinfo\|firstname\|email\|udf1\|udf2\|udf3\|udf4\|udf5\|\|\|\|\|\|SALT)`
address1 `optional`	`String` The first line of the billing address. For Fraud Detection: This information is helpful when it comes to issues related to fraud detection and chargebacks. Hence, it is must to provide the correct information.
address2 `optional`	`String` The second line of the billing address.
city `optional`	`String` The city where your customer resides as part of the billing address.
state `optional`	`String` The state where your customer resides as part of the billing address,
country `optional`	`String` The country where your customer resides.
zipcode `optional`	`String` Billing address zip code is mandatory for the cardless EMI option. `Character Limit`-20
udf1 `optional`	`String` User-defined fields (udf) are used to store any information corresponding to a particular transaction. You can use up to five udfs in the post designated as udf1, udf2, udf3, udf4, udf5.
udf2 `optional`	`String` User-defined fields (udf) are used to store any information corresponding to a particular transaction. You can use up to five udfs in the post designated as udf1, udf2, udf3, udf4, udf5.
udf3 `optional`	`String` User-defined fields (udf) are used to store any information corresponding to a particular transaction.
udf4 `optional`	`String` User-defined fields (udf) are used to store any information corresponding to a particular transaction.
udf5 `optional`	`String` User-defined fields (udf) are used to store any information corresponding to a particular transaction.

JSON Request structure of splitRequest parameter

The sample JSON structure for the splitRequest field:

📘
Notes:

For the absolute type split, you must ensure that the sum of the amount of all splits is equal to the parent transaction amount.

For the percentage type split, you must ensure that the sum of the percentage of all splits is equal to 100. You can use any number of decimal places for each split, but ensure the sum of the percentage of all splits is equal to 100.

{
   "type":"<Type of split, absolute or split>",
   "splitInfo":{
      "<Child Merchant 1 key>":{
         "aggregatorSubTxnId":"<unique transaction ID for this specific sub-transaction>",
         "aggregatorSubAmt":"<amount to be transferred to this child merchant>",
         "aggregatorCharges":"<charges associated with this entity's part of the transaction to be transferred to parent (optional)>"
      },
      "<Child merchant 2 key >":{
         "aggregatorSubTxnId":"<unique transaction ID for this specific sub-transaction>",
         "aggregatorSubAmt":"<amount to be transferred to this child merchant>"
      }
   }
}

The following fields are included in the splitRequest parameter in a JSON format to specify the split details. The fields in the JSON format are described in the following table:

Field Description Example

type
mandatory

string Any of the following type of split is specified in this field.

absolute: The absolute amount is specified for each part of the split. The absolute amount is specified in the aggregatorSubAmt field of the JSON for each child or aggregator. For a sample request and response, refer to Absolute Split During Payment
percentage: The percentage of the amount is specified for each part of the split. The percentage of the amount is specified in the aggregatorSubAmt field of the JSON for each child or aggregator. For a sample request and response, refer to Split by Percentage During Payment

absolute

splitInfo
mandatory

JSON` This parameter must include the list of aggregator sub transaction IDs and sub amounts as follows:

aggregatorSubTxnId: The transaction ID of the aggregator is posted in this parameter. This field is mandatory and applicable only for child merchants.
aggregatorSubAmt: The transaction amount or percentage split for the aggregator is posted in this parameter. This field is mandatory.
aggregatorCharges: The transaction amount or percentage split for aggregator charges is posted in this parameter. This field is optional.
Note: Only the parent aggregators can have the aggregatorCharges field as part of their JSON to collect charges.

Hashing request

Added as extra parameter in the calculation of hash in case of providing Split Request at time of payment. This parameter will be at the end of the hash pattern. and required while sending Split Request at time of payment.

You need to generate a string using certain parameters and apply the SHA-512 algorithm to this string. For more information on hashing, refer to Generate Hash.

📘
Note:
Ensure that you use pipe (|) character between these parameters as mentioned in the following code block.

The parameter order is in the following code block:

sha512(key|txnid|amount|productinfo|firstname|email|udf1|udf2|udf3|udf4|udf5||||||SALT|splitRequest)

Where, splitRequest will be at the end of the hash pattern string.

Example:

hash('sha512', 'Ax4j7J|payment-txnid-1|10|Product Info|Payu-Admin|test@example.com|||||||||||t5atu4TyCvrJDPxAYrmfJfzd90kbXMfL|{"type":"absolute","splitInfo":{"P41sCY":{"aggregatorSubTxnId":"0e7411799c9f0e96620c11","aggregatorSubAmt":"3","aggregatorCharges":"2"},"P41sCK":{"aggregatorSubTxnId":"0e7411799c9f0e96620c22","aggregatorSubAmt":"5"}}}'));

Hash validation logic for payment response (Reverse hashing)

Use the following algorithm for reverse hashing the response from PayU:

sha512(SALT|status|splitInfo||||||udf5|udf4|udf3|udf2|udf1|email|firstname|productinfo|amount|txnid|key)

Example scenarios

If a Parent Merchant has two child merchants: Merchant A (Key: P****Y) and Merchant B (Key: P***K). If a customer buys two products from each of the merchants and involves the following:

Merchant A (Product Cost: 60)
Merchant B (Product Cost: 40)
Customer paid Cost: 100 on PayU Gateway.

The following cases can occur:

**Case 1:**Merchant wants the commission amount from Merchant A (Commission amount: 15) and B (Commission Amount: 10).

So In the final, Merchant wants to settle Amount: 45 to Merchant A and Amount: 30 to Merchant B and Amount: 25 to self account (parent part).

The split JSON Structure for the above scenarios is similar to the following:

{
   "type":"absolute",
   "splitInfo":{
      "P****Y":{
         "aggregatorSubTxnId":"9a70ea0155268101001ba",
         "aggregatorSubAmt":"45",
         "aggregatorCharges":"15"
      },
      "P***K":{
         "aggregatorSubTxnId":"9a70ea0155268101001bb",
         "aggregatorSubAmt":"30",
         "aggregatorCharges":"10"
      }
   }
}

Case 2: Merchant wants the commission amount from Merchant A (Commission amount: 15) and Nothing from Merchant B (Commission Amount: 0).

So, the merchant wants to settle an amount: 45 to Merchant A and amount: 40 to Merchant B and an amount: 15 to self account (parent part).

The split JSON Structure for the above scenario is similar to the following:

{
   "type":"absolute",
   "splitInfo":{
      "P****Y":{
         "aggregatorSubTxnId":"9a70ea0155268101001ba",
         "aggregatorSubAmt":"45",
         "aggregatorCharges":"15"
      },
      "P***K":{
         "aggregatorSubTxnId":"9a70ea0155268101001bb",
         "aggregatorSubAmt":"40"
      }
   }
}

Case 3: Merchant does not want any commission amount from Child Merchant A (Commission amount: 0) and B (Commission Amount: 0).

So In the final, Merchant wants to settle Amount: 60 to child merchant A and Amount: 40 to Child Merchant B and Amount: 0 to Self account (Parent Part).

The split JSON Structure for the above scenario is similar to the following:

{
   "type":"absolute",
   "splitInfo":{
      "P****Y":{
         "aggregatorSubTxnId":"9a70ea0155268101001ba",
         "aggregatorSubAmt":"60"
      },
      "P***K":{
         "aggregatorSubTxnId":"9a70ea0155268101001bb",
         "aggregatorSubAmt":"40"
      }
   }
}

Split Transaction with Only Single Child

You may choose to settle 100% for a single child. In such cases, you can pass zero (0) in the child’s key and 100% amount for others. For example, in the following JSON structure:

The amount is Rs.10 for aggregatorSubAmt.
The amount of Rs.0 (or no amount settlement) for aggregatorCharges

{
"childKey1":{
    "aggregatorSubTxnId":"txnIdForChild",
    "aggregatorSubAmt":"10",
    "aggregatorCharges":"0"
  }
}

Passing parent merchant key in the splitInfo parameter

You can pass the parent merchant key along and the child merchant key with the corresponding aggregatorSubTxnId, aggregatorSubAmt, and aggregatorCharges (can be used by only for parent merchants to collect charges) parameters in a JSON format.

Sample Request

A sample value in JSON format for the splitInfo parameter:

{
   "P41sCY":{
      "aggregatorSubTxnId":"0e7411799c9f0e96620c1",
      "aggregatorSubAmt":"3",
      "aggregatorCharges":"2"
   },
   "P41sCK":{
      "aggregatorSubTxnId":"0e7411799c9f0e96620c2",
      "aggregatorSubAmt":"5"
   }
}

📘
Refunds for Split Transactions: You must include the var8 parameter similar to the following JSON array format with the refund details of split where child_merchant_key_x must be substituted with the child merchant key. For more information, refer to Refund Transaction API > Other request parameters
{
   "child_merchant_key_1":{
      "amount":100,
      "aggregatorRefundAmount":40
   },
   "child_merchant_key_2":{
      "amount":20,
      "aggregatorRefundAmount":0
   }
}

EXAMPLE QUESTIONS