🔄 Status Lifecycle

About Payment Statuses

Every payment in our system transitions through a series of statuses that represent its lifecycle — from creation and authorization to settlement, refund, or chargeback.

Understanding these statuses is essential to:
✅ interpret transaction behavior
⚙️ automate decisions on your platform
🔍 and provide full transparency to payers and merchants.

🔄 Status Overview

Status	Description
`issued`	The payment was created and is awaiting authorization.
`pending`	The transaction is under review, usually waiting for the completion of a 3DS authentication challenge before confirmation.
`confirmed`	The transaction was successfully authorized and is ready for settlement or post-processing.
`paid`	The payment was successfully settled and funds have been transferred.
`refunded`	The payment was refunded to the cardholder.
`refund_error`	A refund attempt was denied by the provider. The system will automatically retry the refund the following day until it succeeds.
`pre_chargeback_resolution`	A proactive refund was issued through the chargeback prevention program before becoming a formal chargeback.
`chargeback_requested`	The cardholder disputed the transaction; it’s under issuer review.
`chargeback_refunded`	The chargeback was accepted and funds returned to the cardholder.
`canceled`	The transaction was manually canceled before confirmation, or the 3DS challenge expired automatically.
`error`	The transaction failed during authorization or due to provider-related issues.

⚠️
Important
Any change in the charge status is automatically sent via webhook.
Ensure your endpoint is correctly configured to receive updates.

📘 See more details in the Webhook Reference.

🧭 Terminal States

Statuses such as refunded, chargeback_refunded, canceled, and error represent the end of a transaction’s lifecycle — no further updates occur after these points.

🕸️ Visual Flow

Below is a diagram illustrating how each status connects within the payment lifecycle.

stateDiagram-v2
    direction TB

    state fork <<choice>>
    [*] --> fork

    fork --> issued: Payment Created
    fork --> cancelled: Cancelled Early

    issued: "issued"
    confirmed: "Confirmed"
    paid: "Paid"
    refunded: "Refunded"
    refund_error: "Refund Error"
    pre_chargeback_resolution: "Pre-Chargeback Resolution"
    chargeback_requested: "Chargeback Requested"
    chargeback_refunded: "Chargeback Refunded"
    error: "Error"
    cancelled: "Cancelled"

    issued --> confirmed: Authorization Success
    issued --> error: Authorization Failed
    issued --> cancelled: Manual Cancellation

    confirmed --> paid: Settlement
    confirmed --> refunded: Refund
    confirmed --> refund_error: Refund Attempt Failed
    confirmed --> chargeback_requested: Dispute Opened
    confirmed --> pre_chargeback_resolution: Preventive Refund

    paid --> refunded: Post-payment Refund
    paid --> chargeback_requested: Chargeback
    chargeback_requested --> chargeback_refunded: Dispute Closed

    confirmed --> [*]
    paid --> [*]
    refunded --> [*]
    refund_error --> [*]
    error --> [*]
    cancelled --> [*]
    chargeback_refunded --> [*]

    %% Notes
    note right of issued
        Payment created, awaiting authorization.
    end note
    note right of confirmed
        Authorized successfully, pending capture or settlement.
    end note
    note right of paid
        Funds transferred to the merchant.
    end note
    note right of refunded
        Amount returned to the cardholder.
    end note
    note right of refund_error
        Refund attempt failed — will retry automatically.
    end note
    note right of pre_chargeback_resolution
        Preventive refund before formal chargeback.
    end note
    note right of chargeback_requested
        Transaction under dispute by cardholder.
    end note
    note right of chargeback_refunded
        Dispute resolved — funds returned.
    end note
    note left of error
        Authorization or provider failure.
    end note
    note left of cancelled
        Transaction canceled before confirmation.
    end note

    %% Style
    classDef success fill:#d3f9d8,stroke:#2f9e44,stroke-width:3px,font-size:16px
    classDef danger fill:#ffe3e3,stroke:#c92a2a,stroke-width:3px,font-size:16px
    classDef warning fill:#fff3bf,stroke:#f08c00,stroke-width:3px,font-size:16px
    classDef info fill:#d0ebff,stroke:#1971c2,stroke-width:2px

    class confirmed,paid,refunded success;
    class refund_error,chargeback_requested,chargeback_refunded,pre_chargeback_resolution warning;
    class error,cancelled danger;
    class issued,fork info;

✅ Key Takeaways

Each status reflects a real-time update in the transaction lifecycle.
All updates are sent through webhooks — always listen for them.
Some statuses (like refund_error) will trigger automatic retries.

💡
Tip:
Implement webhook handling logic to synchronize your database and trigger notifications automatically whenever a charge status changes.

Updated 29 days ago