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.
Payer uses card at payee’s e-commerce site or POS terminal.
Fusion receives the payment request. Payment state changes to
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
If the authentication fails due to system failure, payment is declined. State changes to
Issuer receives the request to authorize the request. Payment state changes to
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
If the authorization fails due to system failure, payment is declined. State changes to
A payment plan is prepared. The plan contains details of the debit and credit ledgers to be affected.
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
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:
The following table describes the different states of a payment lifecycle in detail:
|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||Fusion receives the payment request. Account Holder and Accounts to be used in the payment are determined.|
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.|
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
FAQs related to the payment APIs
List of webhooks to subscribe to & receive event notification
Create Accounts, manage Bundles, view transactions
A tool for developers to try out card transactions
A step-by-step walkthrough to set up Shared spends product
Card API Error Codes
List of error codes specific to Card APIs
Order new cards, change PIN, get payment details