1. Home
  2. Docs
  3. Developers Guide
  4. Web Checkout
  5. PayU Hosted Checkout
  6. Prebuilt Checkout Integration

Prebuilt Checkout Integration

The Integration Process

  1. To start off the integration process, you would be provided a test setup by PayU where you would be given a test merchant account and test credit card credentials to have a first-hand experience of the overall transaction flow. Here, you need to make the transaction request on our test server (and not the production server). Once your testing is complete, then only you will be ready to move to the PayU production server.
  2. In the merchant-initiated POST REQUEST, one of the mandatory parameters is named as hash. The details of this hash parameter have been covered in the later section. But it is absolutely critical for the merchant to calculate the hash correctly and post it to us in the request. Find more about the hash generation process.
  3. A new transaction entry is created in the PayU Database. A unique identifier is created every time at PayU’s end to identify each original transaction in the PayU Database. This identifier is known as the PayU ID (or MihPayID).
  4. The user can select the particular payment option on PayU’s page (Credit Card/Debit Card/Net Banking etc.). When the ‘Pay Now’ button is clicked, PayU redirects the user to the chosen bank.
  5. The user goes through the necessary authorization/authentication process at the bank’s login page, and the bank gives the success/failure response back to PayU.
  6. PayU marks the transaction status based on the response received from the bank. PayU provides the final transaction response string to the merchant through a POST RESPONSE.
  7. A hash generated by PayU also accompanies the POST RESPONSE. The merchant needs to verify the authenticity of the hash value before accepting/rejecting the invoice order.
  8. The merchant can verify the transaction details from the dashboard

Note: To ensure rapid and successful integration, PayU offers a series of integration kits. The merchants can download the latest resource for their web builder plugin or base language from here.

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.  

Base URLs

Environment{base_url}
Sandboxhttps://test.payu.in
Productionhttps://secure.payu.in

Method – POST

PATH – {base_url}/_payment

Request Headers

accept (mandatory)application/json
Content-Type (mandatory)application/x-www-form-urlencoded

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 PayU Hosted Web Checkout.

Mandatory Request Parameters

S.NoParameter* Description Data TypeExample
1. key

The merchant key is provided by PayU and acts as a unique identifier for a specific merchant account in the PayU’s database.

varcharJPM7Fg
2. txnid Transaction ID is the order reference number generated by the merchant to track a particular order. It can be used only once and PayU’s system does not accept a duplicate Transaction ID. varchar, Character Limit – 25PQI6MqpYrjEefU
3. amount It should contain the payment amount of the particular transaction. float/int10.53/10
4.productinfo It should be a string containing a brief description of the product. The description type is entirely merchant’s choice.varchar, Character Limit – 100iPhone
5. firstname The first name of the customer.varchar, Character Limit – 60PayU User
6. email The email of the customer.
This information is helpful when it comes to issues related to fraud detection and chargebacks. Hence, it is must to provide the correct information
varchar, Character Limit – 50,test@gmail.com
7. phone The phone number of the customer.
This information is helpful when it comes to issues related to fraud detection and chargebacks. Hence, it is must to provide the correct information
numeric value only 9876543210
8.surlSuccess URL(surl) – It must contain the URL on which PayU will redirect the final response if the transaction is successful. The response handling can then be done at merchant’s end after redirection to this URL.varchar (URL)https://apiplayground-response.herokuapp.com/
9.furlFailure URL(furl) – It must contain the URL on which PayU will redirect the final response in case of failure. The response handling
can then be done at merchant’s end after redirection to this URL.
varchar (URL)https://apiplayground-response.herokuapp.com/
10. hash It is used to avoid the possibility of transaction tampering. Click here to know more about the hash generation process. varcharccc029894dcc03a164f2
81b7a64596a19785e8a
61ae81d008ef482e153
4a99a67eee346d3cbf9
ffcf1ce63b0e2faee26f2
e4a20e6aef471c25b42
4c33971bb41

Note: In PayU hosted Web Checkout, the payment option details for net banking or card transactions need not be passed on to PayU since the user is redirected to the PayU’s secured environment to execute the payment transaction.

Optional Request Parameters

These are extra parameters that can be passed in the request depending on the use case.

Optional Request Parameters

S.No Parameter Description Data TypeExample
1.

address1

