> 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/kartes/saglabatie-maksajumu-akreditacijas-dati/tirgotaja-inicieti-darijumi-mit.md).

# Tirgotāja iniciēti darījumi (MIT)

Veiciet maksājumus, izmantojot saglabātos maksājumu akreditācijas datus, kad klients nav klāt — abonementiem, periodiskiem maksājumiem un turpmākajiem maksājumiem.

Tirgotāja iniciēts darījums (MIT) ir maksājums, ko tieši izveido tirgotājs, klientam izpildes brīdī aktīvi nepiedaloties. MIT ir piemēroti abonementiem, periodiskām maksām, maksām un citiem turpmākajiem maksājumiem, ja iepriekš ir saņemta klienta piekrišana.

MIT tiek veikti, izmantojot klienta iepriekš saglabātos maksājumu datus, un tajos jāatsaucas uz piekrišanu, kas iegūta sākotnējā klienta iniciētajā darījumā (CIT). SEB Ecommerce maksājumu vārteja apstrādā MIT saskaņā ar Visa un Mastercard Stored Credential Framework.

{% hint style="info" %}
Tirgotāja iniciētie darījumi tiek atbalstīti tikai tiem maksājuma veidiem, kas ļauj saglabāt datus un izmantot tokenizāciju – pašlaik karšu maksājumiem.
{% endhint %}

### Iespēju kopsavilkums

<table><thead><tr><th width="334.66668701171875" valign="top">Iespēja</th><th valign="top">Atbalsts</th></tr></thead><tbody><tr><td valign="top">Maksājuma veidi</td><td valign="top">Maksājumu kartes (Visa, Mastercard)</td></tr><tr><td valign="top">Priekšnosacījums</td><td valign="top">Veiksmīgs sākotnējais klienta iniciētais darījums (CIT) ar saglabātiem datiem</td></tr><tr><td valign="top">Klienta iesaiste</td><td valign="top">Nav – izpildes brīdī klienta līdzdalība nav nepieciešama</td></tr><tr><td valign="top">Autentifikācija</td><td valign="top">EMV® 3DS pēc pieprasījuma no darījuma iniciētāja (3RI), ja piemērojams</td></tr><tr><td valign="top">Tokenizācija</td><td valign="top">Iekšējie (vārtejas) un tīkla tokeni (Visa TMS, Mastercard SCOF)</td></tr><tr><td valign="top">Iniciēšana</td><td valign="top">Tirgotāja API – maksājumus iniciē jūsu sistēmas</td></tr><tr><td valign="top">Plānošana</td><td valign="top">To veic jūsu sistēmas; vārteja maksājumus neplāno</td></tr><tr><td valign="top">Darbības pēc maksājuma</td><td valign="top">Ieturēšana, naudas atmaksa un atcelšana, izmantojot standarta plūsmas</td></tr><tr><td valign="top">Statusa paziņojumi</td><td valign="top">Atzvanes paziņojumi (webhooki)</td></tr><tr><td valign="top">Testēšana Sandbox vidē</td><td valign="top">Pieejams</td></tr></tbody></table>

&#x20;

Atsevišķu iespēju pieejamība ir atkarīga no jūsu tirgotāja līguma, iespējotajiem pakalpojumiem un ekvairinga konfigurācijas.

### Priekšnosacījumi

Pirms varat apstrādāt tirgotāja iniciētus darījumus:

1. Pabeidziet sākotnējo klienta iniciēto darījumu, kura laikā klients nepārprotami piekrīt, ka viņa maksājumu dati var tikt saglabāti turpmākai izmantošanai. Skatiet [Klienta iniciētie darījumi (CIT)](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati/klienta-inicieti-darijumi-cit.md).
2. Saņemiet un saglabājiet tokena ID. Sākotnējā maksājuma laikā vārteja droši saglabā klienta maksājumu datus un ģenerē tokenu. Tokena ID jums tiek atgriezts kopā ar pārējām maksājuma detaļām.
3. Saglabājiet pierādījumus par klienta piekrišanu – piemēram, norēķinu modeli, biežumu, summām un atcelšanas procesu, kam klients ir piekritis. Katram MIT jāatsaucas uz šo piekrišanu.

