> 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/celvezi/smilskaste/testa-scenariji/integracija-un-pasutijumu-apstrade.md).

# Integrācija un pasūtījumu apstrāde

Pārliecinieties, ka tirgotāja paša sistēma pareizi apstrādā maksājumus.

## Veiksmīgs maksājums

Izmantojiet Sandbox maksājuma metodes, lai pārbaudītu, ka jūsu integrācija pareizi apstrādā veiksmīgus maksājumus. Atjauniniet pasūtījumus un aktivizējiet izpildi tikai vienu reizi.

Izmantojiet apstiprināto maksājuma statusu kā patieso datu avotu. Nepaļaujieties uz pārlūka pāradresācijām vai klienta atgriešanos jūsu vietnē.

### Kā jāapstrādā veiksmīgi maksājumi

Uzskatiet maksājumu par veiksmīgu tikai pēc tam, kad tā galīgais statuss ir apstiprināts, izmantojot Payment API.

1. A **Webhook (saukts arī par atpakaļizsaukuma paziņojumiem)** tiek saņemts.
2. Maksājuma statuss tiek pārbaudīts, izmantojot Payment API.
3. Pasūtījuma statuss tiek atjaunināts.
4. Tiek aktivizēta izpilde.

Ieteicamā plūsma:

```
Pasūtījums gaida
    ↓
Klients pabeidz maksājumu
    ↓
Saņemts Webhook
    ↓
GET /egw/v1/payments/{paymentId}
    ↓
Pārbaudiet galīgo maksājuma statusu
    ↓
Atjauniniet pasūtījuma statusu
    ↓
Izpildiet pasūtījumu tikai vienu reizi
```

Ja Webhook nevar piegādāt, salāgojiet gaidošos maksājumus, izmantojot Payment API. Neatstājiet apstiprinātu maksājumu neapstrādātu tikai tāpēc, ka Webhook netika saņemts.

### Apstrādājamie maksājuma statusi

Dažādas maksājuma metodes var sasniegt atšķirīgus veiksmīgus statusus.

| Maksājuma metode   | Veiksmīgs statuss |
| ------------------ | ----------------- |
| Karte              | `Iekasēts`        |
| Google Pay         | `Iekasēts`        |
| Apple Pay          | `Iekasēts`        |
| Click to Pay       | `Iekasēts`        |
| Maksājums ar banku | `Norēķināts`      |

Pirms pasūtījuma atjaunināšanas pārbaudiet galīgo statusu.

### Karte, Google Pay, Apple Pay un Click to Pay

Klients veiksmīgi pabeidz maksājuma procesu.

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Veiciet veiksmīgu maksājumu.
3. Pārliecinieties, ka ir saņemts Webhook.
4. Iegūstiet jaunākās maksājuma detaļas.

   ```http
   GET /egw/v1/payments/{paymentId}
   ```
5. Pārbaudiet maksājuma statusu.
6. Atjauniniet pasūtījuma statusu.
7. Izpildiet pasūtījumu.

Piemērs:

```http
GET https://sandbox-api.ecomm.api.tietoevry.com/egw/v1/payments/019fffc4-17c4-7922-8be4-23cc21348aa1
```

#### Sagaidāmais rezultāts

* Maksājuma statuss ir `Iekasēts`.
* Tiek saņemts Webhook.
* Maksājuma ID tiek saglabāts.
* Pasūtījums mainās no Pending uz Paid.
* Izpilde tiek veikta tieši vienu reizi.
* Dublēta izpilde netiek veikta.

### Maksājums ar banku

Klients veiksmīgi pabeidz Pay by Bank maksājumu.

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Veiciet veiksmīgu Pay by Bank maksājumu.
3. Pārliecinieties, ka ir saņemts Webhook.
4. Iegūstiet maksājuma detaļas, izmantojot Payment API.
5. Pārbaudiet galīgo maksājuma statusu.
6. Atjauniniet pasūtījuma statusu.
7. Izpildiet pasūtījumu.

#### Sagaidāmais rezultāts

