General Integration
The Server-to-Server integration is performed at the server level, that is, your server (merchant server) and PayU server. The transaction is initiated from your server; hence redirection hop is eliminated. Since the details are captured on your page, customers gain confidence and enhance the checkout experience.
Note:
You must be PCI-DSS certified to use Server-to-Server integration. For more information on PCI-DSS certification, contact your Account Manager at PayU.
Before you begin:
Register for a account with PayU before you start integration. For more information, refer to Register for a Merchant Account.
Integration security
After receiving a response from PayU, you must calculate the hash again and validate it against the hash that you sent in the request to ensure the transaction is secure. PayU recommends implementing the transaction details APIs and webhook/callback as an extra security measure. You can find more information on this process in the <a href="transaction-detail-apis="_blank"> Transaction Detail APIs and <a href="webhooks="_blank">Webhooks documentation.
You need to ensure that sensitive information related to the integration is not part of the payment request to PayU. The details including β but are not limited to β the following are considered sensitive information:
- Salt value
- plain text hash string
Along with the request, the sensitive information should not be a part of any merchant-level URL. The following are considered sources for the merchant-level URL:
- The last web address accessed by a browser before loading PayUβs checkout page.
- URLs shared as part of payment request to PayU in the parameters: surl, furl, curl, nurl, and termUrl.
- Notification URLs configured with the merchant account.
- Invoice Completion URLs configured with the merchant account.
Note:
It is important to compare the parameters sent by PayU in the response with the ones you sent in the request to make sure none of them have been changed. You should verify specific parameters such as the transaction ID and amount. PayU is not responsible for any security breaches or losses resulting from your failure to implement the necessary security measures.
Step 1: Post the parameters to PayU
The first request from you to PayU with the required transaction mandatory/ optional parameters. This needs to be a server-to-server Curl call request. For the sample request and response, refer to Collect Payment - General Integration.
Environment
Test Environment | https://test.payu.in/_payment |
Production Environment | https://secure.payu.in/_payment |
Request parameters
Parameter | Description | Example |
---|---|---|
keymandatory | String Merchant key provided by PayU during onboarding. | |
txnidmandatory | 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. | Ashish |
emailmandatory | String The email address of the customer. | |
phonemandatory | String The phone number of the customer. | |
pgmandatory | String The pg parameter determines which payment tabs will be displayed on the PayU page. For cards, 'CC' will be the value. | CC |
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. | AMEX |
ccnummandatory | 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. | 5123456789012346 |
ccname mandatory | String This parameter must contain the name on card β as entered by the customer for the transaction. | Ashish Kumar |
ccvvmandatory | String Use 3-digit CVV number for credit/debit cards and 4-digit security code (4DBC/CID) for AMEX cards. Validate with BIN API. | 123 |
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. | 10 |
ccexpyrmandatory | String This parameter must contain the cardβs expiry year β as entered by the customer for the transaction. It must be of four digits. | 2021 |
furlmandatory | String The success URL, which is the page PayU will redirect to if the transaction is successful. | |
surlmandatory | String The Failure URL, which is the page PayU will redirect to if the transaction is failed. | |
hashmandatory | 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) | |
txn_s2s_flowmandatory | String This parameter must be passed with the value as:- 4 for Legacy Decoupled flow. - 3 for Direct Authorization. | |
address1optional | 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. | |
address2optional | String The second line of the billing address. | |
cityoptional | String The city where your customer resides as part of the billing address. | |
stateoptional | String The state where your customer resides as part of the billing address, | |
countryoptional | String The country where your customer resides. | |
zipcodeoptional | String Billing address zip code is mandatory for the cardless EMI option.Character Limit -20 | |
udf1optional | 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. | |
udf2optional | 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. | |
udf3optional | String User-defined fields (udf) are used to store any information corresponding to a particular transaction. | |
udf4optional | String User-defined fields (udf) are used to store any information corresponding to a particular transaction. | |
udf5optional | String User-defined fields (udf) are used to store any information corresponding to a particular transaction. |
Hashing
You must hash the request parameters using the following hash logic:
sha512(key|txnid|amount|productinfo|firstname|email|udf1|udf2|udf3|udf4|udf5||||||SALT)
For more information, refer to Generate Hash.
Sample request
curl -X POST "https://test.payu.in/_payment
-H "accept: application/json" -H "Content-Type: application/x-www-form-urlencoded" -d
"key=JP***g&txnid=tJA4IWme0jIsDw&amount=10.00&firstname=PayU User&[email protected]&phone=9876543210&productinfo=iPhone&pg=cc&bankcode=cc&surl=https://apiplayground-response.herokuapp.com/&furl=https://apiplayground-response.herokuapp.com/&ccnum=5123456789012346&ccexpmon=05&ccexpyr=2022&ccvv=123&ccname=&txn_s2s_flow=4&hash=36b4ab309154a9cbc0a0b9829c086a196cb2edd758b1e918cf7f20fbc1f596f17cc4ba5682eee32317365c99e8b461692595328eea7bb9c6e689bc4b923abe81"
Step 2: Check response from PayU
Sample response
{
"metaData": {
"message": null,
"referenceId": "2710cd2a20e08a006034861feea27f084a425e94920df9b1856eb6e90793067b",
"statusCode": "E000",
"txnId": "payuTestTransaction2909041",
"unmappedStatus": "captured"
},
"result": {
"mihpayid": "412345678912362515",
"mode": "CC",
"status": "success",
"key": "J****g",
"txnid": "payuTestTransaction2909041",
"amount": "100",
"addedon": "2020-06-09 16:54:26",
"productinfo": "Product Info",
"firstname": "Postman",
"lastname": "",
"address1": "",
"address2": "",
"city": "",
"state": "",
"country": "",
"zipcode": "",
"email": "[email protected]",
"phone": "9123456781",
"udf1": "",
"udf2": "",
"udf3": "",
"udf4": "",
"udf5": "",
"udf6": "",
"udf7": "",
"udf8": "",
"udf9": "",
"udf10": "",
"card_no": "XXXXXXXXXXXX2346",
"field0": "",
"field1": "",
"field2": "",
"field3": "",
"field4": "",
"field5": "NW9WYkV0dzJCclpsMWNRbzg0VVk=",
"field6": "02",
"field7": "AUTHPOSITIVE",
"field8": "",
"field9": "Successful Transaction",
"payment_source": "payuPureS2SAuth",
"PG_TYPE": "CC-PG",
"error": "E000",
"error_Message": "Success",
"unmappedstatus": "captured",
"hash": "df540d8fc8265e9382415993e468cfe0884574ddc617b96053082195752e11e4405888bb96030e749be780805dcf8499241a3c51fb26f978cdb6d328cda2a138",
"bank_ref_num": "",
"bankcode": "CC"
}
}
Next Steps
Response Parameters
Note:
The response contains a combination of the following JSON objects (metaData, result, and binData) based on the use case used in S2S, and the fields in each of them are described in the following tables.
Collect the response in the Collect Payment API - Server-to-Server under API Reference. The response for the S2S payment request is not similar to Merchant Hosted or PayU Hosted Checkout. For description of response parameters, refer to Additional Info for Payment APIs.
Updated about 1 month ago