> 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/pay-by-bank/payment-processing.md).

# Payment Processing

Pay by Bank enables customers to authorize payments directly with their selected bank while merchants integrate only with the **SEB Ecommerce Payment Gateway**.

Although the customer authentication experience may vary between banks, the merchant integration remains the same.

***

## Payment Flow

The following diagram illustrates a typical Pay by Bank payment flow.

```mermaid
%%{init: {
  "theme":"base",
  "themeVariables":{
    "primaryColor":"#009A44",
    "primaryBorderColor":"#006B3F",
    "primaryTextColor":"#FFFFFF",
    "lineColor":"#006B3F",
    "fontFamily":"Arial"
  }
}}%%

flowchart LR

    C["Customer"]
    M["Merchant"]
    G["SEB Ecommerce Gateway"]
    B["Selected Bank"]

    C -->|"1. Select Pay by Bank"| M
    M -->|"2. Create Payment"| G
    G -->|"3. Redirect Customer"| B
    B -->|"4. Authenticate Customer"| B
    B -->|"5. Authorize Payment"| B
    B -->|"6. Payment Result"| G
    G -->|"7. Callback / Payment Response"| M
    M -->|"8. Order Confirmation"| C

    style C fill:#DFF4E8,stroke:#009A44,color:#333333
    style M fill:#DFF4E8,stroke:#009A44,color:#333333
    style G fill:#009A44,stroke:#006B3F,color:#FFFFFF
    style B fill:#F5F5F5,stroke:#999999,color:#333333
```

***

## Payment Processing Steps

1. **Customer selects Pay by Bank.** The customer selects Pay by Bank as the payment method during checkout.
2. **Merchant creates the payment.** The merchant creates a payment request through the SEB Ecommerce Payment Gateway – via [Hosted Checkout](/integration/hosted-checkout.md) or the [Merchant API](/integration/merchant-api.md).
3. **Customer selects a bank.** The customer chooses their country and one of the supported participating banks.
4. **Customer authentication.** The customer is asked to consent to accessing their account information, and is redirected to the selected bank to log in and approve the access. Authentication is completed using the bank’s supported methods – for example, the mobile banking app, Smart-ID, Mobile-ID, Face ID, fingerprint, or device passcode.
5. **Customer selects account.** Customer selects an account. Based on the information returned by the bank, the customer selects the account to pay from and reviews the payment details.
6. **Payment authorization.** The customer is taken to the bank again to review and confirm the payment. Depending on the bank, the authentication and confirmation steps may be combined into a single journey.
7. **Payment result.** The selected bank returns the payment result to the SEB Ecommerce Payment Gateway.
8. **Merchant notification.** The gateway sends the payment result to your systems using the configured [callback or webhook](/integration/merchant-api/webhooks.md), and the status is visible in the Merchant Portal.
9. **Order fulfilment.** After receiving the notification that the payment has reached the Settled status, you may continue with order fulfilment.

{% hint style="warning" %}

## 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 after authentication – the browser may never return even when the payment succeeds.

{% endhint %}

{% hint style="info" %}
Each participating bank determines its own customer authentication journey. The authentication method and user experience may differ between banks – your integration is not affected.
{% endhint %}

{% hint style="info" %}
You integrate only with the SEB Ecommerce Payment Gateway. No separate integration is required for individual banks.
{% endhint %}

***

### What Happens if the Customer Leaves the Payment?

If the customer closes the browser or does not complete authentication, the payment remains Initialized until it is completed, cancelled, or the allowed time window passes – after which it is automatically marked as a final incomplete status (Abandoned). Keep the order in a pending state and wait for the final payment notification before updating it. Incomplete payment attempts are clearly identifiable in the Merchant Portal.

***

### One-Click Payments with Pay by Bank

Where enabled for your merchant account, Pay by Bank supports one-click payments for returning customers, based on previously granted customer consent and a stored account reference.

{% hint style="info" %}
One-click payments are available only for banks that support this feature. Currently supported banks are **SEB** and **Swedbank** in Latvia; **SEB**, **Swedbank**, and **Artea** in Lithuania; and **SEB**, **Swedbank**, and **LHV** in Estonia.
{% endhint %}

#### How It Works

1. The customer opts in. During the initial payment, the customer may choose to store their selected bank and account details for future payments.
2. A secure account reference is created. After successful authorization with the bank, the gateway generates a secure token representing the customer’s account reference. The token is stored within the gateway’s secure environment and remains valid for a limited period – for example, up to 180 days – subject to the bank’s policies and regulatory requirements.
3. Returning customers check out faster. For subsequent purchases, you initiate the payment using the stored account reference via a dedicated API endpoint. The customer skips the bank and account selection steps and proceeds directly to payment confirmation.

Depending on the bank’s implementation and applicable Strong Customer Authentication requirements, the customer may still be asked to approve or authenticate the payment – the confirmation step at the bank cannot always be skipped. One-click Pay by Bank shortens the journey; it does not remove the customer from it.

{% hint style="info" %}
The stored reference identifies the customer’s bank and account selection – it does not give you access to the account. Every payment remains subject to the customer’s bank authorization. When the token expires, the customer simply goes through the standard bank selection flow again.
{% endhint %}

***

### **Recurring and Subsequent Pay by Bank Payments**

Where enabled for the Merchant and supported by the relevant bank or ASPSP, Pay by Bank may be used for recurring and subsequent account-to-account payments through the Merchant API.

The initial payment is completed by the customer through the standard Pay by Bank flow. Where supported, the customer may provide consent for future payments, and the Gateway creates a secure account reference associated with the selected bank and account.

For subsequent payments:

1. The Merchant’s backend determines when a payment should be made and calculates the payment amount.
2. The Merchant initiates the payment through the Merchant API using the stored account reference.
3. The Gateway sends the payment request to the relevant bank or ASPSP.
4. The payment status is returned through the API and, where configured, through webhook notifications.

The Merchant is responsible for the recurring payment logic, including the payment schedule, billing rules, retries, cancellation, customer communication, and subscription management. The Gateway does not create subscription plans or independently schedule and initiate recurring payments.

Depending on the bank’s implementation and applicable regulatory requirements, the customer may still be required to approve or authenticate a subsequent payment. The stored account reference simplifies the payment flow but does not guarantee that customer confirmation or Strong Customer Authentication will be skipped.

The availability of recurring and subsequent Pay by Bank payments, the validity of the stored account reference, and the need for additional customer authentication depend on the relevant bank or ASPSP, enabled Merchant configuration, applicable mandate or consent model, and regulatory requirements.


---

# 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/pay-by-bank/payment-processing.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.