{% hint style="info" %}
Neuzsāciet tirgotāja iniciētus darījumus bez derīga, veiksmīga sākotnējā CIT. Ja sākotnējais CIT tika noraidīts vai pārtraukts, nav piekrišanas attiecību un no saglabātajiem datiem nevar iekasēt maksu.
{% endhint %}

### Maksājuma plūsma

Tirgotāja iniciēts darījums tiek apstrādāts divos soļos, izmantojot Tirgotāja API:

1. Iniciējiet maksājumu. Jūsu sistēma iniciē maksājumu, norādot summu un valūtu, iepirkumu groza informāciju un citu nepieciešamo maksājuma informāciju. Vārteja atgriež iniciētā maksājuma ID.
2. Iekasējiet maksu no saglabātajiem datiem. Jūsu sistēma iekasē maksājumu, nosūtot pieprasījumu, kurā ir atsauce uz iepriekš saglabāto tokenu. Klienta iesaiste nav nepieciešama.

Vārteja atrisina tokenu un apstrādā darījumu, izmantojot standarta autorizācijas plūsmu. Emitents autorizē katru maksājumu saskaņā ar piemērojamajiem karšu shēmu noteikumiem un savu riska novērtējumu. Galīgais maksājuma statuss tiek atgriezts API atbildē un, ja konfigurēts, piegādāts jūsu sistēmām, izmantojot atzvanes paziņojumus (webhookus).

Pēc autorizācijas standarta darbības pēc maksājuma – ieturēšana, naudas atmaksa un atcelšana – ir pieejamas tajās pašās plūsmās kā citiem karšu maksājumiem. Skatiet [Atbalstītās darbības](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/atbalstitas-darbibas.md).

### Biežāk lietošanas gadījumi

Tirgotāja iniciētie darījumi aptver maksājumu scenārijus, kuros maksu ierosina jūsu sistēmas, nevis klients:

* Atkārtoti maksājumi. Fiksētas summas maksas saskaņotos intervālos – ikmēneša abonementi, gada atjaunošana, dalība, apdrošināšanas prēmijas.
* Nomaksas maksājumi. Pirkuma summa sadalīta plānotās daļās, par kurām vienojies klients.
* Maksājumi pēc lietojuma. Dažādas summas vai laika maksas, kuru pamatā ir faktiskais lietojums – piemēram, uzskaitītie pakalpojumi vai papildinājumi – saskaņā ar noteikumiem, kuriem klients ir piekritis.
* Aizkavētas vai sekojošas maksas. Pēc sākotnējā pirkuma iekasētas papildu summas, ja tas ir saskaņots ar klientu.
* Maksas. Konta maksas vai pakalpojumu maksas, kas iekasētas saskaņā ar klienta pastāvīgo piekrišanu.

Lai kāds būtu scenārijs, tirgotāja iniciēto maksu summām, laikam un nosacījumiem jāpaliek tajā piekrišanas tvērumā, ko klients sniedza sākotnējā CIT.

### Autentifikācija

Tā kā MIT laikā klients nav klātesošs, iekasēšanas brīdī netiek veikta karšu turētāja autentifikācija. Tā vietā:

* Stingrā klienta autentifikācija (SCA), kas veikta sākotnējā CIT, aptver saglabāto datu attiecību iestatīšanu.
* Turpmākie MIT var kvalificēties regulatīviem izņēmumiem vai būt ārpus SCA tvēruma, atkarībā no piemērojamajiem noteikumiem. Galīgais autorizācijas lēmums vienmēr paliek emitenta ziņā.
* Ja piemērojams, MIT var izmantot EMV® 3DS pēc pieprasījuma no darījuma iniciētāja (3RI) autentifikāciju kā daļu no vārtejas 3DS atbalsta.

Skatiet [EMV® 3-D Secure (EMV 3DS) un stingro klienta autentifikāciju (SCA)](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/emv-r-3-d-secure-emv-3ds.md) lai iegūtu sīkāku informāciju.

### Atbildības sadalījums

Vārteja nodrošina drošu tirgotāja iniciēto maksājumu izpildi. Abonementu biznesa loģika paliek jūsu ziņā. Šī sadalījuma izpratne ir būtiska pareizai integrācijai:

