Split During Transaction using _payment

API command: _payment

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

Environment

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:

ParameterDescription
key
mandatory
StringMerchant key provided by PayU during onboarding.
txnid
mandatory
StringThe transaction ID is a reference number for a specific order that is generated by the merchant.
amount mandatoryStringThe payment amount for the transaction.
productinfo mandatoryStringA brief description of the product.
firstname mandatoryString The first name of the customer.
email
mandatory
StringThe email address of the customer.
phone
mandatory
StringThe phone number of the customer.
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 mandatoryString 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 mandatoryString 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 mandatoryString 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
StringThe success URL, which is the page PayU will redirect to if the transaction is successful.
surl
mandatory
StringThe Failure URL, which is the page PayU will redirect to if the transaction is failed.
splitRequest
mandatory for Split Settlements
JSONThe JSON includes the split settlement details. For more information, refer to JSON Request Structure for splitRequest parameter.
hash
mandatory
StringIt 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:

FieldDescriptionExample
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|[email protected]|||||||||||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
   }
}