post https://test.payu.in/merchant/postservice.php
predebit
The Pre-Debit Notification API allows the merchants to send a pre-debit notification to the customer regarding an upcoming payment which will be deducted from the customer’s account as part of the registration. There is a mandate to send this notification to the customer at least 48 hours before the actual debit, that is, 48 hours before calling the Recurring API.
Reminder
- Check the mandate status before calling the Pre-Debit Notification API.
- Unless the Pre-Debit notification API is implemented, the Recurring Payment Transaction API will not work, and you will not be able to charge the customer for the given billing cycle.
- Pre-Debit notification is necessary only for Cards and UPI and works for only these two payment modes
Environment
| Production Environment | https://info.payu.in/merchant/ |
| Test Environment | https://test.payu.in/merchant/ |
Sample request
curl --location --request POST 'https://test.info.payu.in/merchant/postservice.php?form=2' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data
'key=JF****g&hash=9f5faabedb7f5d41f519db3a223cf5318ecc0b7e669f49e0a699d4c4879e1ccaed5b99f5cd
8be4f2cbddefe5272ec983abd8f38480d9c2609a29447f750a3158&command=check_action_status_txnid&var
1=7043873219"
Sample response
Successful sceanario
{
"status": 1,
"action": "MANDATE_PRE_DEBIT",
"message": "Request Processed Successfully",
“invoiceId”:” ADDA049409”
}
Failure Scenarios
- Mandate is active in PayU DB and Pre-Debit gets declined from Bank/NPCI
{
"status": “QC” ----- >> Bank/NPCI Error Code
"action": "MANDATE_PRE_DEBIT",
"message": “MANDATE HAS BEEN REVOKED”. ---- >> Description against error code
}
Where, the message parameter in the response will display error code according to the scenario
- Mandate is already Paused/ Revoked in PayU DB
{
"status": 0,
"action": "MANDATE_PRE_DEBIT",
"message": "Mandate is not active” --- >> Description will change based on Scenario
}
Where, the message parameter in the response will display according to the scenario.
Response parameters
| Parameter Name | Description |
|---|---|
| status | Status defines acknowledgment from PayU. Possible values are : · 1- This value indicates that pre-debit notification is triggered successfully for customer or deleted successfully in case of action delete. · 0 – This value indicates pre-debit notification failed to get triggered and merchant should retry after some time to trigger the same or failed to get deleted in case of action delete. |
| action | Always returned as “MANDATE_PRE_DEBIT” to highlight the type of action. |
| message | Description of the pre-debit notification process |
invoiceIdonly for cards | This is an acknowledgment ID that a pre debit notification has been sent for processing. |
invoiceStatusonly for cards | This is the status of the invoice whether it has been charged for recurring or not. Values can be: - Paid - Unpaid - DeletedSince these statuses come from a third-party vendor, so these can vary if there is an addition of new status at the vendor end |
approvedStatusonly for cards | This is for cases where the transaction is above 15000 as RBI guideline says approval is required through AFA (Additional Factor authentication). Values can be: - Pending - Approved - Not_applicable Since these statuses come from third-party vendors, so these can vary if there is an addition of new status at the vendor end. |
Request parameters
Reference information
| Parameter | Reference |
|---|---|
| key | For more information on how to generate the Key and Salt, refer to any of the following: - Production: Generate Merchant Key and Salt - Test: Generate Test Merchant Key and Salt |
| hash | Hash logic for this API is:sha512(key|command|var1|salt)
sha512 |
Response Parameters var1 JSON fields description
Additional information
| Parameter Name | Description |
|---|---|
| status | Status defines acknowledgment from PayU. Possible values are : 1- This value indicates that pre-debit notification is triggered successfully for customer or deleted successfully in case of action delete. · 0 – This value indicates pre-debit notification failed to get triggered and merchant should retry after some time to trigger the same or failed to get deleted in case of action delete. |
| action | Always returned as “MANDATE_PRE_DEBIT” to highlight the type of action. |
| message | Description of the pre-debit notification process |
| invoiceId | This is an acknowledgment ID that a pre debit notification has been sent for processing. |
| invoiceStatus | This is the status of the invoice whether it has been charged for recurring or not. Values can be: - Paid - Unpaid - Deleted Since these statuses come from a third-party vendor, so these can vary if there is an addition of new status at the vendor end |
| approvedStatus | This is for cases where the transaction is above 15000 as RBI guideline says approval is required through AFA (Additional Factor authentication) Values can be.: - Pending - Approved - Not_applicable Since these statuses come from third-party vendors, so these can vary if there is an addition of new status at the vendor end. |
var1 JSON fields description
The var1 variable is in JSON format and comprises of the following parameters:
| JSON Field | Description |
|---|---|
| authpayuid mandatory | The value of mihpayid returned in the payment response of Registration transaction when transaction is successfully completed. As explained earlier in the document, you need to map this value against customer profile at his end so that correct authPayuid will be passed in the request. |
| requestId mandatory | Unique request value generated at merchant’s end to distinguish independent request call. |
| debitDate mandatory for cards and UPI | This parameter contains the date of debit when the recurring would be charged by merchant. *In UPI:** - For all frequencies (other than Daily and Adhoc), the merchant must send the notification 48 hours before the debit. - For Daily and Adhoc frequency, the merchant must send the notification 24 hours before the debit. If the notification is sent after these durations, then the debit will fail. |
| invoiceDisplayNumber mandatory only for cards | A unique display number by merchant for every subsequent invoice/recurring charge. This can be displayed on the merchant’s panel to the customer. This same value needs to be sent in the recurring api also. |
| amount mandatory for cards and UPI | The transaction amount which will be deducted from the customer’s payment instrument. For Cards: - In case of Fixed billing plan, this amount should be same as billingAmount sent during Registration transaction. - In case of Adhoc billing plan, this amount should be equal to or lesser than billingAmount sent during the Registration transaction. *Note: The amount mentioned in the Pre-Debit notification API for UPI should be same as the next execution amount. Else, the next recurring execution request will fail. |
| action optional | Any of the following actions can be performed: * Retrieve: Query the status of the pre-debit notification. Only authpayuid and invoice display numbers are mandatory for this action. * Delete: Delete the already generated pre debit. Only authpayuid and invoice display numbers are mandatory for this action. |
Use the following sample values while trying out the API:
Example values for fields in var1:
authPayuId: 10731087875requestId: 23123abut12123osd14debitDate: 2020-03-20amount: 100