> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/payment-methods/cards/payment-statuses.md). # Payment Statuses Every card payment moves through a defined lifecycle. The payment status – not the customer’s browser – is your source of truth for what to do next. The SEB Ecommerce Payment Gateway returns the current status of every payment throughout its lifecycle – in API responses, via callback notifications, and in the Merchant Portal. Use the payment status to drive your order processing: it tells you when to fulfil, when to wait, and when to let the customer try again. {% hint style="info" %} Always rely on callback notifications or the payment status returned by the gateway. Do not rely solely on the customer’s browser returning to your website – the browser may never return even when the payment succeeds, and may return before the final status is known. {% endhint %} This page describes the status lifecycle for card payments, including digital wallet payments processed through the card networks (Apple Pay, Google Pay, Click to Pay). Pay by Bank payments use a simplified account-to-account lifecycle – see [Pay by Bank › Payment Statuses](/payment-methods/pay-by-bank/payment-statuses.md). ### Status Lifecycle A card payment progresses through the following stages: *Initialized → Authorized → Captured → Settled ( → Refunded )* *Failed, Cancelled, and Abandoned are final statuses that can end the lifecycle before completion.* Which path a payment takes depends on the processing model: a Purchase (single-step) payment moves from Initialized directly to Captured, while an Authorization + Capture (two-step) payment passes through Authorized first. See Supported Operations for the processing models. ### Statuses

Status	Description	Final?	Recommended Merchant Action
Initialized	A new payment has been created, but no payment method has been completed yet – the customer is selecting a payment method or completing checkout and authentication.	No	Keep the order pending. Wait for the next status notification. Do not fulfil.
Authorized	The payment amount has been reserved on the customer’s account (pre-authorization). To complete the payment, it must be finalized by capturing the final amount.	No	Reserve inventory. Capture when you are ready to collect the funds – or reverse if the order is cancelled.
Captured	The customer has paid and the funds have been captured, but they have not yet been transferred to your account. For card payments, this is the “paid” status.	No	Proceed with order fulfilment. Store the payment reference for reconciliation.
Settled	A final status: the payment has been fully completed and the funds have been transferred to your account.	Yes	No action – use for financial reconciliation.
Failed	A final status: the payment could not be completed due to technical issues, issuer declines, or other errors.	Yes	Inform the customer with a clear message and allow another payment attempt or payment method.
Cancelled	A final status: the payment was cancelled before settlement – by the customer, by you, or via an authorization reversal.	Yes	Return the customer to checkout or close the order. Release any reserved inventory.
Abandoned	A final status: the payment was initiated, but no payment method was ever completed – the customer did not select a method or left the flow before finishing.	Yes	Treat as not paid. Create a new payment if the customer wishes to continue – do not reuse the payment.
Refunded	The payment has been partially or fully refunded after being successfully completed.	–	Update the order and refund status accordingly.

### When Is a Card Payment “Paid”? For card payments, a transaction is generally considered paid once it reaches the Captured status – this is the moment to fulfil the order. The Settled status follows later, once settlement with the acquiring bank has been completed, and may be applied after a configurable period (for example, one day). Settled confirms that the funds have been transferred to your account; use it for financial reconciliation, not as the fulfilment trigger. Note: This is the key difference from Pay by Bank: account-to-account payments do not use the Authorized or Captured statuses at all, and are considered paid only at Settled. If you accept both, make sure your order logic keys off the correct status per payment method. ### How Operations Change the Status

Operation	Resulting Status
Purchase (authorization + capture in one step)	Captured
Authorization (pre-authorization)	Authorized
Capture / Partial Capture of an authorized payment	Captured
Authorization Reversal (Void)	Cancelled
Refund / Partial Refund of a captured or settled payment	Refunded (via the refund lifecycle below)
Settlement with the acquiring bank (automatic)	Settled

See [Supported Operations](/payment-methods/cards/supported-operations.md) for when to use each operation. ### Refund Lifecycle Refund processing follows a separate lifecycle with its own statuses – for example, Processing, Completed, and Reverted: * When a refund reaches Completed, the corresponding payment status is updated to Refunded – for both full and partial refunds. * If a refund is later cancelled or reverted, the payment status may return to Settled, provided no other completed refunds remain for that payment. Track refund statuses separately from payment statuses in your order management – a payment showing Refunded may represent a partial refund with a remaining refundable balance. ### Timeouts, Expiration, and Abandoned Payments Payments that are not completed within defined time windows are automatically expired or marked as Abandoned – the gateway does not leave payments pending indefinitely. Timeout and expiration behavior may vary depending on the payment method and transaction state. Incomplete and exceptional payment attempts are clearly identifiable through the API and in the Merchant Portal with dedicated status indicators, supporting investigation, reconciliation, and operational follow-up. If a payment remains Initialized longer than expected, investigate before taking action – and always wait for the final status notification before updating the order. ### Merchant Best Practices * Fulfil orders on the Captured status (card payments), confirmed via a callback notification or the payment status returned by the gateway. * After receiving a callback, retrieve the complete payment details before updating your order – the notification tells you that the status changed; the payment information tells you what it changed to. * Ensure your status handling is idempotent – duplicate notifications must not create duplicate fulfilments or refunds. * Keep orders pending while the payment is Initialized or Authorized, and handle all final statuses (Failed, Cancelled, Abandoned) with clear customer messaging and a retry path. * Store payment references for reconciliation and customer support, and reconcile Settled payments against your account statements. ### Related Documentation * [Supported Operations](/payment-methods/cards/supported-operations.md) * [Card Payment Lifecycle](/payment-methods/cards/card-payment-lifecycle.md) * [Callback Notifications](/integration/merchant-api/webhooks.md) * [Refunds](/features/refunds.md) * [Pay by Bank › Payment Statuses](/payment-methods/pay-by-bank/payment-statuses.md) * [Merchant API](/integration/merchant-api.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/payment-methods/cards/payment-statuses.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.