<table><thead><tr><th valign="top">Nodrošina maksājumu vārteja</th><th valign="top">Jūsu atbildība</th></tr></thead><tbody><tr><td valign="top">Sākotnējā CIT droša apstrāde, tostarp SCA, ja nepieciešams</td><td valign="top">Klienta piekrišanas pierādījumu iegūšana un saglabāšana</td></tr><tr><td valign="top">Drošu maksājumu tokenu ģenerēšana un pārvaldība (PCI DSS)</td><td valign="top">Tokena ID saglabāšana un tā piesaiste klienta profilam</td></tr><tr><td valign="top">MIT izpilde, atsaucoties uz saglabāto tokenu, tostarp 3RI atbalsts, ja piemērojams</td><td valign="top">Maksājumu plānošana – noteikšana, kad katra maksa tiek iniciēta</td></tr><tr><td valign="top">Darījuma statusa apstrāde un reāllaika paziņojumi (webhooki)</td><td valign="top">Atkārtotu mēģinājumu apstrāde noraidītām maksām un abonementa statusa atjauninājumi</td></tr><tr><td valign="top">Standarta ieturēšanas, naudas atmaksas un atcelšanas darbības</td><td valign="top">Norēķinu plāna konfigurēšana, rēķinu izrakstīšana un saziņa ar klientu</td></tr><tr><td valign="top">Darījumu redzamība Tirgotāja portālā</td><td valign="top">Abonementa dzīves cikla pārvaldība un atcelšanas apstrāde</td></tr></tbody></table>

{% hint style="info" %}
Vārteja neatkarīgi neplāno abonementu maksājumus. Atkārtotos darījumus jūsu sistēmas iniciē, izmantojot API zvanus jūsu pārvaldītajos intervālos. Vārteja arī nenodrošina norēķinu plāna konfigurēšanu, rēķinu izrakstīšanu vai abonementa biznesa loģiku.
{% endhint %}

### Noraidījumu un kartes maiņu apstrāde

MIT var tikt noraidīti – piemēram, nepietiekamu līdzekļu, apturēta tokena vai emitenta riska lēmuma dēļ. Vārteja atgriež maksājuma statusu API atbildē un ar atzvanes paziņojumiem, ļaujot jūsu sistēmām pārvaldīt atkārtotus mēģinājumus un abonementa statusa atjauninājumus.

Apstrādājot noraidījumus:

* Izmantojiet maksājuma statusu un vārtejas atgrieztos paziņojumus, lai vadītu savu atkārtoto mēģinājumu un parādu atgūšanas loģiku.
* Ja ir iespējota tīkla tokenizācija, kartes atkārtotas izsniegšanas un derīguma termiņa atjauninājumi kartes shēmās tiek automātiski piemēroti saglabātajam tokenam – esošā tokena atsauce paliek derīga, samazinot noraidījumus, ko izraisa novecojuši kartes dati.
* Piesakieties tokena statusa paziņojumiem. Ja tokens tiek apturēts vai deaktivizēts, apturiet tirgotāja iniciētās maksas un lūdziet klientam atkārtoti norādīt maksājuma veidu, veicot jaunu klienta iniciētu darījumu.
* Informējiet klientus par neveiksmīgiem maksājumiem un nodrošiniet viņiem iespēju atjaunināt maksājuma veidu.

### Redzamība un atskaites

Tirgotāja iniciētie un ar abonementu saistītie darījumi ir redzami Tirgotāja portālā sadaļā Pasūtījumu/darījumu informācija. Ja abonementa funkcionalitāte ir iespējota, darījuma detalizētajā skatā tiek norādīts, vai darījums ir sākotnējais klienta iniciētais darījums (CIT) vai tirgotāja iniciēts darījums (MIT), kas atvieglo saskaņošanu un operatīvo sekošanu.

### Tirgotāja labākā prakse

Mēs iesakām tirgotājiem:

* Sākt tirgotāja iniciētus darījumus tikai pēc derīga, veiksmīga klienta iniciēta darījuma.
* Turēt tirgotāja iniciētās maksas klienta piekrišanas tvērumā – summas, biežums un nosacījumi.
* Ja to pieprasa piemērojamie noteikumi vai karšu shēmu noteikumi, pirms atkārtotām maksām informējiet klientus.
* Skaidri komunicējiet atkārtotu norēķinu noteikumus un nodrošiniet vienkāršu atcelšanas procesu.
* Uzraugiet maksājumu paziņojumus, regulāri saskaņojiet darījumus un atjauniniet abonementa statusu, pamatojoties uz apstiprināto maksājuma statusu.
* Pienācīgi apstrādājiet tokena statusa paziņojumus, lai tiktu galā ar beigušos derīgumu, aizstātām vai deaktivizētām kartēm.
* Izmantojiet tokenizāciju, nevis maksājumu karšu numuru glabāšanu, un uzturiet PCI DSS atbilstību, kas atbilstoša jūsu maksājumu videi.

