> 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/integracija/tirgotaja-api/webhook.md).

# Webhook

Servera paziņojumi, kas jūsu sistēmām informē, kad mainās maksājuma statuss vai vārtejas tokens — uzticama alternatīva gaidīšanai uz klienta pārlūkprogrammu.

Ikreiz, kad maksājuma statuss mainās – tas ir apmaksāts, neizdodas, tiek atcelts, beidzas tā termiņš vai tiek atmaksāts – vārteja nosūta **Webhook (saukts arī par atgriezeniskajiem paziņojumiem)** uz konfigurēto Callback URL. Pēc tam jūsu sistēmas var automātiski atjaunināt pasūtījumu, nevienam neskatoties Tirgotāja portālā un nepaļaujoties uz to, ka klienta pārlūkprogramma atgriezīsies jūsu vietnē.

Webhooki tiek piegādāti no servera uz serveri, neatkarīgi no tā, ko dara klients. Tie pienāk arī tad, ja klients pēc apmaksas aizver pārlūkprogrammu, zaudē savienojumu vai nekad neatgriežas jūsu veikalā. Izpildiet pasūtījumus, balstoties uz maksājuma statusu, ko apstiprinājusi vārteja, nevis uz klienta atgriešanos.

Webhooki ir ieteicami katram integrācijas veidam – Merchant API, Hosted Checkout, Web Plugins un Payment Links. Web Plugins apstrādā Webhookus kā daļu no savas standarta funkcionalitātes. Savām integrācijām ieviesiet Webhook gala punktu.

### Kā tas darbojas

1. Konfigurējiet savu Callback URL. Tirgotāja portālā iestatiet savas puses HTTPS gala punktu, kas saņems paziņojumus par veikalu.
2. Maksājuma statuss mainās. Klients veic maksājumu, pārtrauc maksājumu, tiek pabeigta autorizētā ieturēšana, tiek apstrādāta atmaksa – jebkuras statusa izmaiņas izraisa paziņojumu.
3. Vārteja paziņo jūsu gala punktam. Paziņojums norāda, kurš maksājums ir mainījies (Payment ID) un kāds ir tā jaunākais statuss. Jūsu gala punkts apstiprina saņemšanu ar veiksmīgas atbildes ziņojumu.
4. Jūs izgūstat maksājuma informāciju. Pēc paziņojuma saņemšanas izsauciet Get Payment Information API, lai iegūtu pilnīgu, aktuālu maksājuma informāciju – paziņojums ir ierosinātājs; API atbilde ir autoritatīvais avots.
5. Jūs atjaunināt pasūtījumu. Balstoties uz apstiprināto statusu, atjauniniet pasūtījumu: izpildiet pie apmaksāta statusa, atbrīvojiet krājumu pie galīgas neveiksmes, reģistrējiet atmaksu un tā tālāk. Skatiet Maksājumu statusus, lai redzētu ieteicamo darbību katram statusam.

{% hint style="info" %}
Uztveriet paziņojumu kā signālu, nevis kā datus. Pirms pasūtījuma atjaunināšanas vienmēr izgūstiet maksājuma informāciju, izmantojot autentificēto API – tas vienlaikus sniedz pilnu aktuālo stāvokli un pasargā jūs no viltotiem vai novecojušiem paziņojumiem.
{% endhint %}

{% hint style="warning" %}
Neveiciet Get Payment Information aptauju katram iniciētam maksājumam. Izmantojiet Webhookus kā parasto statusa izgūšanas ierosinātāju. Vaicājiet API tikai izņēmumu gadījumos, piemēram, ja paziņojums nav saņemts sagaidītajā laikā vai kad operators manuāli pieprasa aktuālu maksājuma informāciju.
{% endhint %}

### Kas izraisa paziņojumu

* Maksājuma statusa izmaiņas. Katra maksājuma statusa maiņa – gan karšu maksājumiem, gan Pay by Bank. Tas ietver arī ar atmaksu saistītas izmaiņas: kad atmaksa tiek pabeigta, maksājuma statuss mainās uz Atmaksāts, un tiek nosūtīts paziņojums.
* Tokena izmaiņas. Ja ir iespējota tokenizācija, vārteja jūs informē par tokenu izmaiņām – piemēram, kad saglabāts tokens tiek apturēts vai deaktivizēts – lai jūs varētu uzturēt saglabātās maksājumu metodes aktuālas un apturēt no tirgotāja puses iniciētas maksas. Skatiet Tokenizāciju.

### Webhook gala punkta projektēšana

* Izmantojiet HTTPS. Webhooki tiek piegādāti tikai uz drošiem gala punktiem. Ierobežojiet gala punktu tikai Webhook apstrādei.
* Atbildiet ātri. Nekavējoties apstipriniet paziņojumu un, ja iespējams, apstrādājiet to asinhroni. Ilgstoša biznesa loģika pieprasījuma apstrādātājā izraisa taimautus un nevajadzīgus atkārtotus mēģinājumus.
* Nodrošiniet idempotenci. Tas pats paziņojums var tikt piegādāts vairāk nekā vienu reizi – piemēram, pēc atkārtota mēģinājuma. Paziņojuma apstrādei divreiz nedrīkst radīt dubultus pasūtījumu izpildījumus, dubultus atmaksu ierakstus vai dubultas klientu e-pasta vēstules.
* Vispirms izgūstiet, pēc tam rīkojieties. Nekad nerīkojieties tikai no paziņojuma satura – izgūstiet maksājumu vai vārtejas tokenu, izmantojot API, un rīkojieties, balstoties uz apstiprināto stāvokli.
* Gaidiet, ka notikumi var būt ārpus secības un sakopoti. Vienmēr rīkojieties, balstoties uz jaunāko apstiprināto stāvokli no API, nevis pieņemot saņemšanas kārtību.
* Saglabājiet audita pēdu. Reģistrējiet saņemtos paziņojumus ar laikspiedoliem – tie ir ļoti vērtīgi atbalsta gadījumos un saskaņošanā.

