1. Home
  2. Docs
  3. Developers Guide
  4. Web Checkout
  5. Server to Server Flow
  6. Server to Server Integration

Server to Server Integration

As the name suggests, this integration is done over the server. The transaction is initiated from the merchant server hence redirection hop is eliminated. Since the details are captured on merchant page, it helps in building user confidence and enhances checkout experience.
The merchant must be PCI-DSS certified in this case. For further information on PCI-DSS certification please contact your Account Manager at PayU.

Integration Security

It is absolutely mandatory that the hash (or checksum) is computed again after you receive response from PayU and compare it with request and post back parameters. This will protect you from any tampering by the user and help in ensuring a safe and secure transaction experience. It is mandate that you secure your integration with PayU by implementing Verify webservice and Webhook/callback as a secondary confirmation of transaction response. Detailed integration process of Verify webservice and webhook and be found further in this document. 

Please ensure that sensitive information related to the integration is not part of the payment request to PayU. The details including — but not limited to — the following are considered sensitive information.

1. salt value

2. 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.

1. The last web address accessed by a browser before loading PayU’s checkout page

2. URLs shared as part of payment request to PayU in the parameter surl, furl, curl, nurl, and termUrl

3. Notification URLs configured with the merchant account

4. Invoice Completion URLs configured with the merchant account

Please note that PayU will not be responsible for any security breaches (including any data breaches) that may occur due to non-implementation of the aforesaid security features at your end or any loss or damage arising therefrom, to you or to any third party.  

Initiate Payment request from a merchant to PayU

The first request from Merchant to PayU with the required transaction mandatory/ optional parameters. This needs to be a server to server curl call request.

Test Environmenthttps://test.payu.in/
Production Environmenthttps://secure.payu.in/

Method : POST

Path : {base_url}/_payment

Parameters to be posted by Merchant to PayU in Transaction Request

There are certain parameters that are mandatory and few are optional, while one calls the Merchant Hosted Web Checkout.

Request Parameters

S.NoParameter*DescriptionData TypeExample
1.key Please use Key provided by PayU.varcharJPM7Fg
2.txnidUnique merchant transaction ID for each payment request.varchar
Character Limit – 25
3.amount This parameter should contain the payment amount of the particular transaction. float10.00
4.productinfoThis parameter should contain a brief product description.
varchar Character Limit – 100iPhone
5.firstnameMust contain the first name of the customer.varchar Character Limit – 60PayU User
6.email Must contain the email of the customer
varchar Character Limit – 50 test@gmail.com
7.phone Must contain the phone number of the customer.varchar Character Limit – 50 (numeric value only)9876543210
8.lastnameMust contain the last name of the customer.
varchar Character Limit – 20Verma
9.surlSuccess URL – URL to handle Successful payment response.varchar(URL)https://apiplayground-response.herokuapp.com/
10.furl Failure URL – URL to handle Failed payment response.varchar(URL)https://apiplayground-response.herokuapp.com/
11.curlCancel URL – URL to handle Cancel payment response.varchar(URL)www.abc1234.com
12.hash (Checksum) Hash is a crucial parameter – Please refer to Encryption logic tab under checkout.varcharec21aa240008f
User-defined field(udf)  – This parameter has been made for merchants to keep any information corresponding to the transaction, which may be useful for merchant to keep in the database. UDF1-UDF5 fields are for this purpose only. It’s completely for your usage and you can post any string value in this parameter. udf1-udf5 are optional parameters and you may use them only if needed varchar Character Limit – 255test123
14.udf2User-defined field(udf)  – This parameter has been made for merchants to keep any information corresponding to the transaction, which may be useful for merchant to keep in the database.varchar Character Limit – 255copy789
15.udf3User-defined field(udf)  – This parameter has been made for merchants to keep any information corresponding to the transaction, which may be useful for merchant to keep in the database.varchar Character Limit – 255check789
16.udf4User-defined field(udf)  – This parameter has been made for merchants to keep any information corresponding to the transaction, which may be useful for merchant to keep in the database.varchar Character Limit – 255pass12345
17.udf5User-defined field(udf)  – This parameter has been made for merchants to keep any information corresponding to the transaction, which may be useful for merchant to keep in the databasevarchar Character Limit – 25501234
18.txn_s2s_flow Please pass its value as 4                                                            
19.pgThis parameter signifies the payment option that you want the customer to redirect to from merchant checkout. It works in combination with bankcode and redirects to exact bank/issuer page.
Please set its value to ‘NB’ for Net Banking , ‘CC’ for Credit Card , ‘DC’ for Debit Card , ‘CASH’ for wallets ‘EMI’ for EMI and “UPI” for UPI option
20.bankcode  Each payment option is identified with a unique bank code at PayU. You would need to post this parameter with the corresponding payment option’s bankcode value in it.
For example, for ICICI Net Banking, the value of bankcode parameter value should be ICIB. For detailed list of bank codes, please contact PayU team
21.ccnumThis parameter must contain the card (credit/debit) number entered by the customer for the transaction.int5123456789012346
22.ccnameThis parameter must contain the name on card – as entered by the customer for the transaction.stringAshish
23.ccvvThis parameter must contain the cvv number of the card – as entered by the customer for the transaction.int123
This parameter must contain the card’s expiry month – as entered by the customer for the transaction. Please make sure that this is always in 2 digits.int05
25.ccexpyrThe customer must contain the card’s expiry year – as entered by the customer for the transaction. It must be of 4 digits.int2022
26.   s2s_client_ip This parameter must have the source IP of the user string66.15.149.87
27.   s2s_device_info  This parameter must have the user agent of device stringMozilla

