Generate Hash

A hash is an encrypted value (checksum) that is sent by you in a payment request and reverted by PayU in the payment response. The hash is used to protect transactions against a “man-in-the-middle-attack.” ##

Hash Generation Logic for Payment Request

PayU uses the SHA-512 hash function that belongs to the SHA-2 family of cryptographic functions to generate hash values.

Mandatory Parameters

You need to generate a string using certain mandatory parameters and apply the SHA-512 algorithm to this string.

📘

Note:

Ensure that you use pipe (|) character between these parameters as mentioned in the following code block.

The code sample below demonstrates the exact order of the parameters that must be followed when using the hash function:

sha512(key|txnid|amount|productinfo|firstname|email|udf1|udf2|udf3|udf4|udf5||||||SALT)

For more information on the parameters (and their descriptions) mentioned in the above code block, refer to Collect Payment API - PayU Hosted Checkout.

The following parameters are mandatory to compute Hash:

• Salt
• key
• txnid
• amount
• productinfo
• firstname
• email

The udf parameters (udf1-udf5) are optional, and you need to calculate the hash based on whether you are posting a particular udf or not. For example, if you are not posting udf1 in the payment request, the udf1 field must be left empty in the hash calculation.

🚧

Salt Security

Salt is a susceptible information. Do not pass Salt in the payment request. To know more about generating salt, see Generate Merchant Key and Salt on PayU Dashboard.

Sample code for Hash algorithm

\$output = hash ("sha512", \$text);

📘

Reference:

or the sample code in .NET, refer to Microsoft Documentation > SHA512 Class.

Hashing scenarios for payment request

Here, we will discuss some payment request scenarios and see how hash calculation varies for each of them:

• Scenario 1: When all the udf parameters (udf1-udf5) are posted by the merchant, hash is calculated as:

sha512(key|txnid|amount|productinfo|firstname|email|udf1|udf2|udf3|udf4|udf5||||||SALT)

• Scenario 2: If only some of the udf parameters are posted . For example, if udf2 and udf4 are posted and udf1, udf3, udf5 are not, hash is calculated as:

sha512(key|txnid|amount|productinfo|firstname|email||udf2||udf4|||||||SALT)

• Scenario 3: If none of the udf parameters (udf1-udf5) are posted, hash is calculated as:

sha512(key|txnid|amount|productinfo|firstname|email|||||||||||SALT)

How Hash values are computed?

Let us assume that you are posting the following parameters and their corresponding values in the payment request:

For the parameters mentioned above, the hash generation string will look like:

sha512(C****m|12345|1000|Shopping|Vinay|[email protected]|||||||||||3********s*****k********h*****j)

Now, we will hash the above mentioned string using SHA-512 message-digest algorithm to get the following hash value:

ffcdbf04fa5beefdcc2dd476c18bc410f02b3968e7f4f54e8f43f1e1a310bb32e3b4dec9305232bb89db5b1d0c009a53bcace6f4bd8ec2f695baf3d43ba730ce

You need to post this hash value (along with other parameters) in the payment request to PayU as shown in the table below:

After the request is received, PayU will take the parameters sent in the request to generate the hash string and use the SHA-512 message-digest algorithm to regenerate the hash value. If the hash value generated at PayU end matches with the one sent by the merchant, the transaction is authenticated, or else it is dropped and displayed as a hash mismatch error on the merchant side.

📘

Note:

You can use the Hash API of the PayU node SDK on Github to perform hashing. Refer to the PayU node SDK Readme, download and install the PayU node SDK from the PayU node SDK Github location.

📘

Quick Tips:

1. In the test environment (payu.test.in), PayU displays the error message and the correct action required to resolve the error.
2. However, in the live environment, to retain the confidentiality of the business information, PayU displays only an error message and drops the transaction.
3. It has been observed that a majority of the hash mismatch errors result from an incorrect key insert by the merchant’s developers while generating the hash value. For instance:

Inserting Merchant ID (MID) instead of Merchant Key	sha512(411112345110001 Shopping I Vinay I [email protected] I 3****s*k****h*j)
Inserting SALT instead of Merchant Key & Merchant ID in place of SALT	sha512(3****s*k****h*[email protected] |411)

In these cases, while PayU will compile the hash value with the right positioning of the merchant key and salt in the string, it will be different from the one posted by the merchant for apparent reasons, leading to a mismatch.

4. PayU advises against sending the salt value as part of the payment request package, as it severely compromises the security of the transaction. Because, with access to the salt, a malicious actor executing a man-in-the-middle (MITM) attack can easily alter the details, regenerate the hash value, and can pass the same through the authentication filters in the PayU’s servers.

Hash Validation Logic for Payment Response (Reverse Hashing)

While sending the response, PayU takes the exact same parameters that were sent in the request (in reverse order) to calculate the hash and returns it to you. You must verify the hash and then mark a transaction as a success or failure. This is to make sure the transaction has not tampered within the response.

The order of the parameters is similar to the following code block:

sha512(SALT|status||||||udf5|udf4|udf3|udf2|udf1|email|firstname|productinfo|amount|txnid|key)

Note: You can use the Hash API of the PayU node SDK on Github to perform reverse hashing. Refer to the PayU node SDK Readme, download and install the PayU node SDK from the PayU node SDK Github location.

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 Transaction Detail APIs and Webhooks.

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.