### Piegādes atkārtoti mēģinājumi un nepamanīti paziņojumi

Ja jūsu gala punkts īslaicīgi nav pieejams vai neapstiprina paziņojumu, vārteja automātiski atkārtoti mēģina piegādi, izmantojot pieaugošu atkārtojumu grafiku. Ja visi atkārtotie mēģinājumi ir izsmelti, par šo notikumu vairs netiek sūtīti paziņojumi.

Projektējiet sistēmu, ņemot vērā iespēju, ka paziņojums var netikt saņemts:

* Uzraugiet sava gala punkta pieejamību un kļūdu biežumu – bojāts gala punkts klienta skatījumā neizdodas klusējot.
* Pēc dīkstāves vai nepamanītiem paziņojumiem pārskatiet nesenākos pasūtījumus, kas vēl ir gaidīšanas stāvoklī, un atsvaidziniet to statusu, izmantojot API.

### Konfigurācija

* Iestatiet savu Callback URL sadaļā Tirgotāja portāls → Iestatījumi → Veikala iestatījumi → Tehniskā informācija. Katram veikalam ir sava konfigurācija.
* Konfigurējiet Sandbox un Production atsevišķi – nodrošinot, ka testa paziņojumi nekad nesasniedz jūsu ražošanas gala punktu un otrādi.

### Testēšana

Pirms palaišanas pārbaudiet Webhook apstrādi Sandbox vidē:

* Veiksmīgi, neveiksmīgi, atcelti un pārtraukti maksājuma scenāriji – pārbaudiet, ka katram tiek saņemts paziņojums un pasūtījums tiek pareizi atjaunināts.
* Atmaksas scenāriji – pārbaudiet, ka ar atmaksu saistītās statusa izmaiņas sasniedz jūsu sistēmas.
* Dublēta piegāde – pārbaudiet, ka viena un tā paša paziņojuma apstrāde divreiz nerada dublikātus.
* Gala punkta nepieejamība – izslēdziet savu gala punktu, pabeidziet testa maksājumu, atjaunojiet to un pārbaudiet atkopšanos, izmantojot API saskaņošanu.

### Biežāk uzdotie jautājumi

#### Vai man ir vajadzīgi Webhooki, ja izmantoju Hosted Checkout?

Jā – hostētā lapa nodrošina klienta pieredzi, bet jūsu pasūtījumu apstrādei joprojām ir jāzina maksājuma rezultāts. Klienta atgriešanās jūsu vietnē nav maksājuma apstiprinājums. To apstiprina Webhook vai API statusa vaicājums.

#### Vai man ir vajadzīgi Webhooki, ja izmantoju Web Plugin?

Web Plugins ietver darījuma statusa apstrādi kā daļu no savas standarta funkcionalitātes. Tie apstrādā Webhookus un atjaunina pasūtījumu statusus. Jums pašam nav jāievieš gala punkts.

#### Kas notiek, ja mans serveris nebija pieejams, kad tika nosūtīts paziņojums?

Vārteja automātiski atkārtos piegādi ar pieaugošiem intervāliem. Ja visi atkārtotie mēģinājumi ir izsmelti, šis paziņojums vairs netiek sūtīts atkārtoti – saskaņojiet datus, izmantojot Get Payment Information API un Tirgotāja portālu, lai panāktu līdzi visām nepamanītajām statusa izmaiņām.

#### Vai es varu saņemt vienu un to pašu paziņojumu divreiz?

Jā – piemēram, ja jūsu gala punkts atbildēja lēni un tika aktivizēts atkārtots mēģinājums. Veidojiet apstrādi kā idempotentu, lai dublikātam nebūtu ietekmes.

#### Kā es varu zināt, ka paziņojums ir īsts?

Nerīkojieties, balstoties tikai uz paziņojuma saturu. Izmantojiet to tikai kā ierosinātāju un izgūstiet maksājuma informāciju, izmantojot autentificēto Get Payment Information API – autoritatīvais stāvoklis vienmēr nāk no API, tāpēc viltots paziņojums nevar izraisīt nepareizu pasūtījuma izpildi.

#### Par kuriem statusiem es saņemšu paziņojumus?

Par katru maksājuma statusa maiņu tiek ģenerēts paziņojums – skatiet Maksājumu statusus (Kartes) un Pay by Bank › Maksājumu statusi, lai redzētu statusu modeļus un ieteicamo darbību katram statusam.

### Saistītā dokumentācija

* [Maksājumu statusi (Kartes)](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/maksajuma-statusi.md)
* [Pay by Bank › Maksājumu statusi](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/maksajums-no-bankas-konta/maksajuma-statusi.md)
* [Vienotais Merchant API](/seb-docs-draft/seb-docs-public-lv/integracija/tirgotaja-api.md)
* [Tokenizācija](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/tokenizacija.md)
* [Tirgotāja portāls](/seb-docs-draft/seb-docs-public-lv/celvezi/tirgotaja-portals.md)
* [Testēšana](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/testesana.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/seb-docs-draft/seb-docs-public-lv/integracija/tirgotaja-api/webhook.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.