EFTNET (NEFT/RTGS) Integration
Collect payments using EFTNET (NEFT/RTGS) with Merchant Hosted Checkout integration as described in this section. After collecting the details from the customer, make the transaction request with the payment details to PayU.
To integrate with EFTNET:
Steps to Integrate
1. Initiate the Payment to PayU
Initiate the payment to PayU with pg= NEFTRTGS and bankcode= <based on the bank>
2. Check response from PayU
Check the response from PayU
3. Verify the payment
Verify the payment using verify_payment and monitor using webhooks
Before you begin:Register for an account with PayU before you start integration. For more information, refer to Register for a Merchant Account.
Step 1: Initiate the payment to PayU
Post request syntax & composition
<body>
<form action='https://test.payu.in/_payment' method='post'>
<input type="hidden" name="key" value="JP***g" />
<input type="hidden" name="txnid" value="t6svtqtjRdl34W" />
<input type="hidden" name="productinfo" value="iPhone" />
<input type="hidden" name="amount" value="10" />
<input type="hidden" name="email" value="[email protected]" />
<input type="hidden" name="firstname" value="Ashish" />
<input type="hidden" name="lastname" value="Kumar" />
<input type="hidden" name="pg" value="NEFTRTGS" />
<input type="hidden" name="bankcode" value="EFTAXIS" />
<input type="hidden" name="surl" value="your own success url" />
<input type="hidden" name="furl" value="your own failure url" />
<input type="hidden" name="phone" value="9988776655" />
<input type="hidden" name="hash" value="eabec285da28fd0e3054d41a4d24fe9f7599c9d0b66646f7a9984303fd6124044b6206daf831e9a8bda28a6200d318293a13d6c193109b60bd4b4f8b09c90972" />
<input type="submit" value="submit"> </form>
</body>
</html>Note: The sample HTML code mentioned above is for Merchant Checkout integration with the NEFT/RTGS payment method call for the test environment.
Optional configuration for challan
PayU provides an optional Back to Merchant button on the payment challan of a NEFT/RTGS payment. This button enables your customer to go back to the merchant portal once the transaction is done.
In this scenario, if a customer clicks on Back to Merchant button the merchant will receive the response on the furl shared in the Collect Payment API - Merchant Hosted Checkout.
Sample challan of a NEFT/RTGS transaction
Request parameters
The following parameters vary for the EFTNEFT payment mode in the Collect PaymentAPI (_payment API).
Environment
| Test Environment | https://test.payu.in/_payment |
| Production Environment | https://secure.payu.in/_payment |
| Parameter | Description | Example |
|---|---|---|
key mandatory | String - This parameter is the unique merchant key provided by PayU for your merchant account. For more information, refer to Generate Merchant Key and Salt. | 8488225 |
txnid mandatory | varchar - This parameter is known as Transaction ID (or OrderID). It is the order reference number generated at your (Merchant's) end. It is an identifier which you(merchant) would use to track a particular order. If a transaction using a particular transaction ID has already been successful at PayU, the usage of same Transaction ID again would fail. Hence, it is essential that you post us a unique transaction ID for every new transaction. | fd3e847h2 |
amount mandatory | float - This parameter should contain the payment amount of the particular transaction. Note: Type-cast the amount to float type | 10 |
productinfo mandatory | varchar - This parameter should contain a brief product description. It should be a string describing the product (The description type is entirely your choice). | T-shirt |
firstname mandatory | varchar - This parameter must contain the first name of the customer. | Ankit |
email mandatory | varchar - This parameter must contain the email of the customer | [email protected] |
phone mandatory | integer - Merchant needs to take the customer's GPay registered phone number and pass in this field. This field will be used for further mapping the customer VPA and initiate a collect request. | 9876543210 |
pg mandatory | string - The payment gateway is specified in this parameter. For EFTNET, specify NEFTRTGS. | NEFTRTGS |
bankcode mandatory | string - Each payment option is identified with a unique bank code at PayU. | EFTAXIS |
surl mandatory | The "surl" field is the success URL, which is the page PayU will redirect to if the transaction is successful. The merchant can handle the response at this URL after the customer is redirected there. | https://apiplayground-response.herokuapp.com/ |
furl mandatory | The "furl" field is the Failure URL, which is the page PayU will redirect to if the transaction is failed. The merchant can handle the response at this URL after the customer is redirected there. | https://apiplayground-response.herokuapp.com/ |
hash mandatory | string - The hash calculated by the merchant using the key and salt provided by PayU. The format for calculating the hash: sha512(key|txnid|amount|productinfo|firstname|email|udf1|udf2|udf3|udf4|udf5|||||SALT) For more information, refer to Generate Hash. | calculated_hash_value |
lastname optional | string - The last name of the customer. | Kumar |
address1 optional | string - The first line of the billing address. | 123 Main St |
address2 optional | string - The second line of the billing address. | Apt 4B |
city optional | string - The city where your customer resides as part of the billing address. | Mumbai |
state optional | string - The state where your customer resides as part of the billing address. | Maharashtra |
country optional | string - The country where your customer resides. | India |
zipcode optional | string - Billing address zip code is mandatory for the cardless EMI option. | 400001 |
udf1 optional | string - This parameter has been made for you to keep any information corresponding to the transaction. | custom_data_1 |
udf2 optional | string - This parameter has been made for you to keep any information corresponding to the transaction. | custom_data_2 |
udf3 optional | string - This parameter has been made for you to keep any information corresponding to the transaction. | custom_data_3 |
udf4 optional | string - This parameter has been made for you to keep any information corresponding to the transaction. | custom_data_4 |
udf5 optional | string - This parameter has been made for you to keep any information corresponding to the transaction. | custom_data_5 |
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=J****g&txnid=aI1UM19ONxLgPz&amount=10.00&firstname=Ashish&[email protected]&phone=9876543210&productinfo=iPhone&pg=NEFTRTGS&bankcode=EFTAXIS&surl=https://apiplayground-response.herokuapp.com/&furl=https://apiplayground-response.herokuapp.com/&hash=6840ba0d1a14554f7ee5d20966dfbac6b221718e72dd823f05b6da01420286315b4956c28325898b66520b111604020ea2c547608606674766eb7e4164dc0baa"Step 2: Check response from PayU
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 on Response: For security reasons, the sample response or URL is not included here.
Step 3: Verify the payment
Upon receiving the response, we recommend performing a reconciliation step to validate all transaction details.
You can verify your payments using either of the following methods:
Configure the webhooks to monitor the status of payments.
Webhooks enable a server to communicate with another server by sending an HTTP callback or message.
These callbacks are triggered by specific events or instances and operate at the server-to-server (S2S) level.
👉 For more details, refer to Webhooks for Payments.
Updated 8 days ago