Hash Generation Logic For Payment Request
A hash is an encrypted value (checksum) that is to be sent by the merchant in a payment request and sent by PayU in the payment response. The hash is used to protect transactions against “man in the middle attack”.
PayU uses the SHA-512 hash function which belongs to SHA-2 family of cryptographic functions.
You need to generate a string using certain parameters and apply the sha512 algorithm to this string.
Please note that you have to use pipe (|) character in between these parameters as mentioned below.
The parameter order is mentioned below:
All these parameters (and their descriptions) have already been mentioned earlier in the hosted checkout integration document.
Here, SALT (to be provided by PayU), key, txnid, amount, productinfo, firstname, email are mandatory parameters and hence can’t be empty in the hash calculation above. But, udf1-udf5 are optional and hence you need to calculate the hash based upon the fact that whether you are posting a particular udf or not. For example, if you are NOT posting udf1. Then, in the hash calculation, udf1 field will be left empty.
Note:-Salt is very sensitive info. Please don’t pass in the payment request.
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 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.
Following examples will clarify various scenarios of hash calculation:
Case 1: If all the udf parameters (udf1-udf5) are posted by the merchant. Then, hash is calculated as:
Case 2: If only some of the udf parameters are posted and others are not. For example, if udf2 and udf4 are posted and udf1, udf3, udf5 are not.In this case, hash is calculated as:
Case 3: If NONE of the udf parameters (udf1-udf5) are posted. Then,hash is calculated as:
For Example: If key=C0Dr8m, txnid=12345, amount=10, productinfo=Shopping, firstname=Test, firstname.lastname@example.org, udf2=abc, udf4=15, SALT=3sf0jURk and udf1, udf3, udf5 are not posted.
Then, hash would be calculated as Case 2 above:
(This value comes out to be ffcdbf04fa5beefdcc2dd476c18bc410f02b3968e7f4f54e8f43f1e1a310bb32e3b4dec9305232bb89db5b1d0c009a53bcace6f4bd8ec2f695baf3d43ba730ce)
Hash Generation Logic for Payment Response
PayU calculates the hash using a string of parameters and returns it to the merchant in the response. The merchant must verify the hash and then only mark a transaction as success/failure. This is to make sure the transaction has not tampered.
The calculation is as below:
This time the variables are in reverse order and status variable is added between salt and udf1.
The handling of udf1 – udf5 parameters remains similar to the hash calculation when the merchant sends it in the transaction request to PayU. If any of the udf (udf1-udf5) was posted in the transaction request, it must be taken in hash calculation also. If none of the udf parameters were posted in the transaction request, they should be left empty in the hash calculation too.
It is strongly recommended that merchant should verify the parameters posted by PayU in response with the parameter sent by merchant in request. This will identify any of the parameters have been tampered in response. Parameters such as transaction ID and amount needs to be verified with the values sent in request by the merchant.