The first line of the billing address. It is
mandatory for the cardless EMI option.
This will be used for billing address.
Varchar, Character Limit – 100, Characters allowed: A to Z, a to z, 0 to 9, @, -(Minus),
_(Underscore),
/ (Backslash), (Space),
. (Dot)
H.No- 17, Block C, Kalyan Bldg, Khardilkar Road, Mumbai
2.address2 The second line of the billing address. Varchar, Character Limit – 100, Characters allowed: A to Z, a to z, 0 to 9, @, -(Minus),
_(Underscore), / (Backslash), (Space), . (Dot)
34 Saikripa-Estate, Tilak Nagar
3. city Billing address city is mandatory for the cardless EMI option. Varchar, Character Limit – 100, Characters allowed: A to Z, a to z, 0 to 9, @, -(Minus),
_(Underscore), / (Backslash), (Space),
. (Dot)
Mumbai
4. state Billing address state is mandatory for the cardless EMI option. Varchar, Character Limit – 100, Characters allowed: A to Z, a to z, 0 to 9, @, -(Minus),
_(Underscore), / (Backslash), (Space),
. (Dot)
Maharashtra
5.

country

Billing address country is mandatory for the cardless EMI option. Varchar, Character Limit – 100, Characters allowed: A to Z, a to z, 0 to 9, @, -(Minus),
_(Underscore), / (Backslash), (Space),
. (Dot)
India
6. zipcode Billing address zip code is mandatory for the cardless EMI option. Varchar, Character Limit – 100, Characters allowed: A to Z, a to z, 0 to 9, @, -(Minus),
_(Underscore), / (Backslash), (Space),
. (Dot)
400004
7. udf1User-defined fields(udf) are used to store any information corresponding to a particular transaction. Merchants can use up to 5 udfs in the post designated as udf1, udf2, udf3, udf4, udf5. Data type – Varchar, Character Limit – 255test123
8.udf2User-defined fields(udf) are used to store any information corresponding to a particular transaction,
which may be useful for you to keep in the database.
Data type – Varchar, Character Limit – 255copy789
9.udf3User-defined fields(udf) are used to store any information corresponding to a particular transaction,
which may be useful for you to keep in the database.
Data type – Varchar, Character Limit – 255check789
10.udf4User-defined fields(udf) are used to store any information corresponding to a particular transaction. Data type – Varchar, Character Limit – 255pass12345
11udf5User-defined fields(udf) are used to store any information corresponding to a particular transaction. Data type – Varchar, Character Limit – 25501234
12. curlCancel URL(curl) – It must contain the URL on which PayU will redirect the final response if the transaction is cancelled by the user. The response handling can then be done at merchant’s end after redirection to this URL. varchar (URL)www.abc1234.com
13.

pg

This parameter defines the payment option that the merchant wants the user to see by default on the PayU’s payment page. If this field is empty, the system assumes the Credit Card payment option by default.
Example: if pg= ’NB’ then after redirection to PayU’s payment page, the Net Banking option would be opened by default.
NB for NetBanking tab,
CC for Credit Card tab,
DC for Debit Card tab, CASH for Cash Card tab and EMI for EMI tab
DC
14lastnameLast name of the customer.
Only alphabets a-z are allowed.
varchar, Character Limit – 20Verma

POST Request Syntax & Composition

Here is a sample request that the merchant needs to send to PayU.

Please note that we have incorporated only the mandatory variables in the following code block:

<html>

 

<body>
    <form action='https://test.payu.in/_payment' method='post'>
        <input type="hidden" name="key" value="JP***g" />
        <input type="hidden" name="txnid" value="PQI6MqpYrjEefU" />
        <input type="hidden" name="productinfo" value="iPhone" />
        <input type="hidden" name="amount" value="10.00" />
        <input type="hidden" name="email" value="test@gmail.com" />
        <input type="hidden" name="firstname" value="PayU User" />
        <input type="hidden" name="surl" value="https://www.acme.com/getSuccess" />
        <input type="hidden" name="furl" value="https://www.acme.com/getFailure" />
        <input type="hidden" name="phone" value="9876543210" />
        <input type="hidden" name="hash" value="ccc029894dcc03a164f281b7a64596a19785e8a61ae81d008ef482e1534a99a67eee346d3cbf9ffcf1ce63b0e2faee26f2e4a20e6aef471c25b424c33971bb41" />
        <input type="submit" value="submit">
    </form>
</body>

 

</html>

Run Request in Real Time:

In API playground , select category PayU Hosted and run the request.

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=PQI6MqpYrjEefU&amount=10.00&firstname=PayU User&email=test@gmail.com&phone=9876543210&productinfo=iPhone&surl=https://apiplayground-response.herokuapp.com/&furl=https://apiplayground-response.herokuapp.com/&hash=05a397501918ec5c36ae52daa3b3e49b43e986b86940e109d060076e467c3ea7536617df7420e0e6863dced8c5b45f9fff15c13bdf0335512c05f0210b31b072"