* Maksājuma statuss ir `Norēķināts`.
* Tiek saņemts Webhook.
* Maksājuma ID tiek saglabāts.
* Pasūtījums mainās no Pending uz Paid.
* Izpilde tiek veikta tieši vienu reizi.
* Dublēta izpilde netiek veikta.

### Maksājuma pārbaudes piemērs

Veiksmīga maksājuma atbildes piemērs:

```json
{
  "paymentId": "019fffc4-17c4-7922-8be4-23cc21348aa1",
  "paymentStatus": "CAPTURED",
  "orderNumber": "09a4efab-1365-409d-bb5f-a03a481c0b0d",
  "paidAmount": {
    "currency": "EUR",
    "amount": "38.00"
  }
}
```

Pārliecinieties, ka:

* `paymentId` ir norādīts.
* `paymentStatus` satur gaidīto veiksmīgo statusu.
* `paidAmount` atbilst pasūtījuma summai.
* `orderNumber` ir saistīts ar tirgotāja pasūtījumu.

### Tirgotāja validācijas pārbaudes saraksts

Pārliecinieties, ka:

* Webhook tiek saņemti veiksmīgi.
* Payment API pārbauda maksājuma statusu:

  ```http
  GET /egw/v1/payments/{paymentId}
  ```
* Maksājuma ID tiek saglabāts.
* Galīgais maksājuma statuss tiek saglabāts.
* Pasūtījums mainās no Pending uz Paid.
* Izpilde tiek veikta tieši vienu reizi.
* Dublēti Webhook neizraisa dublētu izpildi.
* Dublēti Webhook nerada dublētas piegādes.
* Dublēti Webhook nerada dublētus klienta paziņojumus.
* Gaidošie maksājumi tiek salāgoti, ja Webhook piegāde neizdodas.

## 3DS autentifikācija

Izmantojiet Sandbox karšu maksājumus, lai pārbaudītu maksājumu plūsmas, kurām nepieciešama EMV 3DS autentifikācija.

### Kā EMV 3DS ietekmē maksājuma statusu

EMV 3DS nav atsevišķa maksājuma statusa. Maksājums paliek `Inicializēts` kamēr klients pabeidz norēķinus un mijiedarbojas ar 3DS pārbaudi.

Maksājuma rezultāts tiek noteikts pēc autentifikācijas un izsniedzēja autorizācijas pabeigšanas.

| Statuss      | Apraksts                                                                          |
| ------------ | --------------------------------------------------------------------------------- |
| `Autorizēts` | 3DS autentifikācija bija veiksmīga, un divpakāpju autorizācija tika apstiprināta. |
| `Iekasēts`   | 3DS autentifikācija bija veiksmīga, un pirkuma maksājums tika apstiprināts.       |
| `Neizdevies` | Autentifikācija vai izsniedzēja autorizācija neizdevās.                           |
| `Pamests`    | Klients nepabeidza 3DS pārbaudi pirms tās termiņa beigām.                         |
| `Atcelts`    | Maksājums tika atcelts pirms pabeigšanas.                                         |

### Veiksmīga autentifikācija

Klients pabeidz 3DS pārbaudi, un maksājums tiek apstiprināts.

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Uzsāciet karšu maksājumu, kuram nepieciešama 3DS autentifikācija.
3. Veiciet autentifikāciju veiksmīgi.
4. Pārliecinieties, ka jūsu Webhook galapunkts saņem paziņojumu.
5. Iegūstiet jaunākās maksājuma detaļas:

   ```http
   GET /egw/v1/payments/{paymentId}
   ```
6. Pārbaudiet galīgo statusu, atjauniniet pasūtījumu un izpildiet to.

#### Sagaidāmais rezultāts

* Maksājums mainās no `Inicializēts` uz `Iekasēts`.
* Jūsu Webhook galapunkts saņem paziņojumu.
* Tirgotāja sistēma saglabā maksājuma ID.
* Payment API atgriež galīgo maksājuma statusu.
* Pasūtījums mainās no Pending uz Paid.
* Izpilde tiek veikta tieši vienu reizi.

