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.

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.
If the client responds with a 200 HTTP code, Decentro considers the callback acknowledged. Decentro will disregard any content in the body and solely depend on the HTTP status code.

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 using the Decentro transaction ID received from Generate payment link API, Generate Dynamic QR, or Issue Collect Request or the reference_id passed by the platform in these APIs.
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.
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. 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.