This callback is used by Decentro to trigger the status of a transaction to pre-configured endpoint of the platform.
Overview
This callback allows the platform to proactively receive a transaction's status without having to check it from their end, thus reducing the computational burden and making it more efficient to propagate the status to the payer.
This callback allows a platform to receive the status of a transaction undertaken through any of the flows below.
- Generate Payment Link API
- Generate Dynamic QR
- Virtual accounts
- Issue Collect Request
The platform can share the endpoint for configuring this callback before going live at [email protected].
Points to Note
Key points to note.
- This callback isn't triggered in case of a static QR code-based or push transaction.
- This callback is triggered 3 times per transaction
- This callback only propagates the transaction status
- This callback is triggered when a transaction status moves to one of SUCCESS, FAILURE, EXPIRED.
Flow
Below is the flow for using the callback capability as part of Decentro
- The platform consumes this callback to get the latest status of an initiated transaction from Generate payment link API, Generate Dynamic QR, Issue Collect Request or virtual accounts
- In this callback, Decentro relays the transaction status via the transaction_status field and the transaction details. The default status will always be 'PENDING' unless the payer authorizes a payment.
- The platform can map the transaction type at its end using the collection_type parameter triggered as part of the callback payload.
- The platform acknowledges the callback by responding to it with 'CB_S00000' from its end. If any other value is passed, Decentro shall retrigger the callback.
- If the platform cannot acknowledge the callback or handle the same at its end, the transaction status can also be fetched using Get Transaction Status in case of a UPI transaction.
- If the platform wants to know the updated balance of the ledger account, it can receive it using the Account Balance Callback/Webhook.
- The platform can handle the reason a transaction failed using the 'error_key' field in the callback, as mentioned in the Error Key section.
Error Keys
Decentro intimates the platform about the error leg i,e where the error has occurred in the transaction using the 'error_key' in the callback payload if it is a UPI transaction. Please note that error keys are for the platform's use, and standalone is not recommended for end-user messaging.
Below are the values propagated by Decentro, as well as the associated interpretation.
| Error Key | Description |
|---|---|
| error_at_remitter_bank | The transaction failed due to an issue at the payer's bank, such as limits breached, an account frozen, etc. |
| error_at_beneficiary_bank | The transaction failed due to an issue at the Decentro's bank partner's end. |
| error_at_payer_psp | The transaction failed due to an issue at payer PSP, i.e., the UPI app used by the payer to authorize the transaction. |
| error_at_payee_psp | The transaction failed due to payee PSP, i.e., Decentro's partner bank's end. |
| error_at_npci | The transaction failed due to an issue at the NPCI level |
Simulation Data
Overview
Decentro's simulation data helps developers simulate all the real-world scenarios using the Payment Link API.
This requires the platform to use standard request payloads to handle scenarios for each API and scenario, as mentioned below.
The platform must whitelist its IP and configure callback endpoints with Decentro if it wishes to handle the flow. Please reach out to us at [email protected] for the same.
Flow
Decentro triggers the transaction status callback to the endpoints configured by Decentro as per the platform's requests. The callback for the testbed will mirror the fields in the documentation but will have the data as passed by the platform in any of the below APIs.