Run Request in Real Time:

In API playground , select category Server to Server and run the request for the flow you wish to.

Below page will appear to try it in real time.

Curl 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=GDRf6lH2sx8c73&amount=10&firstname=PayU User&email=test@gmail.com&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=ec21aa240008ff8d71e5c75c253c5cb59707229840d1494d61b0e0881b8f150188d616c9cbb4d43bce8dcfa248b5e772d45bb47a573196132a8401d232c31478"

Initiate payment response from PayU to Merchant

It would be an S2S call response.

  • If there is an error in request processed, below error will be sent to merchant: {“result”:null,”status”:”failed”,”error”:”E1616″,”message”:”Non-seamless not allowed in S2S Flow”}
  • If the request is correctly processed, then a curl response will be sent back to merchant.
S.No Parameter Description  
1.  post_data  base64 encoded HTML page which needs to be pushed on user’s browser, it will auto submit to bank’s page.
2.post_uri Bank URL where data needs to be posted to, by the merchant

post_data is a base64 encoded string. The merchant needs to decodepost_data, which is an HTML form with auto-submit, which then needs to be shown on the customer’s browser. The HTML being auto-submit will take the customer to the bank page for required credentials.

Example of base 64 encoded and its decoded response:

Response (Example):

eyJzdGF0dXMiOiJzdWNjZXNzIiwicmVzdWx0Ijp7Im1paHBheWlkIjoiNzAwMDEwMDA0MzY2MDEiLCJtb2RlIjoiREMiLCJzdGF0dXMiOiJmYWlsdXJlIiwia2V5Ijoib2ZTeTFEIiwidHhuaWQiOiJjMGUyZTA4ZDc1MTNmNjlkY2M1OSIsImFtb3VudCI6IjEuMjAiLCJhZGRlZG9uIjoiMjAxNy0wMi0yMSAxODozMTozNCIsInByb2R1Y3RpbmZvIjoiUHJvZHVjdCBJbmZvIiwiZmlyc3RuYW1lIjoiUGF5dS1BZG1pbiIsImxhc3RuYW1lIjoiIiwiYWRkcmVzczEiOiIiLCJhZGRyZXNzMiI6IiIsImNpdHkiOiIiLCJzdGF0ZSI6IiIsImNvdW50cnkiOiIiLCJ6aXBjb2RlIjoiIiwiZW1haWwiOiJ0ZXN0QGV4YW1wbGUuY29tIiwicGhvbmUiOiIxMjM0NTY3ODkwIiwidWRmMSI6IiIsInVkZjIiOiIiLCJ1ZGYzIjoiIiwidWRmNCI6IiIsInVkZjUiOiIiLCJ1ZGY2IjoiIiwidWRmNyI6IiIsInVkZjgiOiIiLCJ1ZGY5IjoiIiwidWRmMTAiOiIiLCJjYXJkX3Rva2VuIjoiIiwiY2FyZF9ubyI6IjQ1OTE1MFhYWFhYWDUyNzkiLCJmaWVsZDAiOiIiLCJmaWVsZDEiOiIxMTcwMjIxOTQwMzI0NjgiLCJmaWVsZDIiOiIiLCJmaWVsZDMiOiIiLCJmaWVsZDQiOiIiLCJmaWVsZDUiOiIyIiwiZmllbGQ2IjoiQXV0aGVudGljYXRpb24gZmFpbGVkLlRyYW5zYWN0aW9uIGNhbm5vdCBiZSBhdXRob3JpemVkIiwiZmllbGQ3IjoiRW1wdHkgdmFsdWUgcmVjZWl2ZWQsIHZhbHVlcyBhcmUgcnJuID0gLHRyYW5zX2lkID0gMTE3MDIyMTk0MDMyNDY4LGF1dGhfY29kID0gIiwiZmllbGQ4IjoiIiwiZmllbGQ5IjoiQXV0aGVudGljYXRpb24gZmFpbGVkLlRyYW5zYWN0aW9uIGNhbm5vdCBiZSBhdXRob3JpemVkIiwicGF5bWVudF9zb3VyY2UiOiJwYXl1IiwiUEdfVFlQRSI6IlNCSVBHIiwiZXJyb3IiOiJFMzAzIiwiZXJyb3JfTWVzc2FnZSI6IkNhcmQgYXV0aGVudGljYXRpb24gZmFpbHVyZSIsIm5ldF9hbW91bnRfZGViaXQiOiIwIiwidW5tYXBwZWRzdGF0dXMiOiJmYWlsZWQiLCJoYXNoIjoiMjAzZTgxMTVlM2FmNGZlN2UyMDEyNDlkNmZiZDA5MzU4YzBlNTA1ODgxZGMxODI2ZDk0ZDAzODczMTk3ZDFkZjQ1OTUzMGE5NGI5ZWZiNWQyMWZmZjI4MWI0MWEwMzA0YTcxNjY3MjExM2Ez MTY2M2FlMGViMThmYzM4Njg5ODciLCJiYW5rX3JlZl9ubyI6IiIsImJhbmtfcmVmX251bSI6IiIsImJhbmtjb2RlIjoiVklTQSIsInN1cmwiOiJodHRwczpcL1wvYWRtaW4ucGF5dS5pblwvdGVzdF9yZXNwb25zZSIsImN1cmwiOiJodHRwczpcL1wvYWRtaW4ucGF5dS5pblwvdGVzdF9yZXNwb25zZSIsImZ1cmwiOiJodHRwczpcL1wvYWRtaW4ucGF5dS5pblwvdGVzdF9yZXNwb25zZSIsImNhcmRfaGFzaCI6ImYzNmM3NDhkNjRhZmUxODNiYzNiNWQwOTJlNDI1MjA5ZDk3MGUxNmM3NmIzMzBiODEzNDc3YWQzNWQ1NTlhN2YifX0=