### Testēšana

Pabeidziet visu izstrādi un validāciju Sandbox vidē pirms dzīvo darījumu apstrādes. Pirms Production aktivizācijas pieprasīšanas pārbaudiet:

* Sākotnējo CIT ar klienta piekrišanas soli un veiksmīgu tokena izveidi.
* MIT maksu, kas atsaucas uz saglabāto tokenu, bez klienta iesaistes.
* Noraidītu MIT scenārijus un jūsu atkārtoto mēģinājumu un paziņojumu apstrādi.
* Uzvedību ar apturētu vai deaktivizētu tokenu.
* Atzvanes vai webhook paziņojumus un abonementa statusa atjauninājumus jūsu sistēmās.
* Naudas atmaksas un atcelšanas apstrādi tirgotāja iniciētajiem maksājumiem.

### Biežāk uzdotie jautājumi

#### Vai MIT var būt klienta pirmais maksājums?

Nē. Tirgotāja iniciētie darījumi prasa veiksmīgu sākotnējo klienta iniciēto darījumu, kurā klients nepārprotami piekrita saglabāt savus maksājumu datus. MIT pieprasījumi atsaucas uz tokenu, kas izveidots šī maksājuma laikā.

#### Vai vārteja plāno manus abonementa maksājumus?

Nē. Vārteja izpilda jūsu iniciētos darījumus, bet neatkarīgi maksājumus neplāno. Jūsu sistēmas nosaka, kad katra maksa tiek iniciēta, un attiecīgi izsauc Tirgotāja API, izmantojot statusa paziņojumus abonementa statusa pārvaldībai.

#### Vai klients MIT laikā pabeidz 3-D Secure?

Nē. Klients nav klātesošs, tāpēc iekasēšanas brīdī netiek veikta karšu turētāja autentifikācija. SCA, kas veikta sākotnējā CIT, aptver datu sagatavošanu, un, ja piemērojams, vārteja atbalsta EMV® 3DS Requestor-Initiated (3RI) autentifikāciju MIT. Autorizācijas lēmums paliek emitenta ziņā.

#### Vai es varu izmantot MIT ar citiem maksājuma veidiem, nevis kartēm?

Tirgotāja iniciētie darījumi tiek atbalstīti tikai tiem maksājuma veidiem, kas ļauj glabāt datus un tokenizāciju – pašlaik karšu maksājumiem. Maksājumi starp kontiem darbojas pēc citiem modeļiem; skatiet Pay by Bank.

#### Ko man darīt, ja MIT tiek noraidīts?

Izmantojiet maksājuma statusu, kas atgriezts API atbildē un ar webhooks, lai vadītu savu atkārtoto mēģinājumu loģiku un abonementa statusa atjauninājumus. Ja noraidījumu izraisa apturēts vai deaktivizēts tokens, lūdziet klientam atkārtoti norādīt maksājuma veidu, veicot jaunu klienta iniciētu darījumu.

#### Vai es varu atmaksāt tirgotāja iniciētu maksājumu?

Jā. Ieturētie MIT maksājumi var tikt atmaksāti pilnībā vai daļēji, izmantojot standarta atmaksas plūsmu. Skatiet Atbalstītās darbības.

### Saistītā dokumentācija

Turpiniet ar šādām tēmām:

* [Saglabātie dati](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati.md)
* [EMV® 3-D Secure](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/emv-r-3-d-secure-emv-3ds.md) (EMV 3DS)
* [Tokenizācija](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/tokenizacija.md)
* [Maksājumi ar vienu klikšķi](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati/maksajumi-ar-vienu-klikski.md)
* [Klienta iniciētie darījumi](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati/klienta-inicieti-darijumi-cit.md) (CIT)
* [Tirgotāja API](/seb-docs-draft/seb-docs-public-lv/integracija/tirgotaja-api.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/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati/tirgotaja-inicieti-darijumi-mit.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.