### Veiksmīga autentifikācija ar divpakāpju maksājumiem

Daži tirgotāji izmanto atsevišķas autorizācijas un iekasēšanas darbības. Veiksmīga 3DS autentifikācija rezultējas autorizētā maksājumā. Saglabājiet pasūtījumu Pending vai rezervējiet krājumus līdz iekasēšana pabeigta. Izpildiet pasūtījumu tikai pēc tam, kad maksājums sasniedz `Iekasēts`.

```
Inicializēts
    ↓
3DS autentifikācija veiksmīga
    ↓
Autorizēts
    ↓
Iekasēt maksājumu
    ↓
Iekasēts
```

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Veiciet karšu maksājumu, kuram nepieciešama 3DS autentifikācija.
3. Pārliecinieties, ka maksājums sasniedz `Autorizēts`.
4. Saglabājiet pasūtījumu Pending statusā vai rezervējiet krājumus.
5. Iekasējiet maksājumu:

   ```http
   PATCH /egw/v1/payments/{paymentId}/capture
   ```
6. Iegūstiet jaunākās maksājuma detaļas.
7. Pārliecinieties, ka maksājums sasniedz `Iekasēts`.
8. Atjauniniet pasūtījumu un izpildiet to.

#### Sagaidāmais rezultāts

* Maksājums mainās no `Inicializēts` uz `Autorizēts`.
* Pasūtījums paliek Pending līdz iekasēšana ir veiksmīga.
* Iekasēšanas pieprasījums ir veiksmīgs.
* Maksājums mainās no `Autorizēts` uz `Iekasēts`.
* Payment API pārbauda maksājuma statusu.
* Pasūtījums mainās no Pending uz Paid.
* Izpilde tiek veikta tieši vienu reizi.
* Dublētas iekasēšanas nerada dublētu izpildi.

### Autentifikācija neizdevās

Klients neiztur 3DS pārbaudi vai izsniedzējs noraida autorizāciju.

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Uzsāciet karšu maksājumu, kuram nepieciešama 3DS autentifikācija.
3. Aktivizējiet neveiksmīgas autentifikācijas scenāriju.
4. Pārliecinieties, ka jūsu Webhook galapunkts saņem paziņojumu.
5. Iegūstiet jaunākās maksājuma detaļas, izmantojot Payment API.
6. Pārbaudiet galīgo maksājuma statusu.

#### Sagaidāmais rezultāts

* Maksājums mainās no `Inicializēts` uz `Neizdevies`.
* Jūsu Webhook galapunkts saņem paziņojumu.
* Pasūtījums paliek Pending vai Unpaid.
* Izpilde netiek sākta.
* Netiek izveidota ne piegāde, ne rēķins.
* Klients var mēģināt maksāt vēlreiz.

### Autentifikācija pamesta

Klients pamet autentifikācijas plūsmu pirms pārbaudes pabeigšanas. Maksājums kļūst `Pamests` pēc tam, kad vārteja piemēro taimauta vai derīguma termiņa apstrādi.

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Uzsāciet karšu maksājumu, kuram nepieciešama 3DS autentifikācija.
3. Aizveriet pārlūkprogrammu vai atstājiet autentifikācijas lapu.
4. Pagaidiet Webhook vai salāgojiet gaidošo maksājumu pēc attiecīgā taimauta.
5. Iegūstiet jaunākās maksājuma detaļas, izmantojot Payment API.
6. Pārliecinieties, ka galīgais statuss ir `Pamests`.

#### Sagaidāmais rezultāts

* Maksājums mainās no `Inicializēts` uz `Pamests` pēc taimauta vai derīguma termiņa apstrādes.
* Pasūtījums paliek Pending vai Unpaid.
* Izpilde netiek sākta.
* Netiek izveidota ne piegāde, ne rēķins.

### Maksājums atcelts