Decoded response below (Example):

<html><body><form name="payment_post" id="payment_post" action="http:// axisnetbanking.com" method="post"><input type="hidden" name="RU" value="https:// 	 zomato.com/resulthandling?payu_response=aHR0cHM6Ly9zZWN1cmUucGF5dS5pbi9BWElTX05CX1JFU1BPTlNFLnBocA==&reference=1e281da1d50a5ae1d3217570d3761dcf81db4e7c2c6c60f0ef60 	1df5f8647202"><input type="hidden" name="qs" value="PRN~12d457876d30e900a9e0$PID~000000002438$MD~P$ITC~70000000097771$CRN~I 	 NR$AMT~10.00$RESPONSE~AUTO$CG~Y"></form><script type='text/javascript'>

Transaction response from PayU to Merchant

Once the customer is redirected to bank’s page where customer authentication is done, bank gives back the redirect response to PayU and PayU gives the final transaction response to merchant via a redirect.

Below parameters will be sent in this response. The merchant must refer to the ‘status’ parameter mentioned in the table below for processing/ discarding the order.

Please verify amount and txnid parameters at your end in response from PayU.

Sr.NoVariable NameDescription
1mihpayidIt is a unique reference number created for each transaction at PayU’s end.
2modeThis parameter describes the payment category by which the transaction was completed/attempted by the customer. The values are mentioned below:
Example : CC for credit card, DC for debit card, etc. Mode labels can be found in Payment options tab.
3bankcodeThis parameter would contain the code indicating the payment option used for the transaction. For example, Visa Debit Card – VISA, Master Debit Card – MAST.
4statusThis parameter gives the status of the transaction. Hence, the value of this parameter depends on whether the transaction was successful or not. You must map the order status using this parameter only. The values are as below:
Possible values : success, failure, pending
5unmappedstatusThis parameter contains the status of a transaction as per the internal database of PayU. PayU’s system has several intermediate status which are used for tracking various activities internal to the system. Hence, this status contains intermediate states of a transaction also – and hence is known as unmappedstatus. For example: dropped/bounced/captured/auth/failed/usercancelled/pending
6txnidUnique merchant transaction ID sent in request.
7amountThis parameter would contain the original amount which was sent in the transaction request by the merchant.
8productinfoThis parameter would contain the same value of productinfo which was sent in the transaction request from merchant’s end to PayU
9firstnameThis parameter would contain the same value of firstname which was sent in the transaction request from merchant’s end to PayU
10lastnameThis parameter would contain the same value of lastname which was sent in the transaction request from merchant’s end to PayU
11emailThis parameter would contain the same value of email which was sent in the transaction request from merchant’s end to PayU
12phoneThis parameter would contain the same value of phone which was sent in the transaction request from merchant’s end to PayU
This parameter would contain the same value of udf1 which was sent in the transaction request from merchant’s end to PayU
14hashThis parameter is absolutely crucial and is similar to the hash parameter used in the transaction request. Please refer to encryption logic tab under checkout.
15errorFor the failed transactions, this parameter provides the reason of failure.
16PG_TYPEThis parameter gives information on the payment gateway used for the transaction. For example, if SBI PG was used, it would contain the value SBIPG.
17bank_ref_numFor each successful transaction – this parameter would contain the bank reference number generated by the bank.