> 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/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/maksajums-no-bankas-konta/maksajumu-apstrade.md).

# Maksājumu apstrāde

Pay by Bank ļauj klientiem autorizēt maksājumus tieši pie viņu izvēlētās bankas, kamēr tirgotāji integrējas tikai ar **SEB Ecommerce maksājumu vārteju**.

Lai gan klienta autentifikācijas pieredze var atšķirties starp bankām, tirgotāja integrācija paliek nemainīga.

***

## Maksājuma plūsma

Šī diagramma ilustrē tipisku Pay by Bank maksājuma plūsmu.

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

flowchart LR

    C["Klients"]
    M["Tirgotājs"]
    G["SEB Ecommerce vārteja"]
    B["Izvēlētā banka"]

    C -->|"1. Izvēlēties Pay by Bank"| M
    M -->|"2. Izveidot maksājumu"| G
    G -->|"3. Novirzīt klientu"| B
    B -->|"4. Autentificēt klientu"| B
    B -->|"5. Autorizēt maksājumu"| B
    B -->|"6. Maksājuma rezultāts"| G
    G -->|"7. Atpakaļsaukums / maksājuma atbilde"| M
    M -->|"8. Pasūtījuma apstiprinājums"| 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
```

***

## Maksājuma apstrādes soļi

1. **Klients izvēlas Pay by Bank.** Klients norēķinoties izvēlas Pay by Bank kā maksājuma metodi.
2. **Tirgotājs izveido maksājumu.** Tirgotājs izveido maksājuma pieprasījumu, izmantojot SEB Ecommerce maksājumu vārteju – caur [Hosted Checkout](/seb-docs-draft/seb-docs-public-lv/integracija/mitinata-norekinu-lapa.md) vai [Merchant API](/seb-docs-draft/seb-docs-public-lv/integracija/tirgotaja-api.md).
3. **Klients izvēlas banku.** Klients izvēlas savu valsti un vienu no atbalstītajām iesaistītajām bankām.
4. **Klienta autentifikācija.** Klientam tiek lūgts piekrist piekļuvei viņa konta informācijai, un viņš tiek novirzīts uz izvēlēto banku, lai pieteiktos un apstiprinātu piekļuvi. Autentifikācija tiek pabeigta, izmantojot bankas atbalstītās metodes – piemēram, mobilo bankas lietotni, Smart-ID, Mobile-ID, Face ID, pirksta nospiedumu vai ierīces piekļuves kodu.
5. **Klients izvēlas kontu.** Balstoties uz bankas atgriezto informāciju, klients izvēlas kontu, no kura veikt maksājumu, un pārskata maksājuma informāciju.
6. **Maksājuma autorizācija.** Klients tiek vēlreiz novirzīts uz banku, lai pārskatītu un apstiprinātu maksājumu. Atkarībā no bankas autentifikācijas un apstiprināšanas soļi var tikt apvienoti vienā plūsmā.
7. **Maksājuma rezultāts.** Izvēlētā banka nosūta maksājuma rezultātu uz SEB Ecommerce maksājumu vārteju.
8. **Tirgotāja paziņojums.** Vārteja nosūta maksājuma rezultātu uz jūsu sistēmām, izmantojot konfigurēto [atpakaļsaukumu vai webhook](/seb-docs-draft/seb-docs-public-lv/integracija/tirgotaja-api/webhook.md), un statuss ir redzams Merchant Portal.
9. **Pasūtījuma izpilde.** Pēc paziņojuma saņemšanas, ka maksājums ir sasniedzis statusu Settled, varat turpināt pasūtījuma izpildi.

{% hint style="warning" %}

## Vienmēr paļaujieties uz atpakaļsaukuma paziņojumiem vai uz maksājuma statusu, ko atgriež vārteja. Nepaļaujieties tikai uz to, ka pēc autentifikācijas klienta pārlūkprogramma atgriezīsies jūsu vietnē – pārlūkprogramma var arī nekad neatgriezties, pat ja maksājums ir veiksmīgs.

{% endhint %}

{% hint style="info" %}
Katra iesaistītā banka nosaka savu klienta autentifikācijas plūsmu. Autentifikācijas metode un lietotāja pieredze var atšķirties starp bankām – jūsu integrācija netiek ietekmēta.
{% endhint %}

{% hint style="info" %}
Jūs integrējaties tikai ar SEB Ecommerce maksājumu vārteju. Atsevišķām bankām nav nepieciešama atsevišķa integrācija.
{% endhint %}

***

### Kas notiek, ja klients pamet maksājumu?

Ja klients aizver pārlūkprogrammu vai nepabeidz autentifikāciju, maksājums paliek statusā Initialized, līdz tas tiek pabeigts, atcelts vai beidzas atļautais laika logs – pēc kura tas automātiski tiek atzīmēts kā galīgais nepabeigtais statuss (Abandoned). Turiet pasūtījumu gaidīšanas stāvoklī un pirms atjaunināšanas sagaidiet galīgo maksājuma paziņojumu. Nepabeigtie maksājuma mēģinājumi ir skaidri identificējami Merchant Portal.

***

### Vienas klikšķa maksājumi ar Pay by Bank

Ja tas ir iespējots jūsu tirgotāja kontā, Pay by Bank atbalsta vienas klikšķa maksājumus atkārtotiem klientiem, pamatojoties uz iepriekš sniegtu klienta piekrišanu un saglabātu konta atsauci.

{% hint style="info" %}
Vienas klikšķa maksājumi ir pieejami tikai tām bankām, kas atbalsta šo funkciju. Pašlaik atbalstītās bankas ir **SEB** un **Swedbank** Latvijā; **SEB**, **Swedbank**, kā arī **Artea** Lietuvā; un **SEB**, **Swedbank**, kā arī **LHV** Igaunijā.
{% endhint %}

#### Kā tas darbojas

1. Klients piekrīt izmantot šo funkciju. Sākotnējā maksājuma laikā klients var izvēlēties saglabāt izvēlētās bankas un konta informāciju turpmākajiem maksājumiem.
2. Tiek izveidota droša konta atsauce. Pēc veiksmīgas autorizācijas bankā vārteja ģenerē drošu žetonu, kas attēlo klienta konta atsauci. Žetons tiek glabāts vārtejas drošajā vidē un ir derīgs ierobežotu laiku – piemēram, līdz 180 dienām – atbilstoši bankas politikai un normatīvajām prasībām.
3. Atkārtoti klienti norēķinās ātrāk. Turpmākiem pirkumiem jūs uzsākat maksājumu, izmantojot saglabāto konta atsauci, caur īpašu API galapunktu. Klients izlaiž bankas un konta izvēles soļus un pāriet tieši uz maksājuma apstiprināšanu.

Atkarībā no bankas ieviešanas un piemērojamajām stingrās klienta autentifikācijas prasībām klientam joprojām var tikt lūgts apstiprināt vai autentificēt maksājumu – bankas apstiprināšanas soli ne vienmēr var izlaist. Pay by Bank ar vienu klikšķi saīsina plūsmu; tas neizņem klientu no tās.

{% hint style="info" %}
Saglabātā atsauce identificē klienta bankas un konta izvēli – tā jums nepiešķir piekļuvi kontam. Katrs maksājums joprojām ir pakļauts klienta bankas autorizācijai. Kad žetons beidzas, klients vienkārši vēlreiz iziet standarta bankas izvēles plūsmu.
{% endhint %}

***

### **Atkārtoti un turpmākie Pay by Bank maksājumi**

Ja tas ir iespējots Tirgotājam un to atbalsta attiecīgā banka vai ASPSP, Pay by Bank var izmantot atkārtotiem un turpmākiem konta-konta maksājumiem, izmantojot Merchant API.

Sākotnējo maksājumu klients pabeidz, izmantojot standarta Pay by Bank plūsmu. Ja tas tiek atbalstīts, klients var sniegt piekrišanu turpmākiem maksājumiem, un Vārteja izveido drošu konta atsauci, kas saistīta ar izvēlēto banku un kontu.

Turpmākajiem maksājumiem:

1. Tirgotāja aizmugursistēma nosaka, kad maksājums jāveic, un aprēķina maksājuma summu.
2. Tirgotājs uzsāk maksājumu, izmantojot Merchant API un saglabāto konta atsauci.
3. Vārteja nosūta maksājuma pieprasījumu attiecīgajai bankai vai ASPSP.
4. Maksājuma statuss tiek atgriezts caur API un, ja konfigurēts, caur webhook paziņojumiem.

Tirgotājs ir atbildīgs par atkārtotu maksājumu loģiku, tostarp maksājumu grafiku, norēķinu noteikumiem, atkārtotiem mēģinājumiem, atcelšanu, saziņu ar klientu un abonementu pārvaldību. Vārteja neveido abonēšanas plānus un neatkarīgi neplāno un neuzsāk atkārtotus maksājumus.

Atkarībā no bankas ieviešanas un piemērojamajām normatīvajām prasībām klientam joprojām var būt nepieciešams apstiprināt vai autentificēt turpmāku maksājumu. Saglabātā konta atsauce vienkāršo maksājuma plūsmu, taču negarantē, ka klienta apstiprinājums vai stingrā klienta autentifikācija tiks izlaista.

Atkārtotu un turpmāku Pay by Bank maksājumu pieejamība, saglabātās konta atsauces derīgums un nepieciešamība pēc papildu klienta autentifikācijas ir atkarīga no attiecīgās bankas vai ASPSP, iespējotās Tirgotāja konfigurācijas, piemērojamā pilnvarojuma vai piekrišanas modeļa un normatīvajām prasībām.


---

# 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/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/maksajums-no-bankas-konta/maksajumu-apstrade.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.