Klients atceļ maksājumu pirms pabeigšanas.

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Uzsāciet karšu maksājumu, kuram nepieciešama 3DS autentifikācija.
3. Atceliet maksājumu.
4. Iegūstiet maksājumu, izmantojot Payment API.
5. Pārbaudiet galīgo maksājuma statusu.

#### Sagaidāmais rezultāts

* Maksājums mainās no `Inicializēts` uz `Atcelts`.
* Pasūtījums paliek Pending vai Unpaid.
* Izpilde netiek sākta.
* Netiek izveidota ne piegāde, ne rēķins.

### Tirgotāja validācijas pārbaudes saraksts

Pārliecinieties, ka:

* Maksājums paliek `Inicializēts` 3DS plūsmas laikā.
* Webhook tiek saņemti un apstrādāti.
* Payment API pārbauda galīgo maksājuma statusu:

  ```http
  GET /egw/v1/payments/{paymentId}
  ```
* Veiksmīgi maksājumi rezultējas `Autorizēts` vai `Iekasēts`.
* Neveiksmīga autentifikācija rezultējas `Neizdevies`.
* Nepabeigta autentifikācija rezultējas `Pamests`.
* Atcelti maksājumi rezultējas `Atcelts`.
* Pasūtījumi tiek izpildīti tikai pēc veiksmīga maksājuma apstiprināšanas.
* Neveiksmīgi, pamesti un atcelti maksājumi nekad neizraisa izpildi.

{% hint style="warning" %}
Izmantojiet Webhook kopā ar maksājuma statusa pārbaudi, lai noteiktu maksājuma rezultātu. Nekad neizmantojiet pārlūka pāradresāciju kā vienīgo maksājuma veiksmes indikatoru.
{% endhint %}

## Neizdevušies maksājumi

Izmantojiet Sandbox maksājuma metodes, lai pārbaudītu neveiksmīgu, atceltu un nepabeigtu maksājumu apstrādi.

Uzskatiet maksājumu par neveiksmīgu tikai pēc tam, kad tā galīgais statuss ir pārbaudīts, izmantojot Payment API.

Novērsiet pasūtījuma izpildi neveiksmīgiem maksājumiem. Ja nepieciešams, ļaujiet klientam mēģināt vēlreiz.

### Kā jāapstrādā neveiksmīgi maksājumi

Apstipriniet maksājumu neveiksmes, izmantojot Webhook un maksājuma statusa pārbaudi.

Ieteicamā plūsma:

```
Pasūtījums gaida
    ↓
Maksājuma mēģinājums
    ↓
Saņemts Webhook
    ↓
GET /egw/v1/payments/{paymentId}
    ↓
Pārbaudiet galīgo maksājuma statusu
    ↓
Saglabāt pasūtījumu kā Unpaid
    ↓
Atļaut atkārtotu mēģinājumu
```

### Neveiksmīgs maksājums

Izdevējs noraida maksājumu vai apstrāde neizdodas.

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Aktivizējiet neveiksmīga maksājuma scenāriju.
3. Pārliecinieties, ka ir saņemts Webhook.
4. Iegūstiet maksājuma detaļas:

   ```http
   GET /egw/v1/payments/{paymentId}
   ```
5. Pārbaudiet galīgo maksājuma statusu.
6. Pārskatiet pasūtījuma apstrādi.

#### Sagaidāmais rezultāts

* Maksājuma statuss ir `Neizdevies`.
* Maksājuma ID ir pieejams.
* Tiek saņemts Webhook.
* Pasūtījums paliek Pending vai Unpaid.
* Izpilde netiek sākta.
* Netiek izveidota ne piegāde, ne rēķins.
* Klients var mēģināt maksāt vēlreiz.

### Atcelts maksājums

Klients vai tirgotājs atceļ maksājumu pirms pabeigšanas.

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Sāciet maksājuma plūsmu.
3. Atceliet maksājumu.
4. Iegūstiet maksājuma detaļas, izmantojot Payment API.
5. Pārbaudiet galīgo maksājuma statusu.

#### Sagaidāmais rezultāts

