All successful registration transactions are charged over the recurring interface with server-to-server API without any additional 2FA or the customers’ involvement. This section describes how to achieve the Recurring Transaction for Net Banking, Cards, and UPI through the common platform.
Notes:
- Banks do not support refunds for Net Banking Recurring Payment transactions (or e-NACH transaction) so you will get an error message, “Refund not accepted for txn” or Error 232. For the list of banks supporting e-NACH, refer to Recurring Payments Bank Codes.
- Check the mandate status, call the Pre-Debit Notification API before calling the Recurring Payment Transaction API to make a recurring payment transaction.
Assumptions:
If the merchant has already performed a successful registration transaction with Net Banking/UPI/Card and mihpayid is received in response to the registration transaction captured successfully and mapped to the customer at the merchant’s end.
Environment
| Production Environment | <https://info.payu.in/merchant/> |
| Test Environment | <https://test.payu.in/merchant/> |
Sample request
curl -X POST "https://test.payu.in/merchant/postservice?form=2" -H "accept: application/json" -H "Content-Type: application/x-www-form-urlencoded" -d "key=JP***g&command=si_transaction&var1={\"authpayuid\": \"6611192557\",\"invoiceDisplayNumber\":\"12345678910\",\"amount\": 3,\"txnid\": \"REC15113506209\",\"phone\": \"9999999999\",\"email\": \"[email protected]\",\"udf2\": \"\",\"udf3\": \"\",\"udf4\": \"\",\"udf5\": \"\"}&hash=jbUS07Og8BToVZ"Sample response
Success scenario
Here is a sample response object returned against recurring payment API when the transaction is successfully charged.
{
"status": 1,
"message": "Transaction Processed successfully",
"details": {
"REC15113506209": {
"transactionid": "REC15113506209",
"amount": "3",
"payuid": "6611427463",
"status": "captured",
"field9": "Transaction Completed Successfully",
"phone": "9999999999",
"email": "[email protected]",
"udf2": "",
"udf3": "",
"udf4": "",
"udf5": ""
}
}
} Failure scenarios
- Invalid hash
{
"status": 0,
"msg": "Invalid Hash."
}- Basic authentication check failed
{
"status": 1,
"message": "Transaction Processed successfully",
"details": {
"REC9812123123": {
"authpayuid": "6611192559",
"transactionid": "REC9812123123",
"amount": "1",
"user_credentials": " ",
"card_token": " ",
"payuid": "",
"status": "failed",
"field9": "Basic authentication check failed",
"phone": "",
"email": ""
}
}
}Response parameters
JSON fields description of the Details parameter
| JSON Field | Description |
|---|---|
| transactionid | This field contains the value of transaction ID parameter which is echoed back in the response. This is unique transaction ID generated by merchant during calling recurring API. |
| amount | This field contains the requested transaction amount is echoed back in the payment response. |
| payuid | This field contains the PayU’s transaction ID for processed recurring transaction. Merchant can use this field for reference point in the settlement report. |
| status | This field gives the status of the transaction. Hence, the value of this field depends on whether the transaction was successful or not. |
| field9 | This field returns the description of transaction status which can help the merchant in providing better customer communication. |
| phone | The mobile number of the customer echoed back. |
| Email ID of the customer echoed back. | |
| udf1 | Extra information received in the request echoed back. |
| udf2 | Extra information received in the request echoed back. |
| udf3 | Extra information received in the request echoed back. |
| udf4 | Extra information received in the request echoed back. |
| udf5 | Extra information received in the request echoed back. |
status field description
This field gives the status of the transaction. Hence, the value of this field depends on whether the transaction was successful or not.
You must map the order status using this parameter only. The possible values of this parameter are:
- captured: If the transaction is successful, the value will be captured. In some cases, the response of Net banking recurring can be captured over real-time basis (ICICI bank in the specific scenario).
- pending: This is common with most Net Banking (except ICICI in the specific scenario) or UPI recurring transaction. In that case, the merchant should consider this as successful initiation of payment with bank / NPCI. The status will be notified back to the merchant over payment processing with individual bank gets completed.
For UPI, “pending” transactions get usually get converted into captured or failed within 10 mins from the time of initiation. The Query API can be called post 10 mins from initiation, whereas for Net Banking, it can be called up to T+2 once a day. For more information, refer to Capture response of Recurring Transaction.
For Net Banking, “pending” transaction gets converted into “captured” or “failed” from the same day till T+2 anytime, depending upon the bank account used by the customer in setting up registration. - failed: The value of the status as “failed” or blank must be treated as a failed transaction only.
- in-progress: The status of transaction is in progress.
To capture the final status of “pending” transaction to either “captured” or “failed”, PayU recommends merchants to either implement Webhook URL or call verify_payment API after regular intervals. For more information on:
- Webhook: Refer to Webhooks
- verify_payment API: Refer to Verify Payment API
Note:
For UPI, call the verify_settlement API after 10 mins from time of initiation whereas for Net Banking it can be called up to T+2 once in a day.
Request parameters
Reference information
| Parameter | Reference |
|---|---|
<<glossary:key>> |
For more information on how to generate the Key and Salt, refer to any of the following:
|
<<glossary:hash>> |
Hash logic for this API is: |
var1 |
For JSON fields description, refer to Additional Info. for Recurring Payment APIs |