Unknown macro: {hivestonebreadcrumb}
Page tree
Skip to end of metadata
Go to start of metadata

Learn the functional concepts related to payment lifecycle. In this article, you learn about

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 State



Fusion receives the payment request. Account Holder and Accounts to be used in the payment are determined.


The payment request is invalid or Payer and/or Payee are blocked.


Payment request is submitted to the issuer configured for the payment.


Payment request is invalid. Possible reasons are:

  • Authorization was declined

  • Invalid challenge
  • Payment declined by the payer

  • Payer enters incorrect PIN, OTP
PAYMENT_FAILEDPayment authorization failed due to underlying system failure.


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.


Fusion declines the payment plan. Possible reasons are:

  • Execution of payment plan failed
  • Validation of ledger rule failed


Ledger entries successfully posted as per payment plan.


The response to the payment request is acknowledged by the issuer and acquirer.


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.


Reversal payment request is captured.

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.

On this page

Need Help?

Drop a mail at fusion-support@zeta.tech or call us on 080-6690 5995.

  • No labels