* Maksājuma statuss ir `Atcelts`.
* Pasūtījums paliek Pending vai Unpaid.
* Izpilde netiek sākta.
* Netiek izveidota piegāde.
* Klients var uzsākt jaunu maksājuma mēģinājumu.

### Pamests maksājums

Klients pamet maksājuma plūsmu, to nepabeidzot.

#### Pārbaude

1. Izveidojiet jaunu pasūtījumu statusā Pending.
2. Sāciet maksājuma plūsmu.
3. Atstājiet maksājuma vai autentifikācijas lapu pirms pabeigšanas.
4. Iegūstiet maksājuma detaļas, izmantojot Payment API.
5. Pārbaudiet galīgo maksājuma statusu.

#### Sagaidāmais rezultāts

* Maksājuma statuss ir `Pamests`.
* Pasūtījums paliek Pending vai Unpaid.
* Izpilde netiek sākta.
* Netiek izveidota ne piegāde, ne rēķins.
* Klients var uzsākt jaunu maksājuma mēģinājumu.

### Maksājuma pārbaudes piemērs

Pārbaudiet galīgo maksājuma stāvokli:

```http
GET /egw/v1/payments/{paymentId}
```

Neveiksmīga maksājuma atbildes piemērs:

```json
{
  "paymentId": "019fffc4-17c4-7922-8be4-23cc21348aa1",
  "paymentStatus": "FAILED"
}
```

| Maksājuma statuss | Tirgotāja darbība       |
| ----------------- | ----------------------- |
| `Neizdevies`      | Neizpildiet pasūtījumu. |
| `Atcelts`         | Neizpildiet pasūtījumu. |
| `Pamests`         | Neizpildiet pasūtījumu. |

### Webhook

Webhook informē jūsu sistēmu, kad mainās maksājuma statuss.

Izmantojiet katru Webhook kā aktivizētāju, lai iegūtu un apstrādātu jaunāko maksājuma stāvokli.

Šie norādījumi attiecas uz:

* Unified Merchant API
* API klienta SDK
* Hosted Checkout
* Tīmekļa spraudnis
* Mobilais SDK

Vienmēr iegūstiet jaunāko maksājuma statusu, izmantojot Payment API, pirms atjaunināt pasūtījumu vai aktivizēt izpildi.

{% hint style="info" %}
Tīmekļa spraudņi apstrādā Webhook kā daļu no standarta funkcionalitātes. Citām integrācijām implementējiet Webhook galapunktu.
{% endhint %}

#### Konfigurējiet Webhook

Konfigurējiet Callback URL katram veikalam, lai saņemtu automātiskus maksājuma statusa paziņojumus.

Galapunktam jābūt publiski pieejamam, izmantojot HTTPS.

**Tirgotāja portāla**

1. Pierakstieties Merchant Portal.
2. Atveriet **Iestatījumi → Veikala iestatījumi**.
3. Atlasiet nepieciešamo veikalu.
4. Atlasiet **Rediģēt līgumu**.
5. Atvērt **Tehniskā informācija**.
6. Ievadiet galapunktu sadaļā **Atbildes URL**.
7. Iesniedziet izmaiņas apstiprināšanai.

Piemērs:

```
https://merchant.example.com/payment-callback
```

Konfigurējiet Sandbox un Production Callback URL atsevišķi.

Vārteja nosūta paziņojumu ikreiz, kad mainās maksājuma statuss.

#### Ieteicamā Webhook apstrādes plūsma

```
Saņemts Webhook
    ↓
Izvelciet maksājuma ID
    ↓
GET /egw/v1/payments/{paymentId}
    ↓
Pārbaudiet maksājuma statusu
    ↓
Atjauniniet pasūtījumu
    ↓
Aktivizējiet biznesa darbības
```

Uzskatiet Webhook par maksājuma pārbaudes aktivizētāju.

Uzskatiet Payment API atbildi par patieso datu avotu.


---

# 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/celvezi/smilskaste/testa-scenariji/integracija-un-pasutijumu-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.
