Learn the functional concepts related to payment lifecycle. In this article, you learn about
In most real-life cases, a payment request is triggered by a Push payment—when payer uses their card at merchant's e-commerce site or POS terminal. Various parties like acquirer, issuer, and card network communicate with each other to process the request. The request moves to different stages as a result of this processing. Fusion uses states to track the progress of the request. A typical payment lifecycle consists of the following stages and associated states:
For a detailed explanation on payment states, see Payment states. |
PAYMENT_REQUESTED
. PAYMENT_AUTHORIZATION_REQUESTED,
and the request moves to the next stage (step 4). PAYMENT_REQUEST_FAILED
. PAYMENT_FAILED
.PAYMENT_AUTHORIZATION_RECEIVED
.PAYMENT_REQUEST_DECLINED
.PAYMENT_FAILED
.PAYMENT_EFFECTED
. Request moves to the next stage (step 8). REVERSAL_INITIATED
. After successful reversal, state changes to PAYMENT_REVERSED
.PAYMENT_CAPTURED
.The below diagram is an illustration of the above life cycle:
The following table describes the different states of a payment lifecycle in detail:
Payment State | Description |
PAYMENT_REQUESTED | Fusion receives the payment request. Account Holder and Accounts to be used in the payment are determined. |
PAYMENT_REQUEST_FAILED | The payment request is invalid or Payer and/or Payee are blocked. |
PAYMENT_AUTHORIZATION_REQUESTED | Payment request is submitted to the issuer configured for the payment. |
PAYMENT_REQUEST_DECLINED | Payment request is invalid. Possible reasons are:
|
PAYMENT_FAILED | Payment authorization failed due to underlying system failure. |
PAYMENT_AUTHORIZATION_RECEIVED | Payment request is received by the issuer for authorization. A payment plan for the payment is prepared. The plan contains details of the debit and credit ledgers to be affected. |
PAYMENT_DECLINED | Fusion declines the payment plan. Possible reasons are:
|
PAYMENT_EFFECTED | Ledger entries successfully posted as per payment plan. |
PAYMENT_CAPTURED | The response to the payment request is acknowledged by the issuer and acquirer. |
REVERSAL_INITIATED | Fusion nullifies the original payment request and initiates a reversal. This can happen if a payment capture fails due to timeout or if the payer raises a purchase dispute. |
PAYMENT_REVERSED | Reversal payment request is captured. |
Through the course of a payment request's lifecycle, it passes through various stages. Fusion triggers various events at each stage. You can use these events to gather crucial information regarding the payment request or configure your application to perform operations according to your business workflow . For more information, see Fusion Events.
Payment webhooks are HTTPS endpoints that allow you to subscribe to various events that take place in a payment's lifecycle. Real-time notifications are sent to your application which can be used to take necessary action. For more information, see About Webhooks.
Payment interceptors are similar to webhooks, with the added functionality of returning a response. Using interceptors, you can intercept a payment request, use your internal decision engines, and then notify Fusion to allow or disallow the payment. For more information, see About Interceptors.
|