Payment Lifecycle

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.

1. Payer uses card at payee’s e-commerce site or POS terminal.

2. Fusion receives the payment request. Payment state changes to PAYMENT_REQUESTED.

3. Fusion authenticates card details like CVV, name, and expiry.

   • If the authentication is successful, state changes to PAYMENT_AUTHORIZATION_REQUESTED, and the request moves to the next stage (step 4).

   • If the authentication is unsuccessful, the payment is declined. State changes to PAYMENT_REQUEST_FAILED.

   • If the authentication fails due to system failure, payment is declined. State changes to PAYMENT_FAILED.

4. Issuer receives the request to authorize the request. Payment state changes to PAYMENT_AUTHORIZATION_RECEIVED.

5. Issuer authorizes the request. Next, payer verifies the request using OTP (e-commerce) or card PIN (POS terminal).

   • If authorization is successful, request moves to the next stage (step 6).

   • If the issuer deems the request unauthorized or the payee is unable to verify, payment is declined. State changes to PAYMENT_REQUEST_DECLINED.

   • If the authorization fails due to system failure, payment is declined. State changes to PAYMENT_FAILED.

6. A payment plan is prepared. The plan contains details of the debit and credit ledgers to be affected.

7. Fusion executes the payment plan.

   • If the plan is executed successfully, entries are posted to corresponding ledgers. State changes to PAYMENT_EFFECTED. Request moves to the next stage (step 8).

   • If Fusion fails to capture the payment due to timeout or if payer disputes the payment, Fusion initiates a reversal that nullifies the original payment. State changes to REVERSAL_INITIATED. After successful reversal, state changes to PAYMENT_REVERSED.

8. Issuer and acquirer are notified of the successful transaction. State changes to PAYMENT_CAPTURED.

The below diagram is an illustration of the above life cycle:

Payment states

The following table describes the different states of a payment lifecycle in detail:

Payment events

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 and interceptors

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