Success Response

Below is the response body for a Success Status. Read more about different error codes

{
  "mihpayid": "403993715522785532",
  "mode": "CC",
  "status": "success",
  "unmappedstatus": "captured",
  "key": "JPM7Fg",
  "txnid": "PQI6MqpYrjEefU",
  "amount": "10.00",
  "cardCategory": "domestic",
  "discount": "0.00",
  "net_amount_debit": "10",
  "addedon": "2021-03-15 02:15:36",
  "productinfo": "iPhone",
  "firstname": "PayU User",
  "address1": "",
  "address2": "",
  "city": "",
  "state": "",
  "country": "",
  "zipcode": "",
  "email": "test@gmail.com",
  "phone": "9876543210",
  "udf1": "",
  "udf2": "",
  "udf3": "",
  "udf4": "",
  "udf5": "",
  "udf6": "",
  "udf7": "",
  "udf8": "",
  "udf9": "",
  "udf10": "",
  "hash": "9037e61182de145d70da266ac445c8ad6634ed268a4e364e58e5f1802cd942f608ea85c98f5b6a7d159bdf1e1f3966bed04610b9f1a36e69b9c5559ff576f32d",
  "field1": "",
  "field2": "",
  "field3": "",
  "field4": "",
  "field5": "",
  "field6": "",
  "field7": "",
  "field8": "",
  "field9": "Transaction Completed Successfully",
  "payment_source": "payu",
  "PG_TYPE": "CC-PG",
  "bank_ref_num": "1d0b3604-5203-49a1-9eab-dd163d12cbd0",
  "bankcode": "CC",
  "error": "E000",
  "error_Message": "No Error",
  "name_on_card": "test",
  "cardnum": "512345XXXXXX2346",
  "cardhash": "This field is no longer supported in postback params."
}

Response Parameters

Response Parameters posted by PayU to Merchant after payment activity.

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

Understanding Response Body

S.NoParameterDescription
1.mihpayidIt is a unique reference number created for each transaction at PayU’s end. Please save this transaction id at your end because this will be used as a reference for all the future actions on this transaction like Inquiry or Refund.
2.modeThis parameter describes the payment category by which the transaction was completed/attempted by the customer. The values are mentioned below:
Category used by Customer – Value of Mode Parameter
Credit Card – CC
Debit Card – DC
NetBanking – NB
Cash Card – CASH
EMI – EMI
IVR – IVR
Cash On Delivery – COD
Cardless EMI – CLEMI
3.bankcodeThis parameter would contain the code indicating the payment option used for the transaction. For example, Visa Debit Card – VISA, Master Debit Card – MAST.
4.statusThis 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
If the value of ‘status’ parameter is ’success’, the transaction is successful.
If the value of ‘status’ is ‘failure’ or ‘pending’, must be treated as a failed transaction only.
5.unmappedstatusThis parameter contains the status of a transaction as per the internal database of PayU. PayU’s system has several intermediate status which is 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.
Possible values:
dropped/ bounced/ captured/ auth/ failed/ usercancelled/ pending.
Read here for status description
6.errorFor the failed transactions, this parameter provides the reason for failure.
7.bank_ref_numFor each successful transaction – this parameter would contain the bank reference number generated by the bank.
8.txnidThis parameter would contain the transaction ID value posted by the merchant during the transaction request.
9.amountThis parameter would contain the original amount which was sent in the transaction request by the merchant.
10.productinfoThis parameter would contain the same value of productinfo which was sent in the transaction request from merchant’s end to PayU.
11.firstnameThis parameter would contain the same value of firstname which was sent in the transaction request from the merchant’s end to PayU.
12.emailThis parameter would contain the same value of email which was sent in the transaction request from the merchant’s end to PayU.
13.phoneThis parameter would contain the same value of phone which was sent in the transaction request from the merchant’s end to PayU.
14.hashThis parameter is absolutely crucial and is similar to the hash parameter used in the transaction request. Please refer to encryption logic.
15.PG_TYPEThis parameter gives information on the payment gateway used for the transaction.
16.udf1This parameter would contain the same value of udf1 which was sent in the transaction request from the merchant’s end to PayU.
17. udf2This parameter would contain the same value of udf2 which was sent in the transaction request from the merchant’s end to PayU.
18.udf3This parameter would contain the same value of udf3 which was sent in the transaction request from the merchant’s end to PayU.
19. udf4This parameter would contain the same value of udf4 which was sent in the transaction request from the merchant’s end to PayU.
20.udf5This parameter would contain the same value of udf5 which was sent in the transaction request from the merchant’s end to PayU.