> 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/card-payment-lifecycle.md).

# Card Payment Lifecycle

## Card Payment Processing

Understanding how a card payment is processed helps merchants correctly implement payment flows, manage order fulfilment, and handle post-payment operations such as captures and refunds.

The SEB Ecommerce Payment Gateway combines secure payment gateway services with acquiring services, enabling merchants to process Visa and Mastercard transactions through a single platform.

***

### Payment Participants

A typical card payment involves the following participants:

| Participant                                            | Description                                                                                                                 |
| ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| **Customer**                                           | The cardholder making the purchase.                                                                                         |
| **Merchant**                                           | The business accepting the payment.                                                                                         |
| **SEB Ecommerce Payment Gateway & Acquiring Services** | Securely processes the payment request, performs acquiring services, and routes authorization requests to the card schemes. |
| **Card Scheme**                                        | Visa or Mastercard, providing the global payment network.                                                                   |
| **Issuer**                                             | The financial institution that issued the customer's payment card and authorizes the transaction.                           |

***

### Card Payment Flow

The following diagram illustrates a typical card payment flow.

```mermaid
sequenceDiagram
    participant C as Customer
    participant M as Merchant
    participant S as SEB Gateway & Acquiring
    participant V as Visa / Mastercard
    participant I as Issuer

    C->>M: Submit payment
    M->>S: Create payment
    S->>V: Authorization request
    V->>I: Forward authorization request
    I-->>V: Approve or Decline
    V-->>S: Authorization response
    S-->>M: Payment result
    M-->>C: Display payment result
```

***

### Card Payment Lifecycle

Every card payment follows the same high-level lifecycle.

```mermaid
flowchart LR

A[Customer Checkout]
-->
B[Authentication<br/>EMV® 3DS if required]
-->
C[Authorization]
-->
D[Capture]
-->
E[Settlement]

D --> F[Refund]

C --> G[Reversal / Void]
```

***

### Payment Stages

#### Customer Checkout

The customer selects **Payment Card** during checkout and enters their payment details using the selected integration method.

Depending on your integration, payment details are collected through:

* Hosted Checkout
* Merchant API

***

#### Authentication

Where required, the customer completes **EMV® 3-D Secure (EMV 3DS)** authentication.

Authentication may be performed using:

* One-Time Password (OTP)
* Banking application approval
* Fingerprint or Face ID
* Other issuer-supported authentication methods

***

#### Authorization

The payment request is routed through the card scheme to the issuing bank.

The issuer evaluates the transaction by checking:

* Card validity
* Available funds or credit
* Authentication results
* Fraud and risk indicators

The issuer then either:

* Approves the transaction
* Declines the transaction

An approved authorization reserves the requested amount on the customer's account.

***

#### Capture

Capture confirms that the merchant wishes to collect the authorized funds.

Depending on the merchant configuration, payments may be:

* Captured automatically
* Captured manually
* Partially captured

***

#### Settlement

Following capture, the transaction enters the settlement process.

The card scheme transfers settlement information between the issuer and SEB. Funds are then settled to the merchant according to the agreed settlement schedule.

***

#### Post-Payment Operations

After authorization or settlement, additional operations may be available depending on the payment status.

Supported operations include:

* Capture
* Partial Capture
* Refund
* Partial Refund
* Reversal / Void

Detailed information is available in the [**Supported Operations**](/payment-methods/cards/supported-operations.md) section.

***

### Related Documentation

Continue with the following topics to learn more about card payment processing:

* [Supported Operations](/payment-methods/cards/supported-operations.md)
* [Stored Credentials](/payment-methods/cards/stored-credentials.md)
* [EMV® 3-D Secure](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md)
* [Tokenization](/payment-methods/cards/tokenization.md)
* [Testing](/payment-methods/cards/testing.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/card-payment-lifecycle.md?ask=<question>&goal=<user_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.
