> 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-lt/mokejimo-metodai/korteles/issaugoti-duomenys/prekybininko-inicijuotos-transakcijos-mit.md).

# Prekybininko inicijuotos transakcijos (MIT)

Nuskaičiuokite išsaugotus mokėjimo duomenis klientui nedalyvaujant – prenumeratoms, pasikartojantiems mokesčiams ir vėlesniems mokėjimams.

Prekybininko inicijuotas sandoris (MIT) – tai mokėjimas, kurį tiesiogiai inicijuoja prekybininkas, o klientas jo vykdymo metu aktyviai nedalyvauja. MIT tinka prenumeratoms, pasikartojantiems mokesčiams, rinkliavoms ir kitiems vėlesniems mokėjimams, kai kliento sutikimas jau gautas anksčiau.

MIT vykdomi naudojant anksčiau kliento išsaugotus mokėjimo duomenis ir turi remtis sutikimu, nustatytu pradiniame Kliento inicijuotame sandoryje (CIT). SEB Ecommerce Payment Gateway MIT apdoroja pagal Visa ir Mastercard Stored Credential Framework.

{% hint style="info" %}
Prekybininko inicijuoti sandoriai palaikomi tik tiems mokėjimo būdams, kurie leidžia saugoti kredencialus ir juos tokenizuoti – šiuo metu tai mokėjimai kortele.
{% endhint %}

### Galimybių santrauka

<table><thead><tr><th width="334.66668701171875" valign="top">Galimybė</th><th valign="top">Palaikymas</th></tr></thead><tbody><tr><td valign="top">Mokėjimo būdai</td><td valign="top">Mokėjimo kortelės (Visa, Mastercard)</td></tr><tr><td valign="top">Būtina sąlyga</td><td valign="top">Sėkmingas pradinis Kliento inicijuotas sandoris (CIT) su išsaugotais kredencialais</td></tr><tr><td valign="top">Kliento dalyvavimas</td><td valign="top">Nėra – vykdymo metu klientas nedalyvauja</td></tr><tr><td valign="top">Autentifikavimas</td><td valign="top">EMV® 3DS užklausėjo inicijuotas (3RI), kai taikoma</td></tr><tr><td valign="top">Tokenizavimas</td><td valign="top">Vidiniai (šliuzo) ir tinklo žetonai (Visa TMS, Mastercard SCOF)</td></tr><tr><td valign="top">Inicijavimas</td><td valign="top">Prekybininko API – mokėjimus inicijuoja jūsų sistemos</td></tr><tr><td valign="top">Tvarkaraštis</td><td valign="top">Vykdo jūsų sistemos; šliuzas mokėjimų nesuplanuoja</td></tr><tr><td valign="top">Veiksmai po mokėjimo</td><td valign="top">Įskaitymas, grąžinimas ir atšaukimas standartiniais srautais</td></tr><tr><td valign="top">Būsenos pranešimai</td><td valign="top">Atgaliniai pranešimai (webhook'ai)</td></tr><tr><td valign="top">Testavimas Sandbox aplinkoje</td><td valign="top">Galima</td></tr></tbody></table>

&#x20;

Atskirų galimybių prieinamumas priklauso nuo jūsų prekybininko sutarties, įgalintų paslaugų ir įsigyjančiojo banko konfigūracijos.

### Būtinos sąlygos

Prieš pradėdami apdoroti prekybininko inicijuotus sandorius:

1. Atlikite pradinį Kliento inicijuotą sandorį, kurio metu klientas aiškiai sutinka, kad jo mokėjimo kredencialai būtų saugomi naudojimui ateityje. Žr. [Kliento inicijuoti sandoriai (CIT)](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/issaugoti-duomenys/kliento-inicijuotos-transakcijos-cit.md).
2. Gaukite ir saugokite žetono ID. Pradinio mokėjimo metu šliuzas saugiai išsaugo kliento mokėjimo kredencialus ir sugeneruoja žetoną. Žetono ID jums grąžinamas kartu su kitais mokėjimo duomenimis.
3. Išsaugokite kliento sutikimo įrodymus – pavyzdžiui, atsiskaitymo modelį, periodiškumą, sumas ir atšaukimo procesą, kuriam klientas pritarė. Kiekvienas MIT turi remtis šiuo sutikimu.

{% hint style="info" %}
Nepradėkite prekybininko inicijuotų sandorių be galiojančio, sėkmingo pradinio CIT. Jei pradinis CIT buvo atmestas arba nutrauktas, sutikimo ryšys neegzistuoja ir išsaugoti kredencialai negali būti apmokestinti.
{% endhint %}

### Mokėjimo srautas

Prekybininko inicijuotas sandoris apdorojamas dviem žingsniais per Prekybininko API:

1. Inicijuokite mokėjimą. Jūsų sistema inicijuoja mokėjimą, pateikdama sumą ir valiutą, pirkinių krepšelio duomenis ir kitą būtiną mokėjimo informaciją. Šliuzas grąžina inicijuoto mokėjimo ID.
2. Nuskaičiuokite išsaugotą kredencialą. Jūsų sistema nuskaičiuoja mokėjimą išsiųsdama užklausą, kurioje nurodomas anksčiau išsaugotas žetonas. Kliento sąveikos nereikia.

Šliuzas išsprendžia žetoną ir apdoroja sandorį per standartinį autorizavimo srautą. Leidėjas kiekvieną mokėjimą autorizuoja pagal taikomas kortelių schemos taisykles ir savo rizikos vertinimą. Galutinė mokėjimo būsena grąžinama API atsakyme ir, jei sukonfigūruota, jūsų sistemoms pristatoma per atgalinius pranešimus (webhook'us).

Po autorizavimo standartinės mokėjimo po sandorio operacijos – įskaitymas, grąžinimas ir atšaukimas – galimos tais pačiais srautais kaip ir kitiems mokėjimams kortele. Žr. [Palaikomos operacijos](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/palaikomos-operacijos.md).

### Dažniausi naudojimo atvejai

Prekybininko inicijuoti sandoriai apima mokėjimo scenarijus, kai nuskaičiavimą inicijuoja jūsų sistemos, o ne klientas:

* Pasikartojantys mokėjimai. Fiksuotos sumos nuskaičiavimai sutartais intervalais – mėnesinės prenumeratos, metiniai pratęsimai, narystės, draudimo įmokos.
* Mokėjimai dalimis. Pirkimo suma padalijama į suplanuotas dalis, dėl kurių sutarta su klientu.
* Naudojimu pagrįstas atsiskaitymas. Skirtingos sumos arba laiko nuskaičiavimai pagal faktinį naudojimą – pavyzdžiui, apskaitomoms paslaugoms ar papildymams – laikantis sąlygų, kurioms klientas pritarė.
* Atidėti arba vėlesni nuskaičiavimai. Vėlesnės sumos surenkamos po pradinio pirkimo, kai dėl to buvo susitarta su klientu.
* Mokesčiai. Sąskaitos ar paslaugų mokesčiai, surenkami pagal nuolatinį kliento sutikimą.

Kad ir koks būtų scenarijus, prekybininko inicijuotų nuskaičiavimų sumos, laikas ir sąlygos turi likti pradinio CIT metu kliento suteikto sutikimo ribose.

### Autentifikavimas

Kadangi MIT metu klientas nedalyvauja, nuskaičiavimo metu kortelės turėtojo autentifikavimas nevyksta. Vietoj to:

* Stiprus kliento autentifikavimas (SCA), atliktas pradinio CIT metu, apima saugomų kredencialų ryšio nustatymą.
* Vėlesni MIT gali atitikti reguliavimo išimtis arba nepatekti į SCA taikymo sritį, atsižvelgiant į taikytinus teisės aktus. Galutinį autorizavimo sprendimą visada priima leidėjas.
* Jei taikoma, MIT gali naudoti EMV® 3DS užklausėjo inicijuotą (3RI) autentifikavimą kaip šliuzo 3DS palaikymo dalį.

Žr. [EMV® 3-D Secure (EMV 3DS) ir stiprus kliento autentifikavimas (SCA)](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/emv-r-3-d-secure-emv-3ds.md) dėl detalių.

### Atsakomybių pasiskirstymas

Šliuzas užtikrina saugų prekybininko inicijuotų mokėjimų vykdymą. Prenumeratos verslo logika išlieka jūsų atsakomybė. Norint teisingai integruoti, būtina suprasti šį pasidalijimą:

<table><thead><tr><th valign="top">Suteikia mokėjimo šliuzas</th><th valign="top">Jūsų atsakomybė</th></tr></thead><tbody><tr><td valign="top">Saugus pradinio CIT apdorojimas, įskaitant SCA, kai to reikalaujama</td><td valign="top">Kliento sutikimo įrodymų gavimas ir išsaugojimas</td></tr><tr><td valign="top">Saugų mokėjimo žetonų generavimas ir valdymas (PCI DSS)</td><td valign="top">Žetono ID saugojimas ir jo susiejimas su kliento profiliu</td></tr><tr><td valign="top">MIT vykdymas, nurodant saugomą žetoną, įskaitant 3RI palaikymą, kai taikoma</td><td valign="top">Mokėjimų planavimas – sprendimas, kada inicijuojamas kiekvienas nuskaičiavimas</td></tr><tr><td valign="top">Sandorio būsenos valdymas ir pranešimai realiuoju laiku (webhook'ai)</td><td valign="top">Pakartotinių bandymų valdymas atmestiems nuskaičiavimams ir prenumeratos būsenos atnaujinimams</td></tr><tr><td valign="top">Standartinės įskaitymo, grąžinimo ir atšaukimo operacijos</td><td valign="top">Atsiskaitymo plano konfigūravimas, sąskaitų faktūrų išrašymas ir komunikacija su klientu</td></tr><tr><td valign="top">Sandorių matomumas Prekybininko portale</td><td valign="top">Prenumeratos gyvavimo ciklo valdymas ir atšaukimo apdorojimas</td></tr></tbody></table>

{% hint style="info" %}
Šliuzas savarankiškai neplanuoja prenumeratos mokėjimų. Pasikartojantys sandoriai inicijuojami jūsų sistemų per API iškvietimus jūsų valdomais intervalais. Šliuzas taip pat neteikia atsiskaitymo plano konfigūravimo, sąskaitų faktūrų išrašymo ar prenumeratos verslo logikos.
{% endhint %}

### Atmetimų ir kortelių pakeitimų valdymas

MIT gali būti atmesti – pavyzdžiui, dėl nepakankamų lėšų, sustabdyto žetono arba leidėjo rizikos sprendimo. Šliuzas grąžina mokėjimo būseną API atsakyme ir per atgalinius pranešimus, sudarydamas galimybę jūsų sistemoms valdyti pakartotinius bandymus ir prenumeratos būsenos atnaujinimus.

Tvarkant atmetimus:

* Naudokite šliuzo grąžinamą mokėjimo būseną ir pranešimus savo pakartotinių bandymų bei įsiskolinimo valdymo logikai.
* Kai įgalintas tinklo tokenizavimas, kortelės pakartotinis išdavimas ir galiojimo pabaigos atnaujinimai kortelių schemų automatiškai pritaikomi išsaugotam žetonui – esama žetono nuoroda išlieka galiojanti, taip sumažinant atmetimus dėl pasenusių kortelės duomenų.
* Prenumeruokite žetono būsenos pranešimus. Jei žetonas sustabdytas arba deaktyvuotas, sustabdykite prekybininko inicijuojamus nuskaičiavimus ir paprašykite kliento iš naujo pateikti mokėjimo būdą per naują Kliento inicijuotą sandorį.
* Informuokite klientus apie nepavykusius nuskaičiavimus ir suteikite jiems galimybę atnaujinti mokėjimo būdą.

### Matomumas ir ataskaitos

Prekybininko inicijuoti ir su prenumeratomis susiję sandoriai matomi Prekybininko portale skiltyje „Užsakymai/Sandorių detalės“. Kai prenumeratos funkcionalumas įgalintas, sandorio detalės rodinyje nurodoma, ar sandoris yra pradinis Kliento inicijuotas sandoris (CIT), ar prekybininko inicijuotas sandoris (MIT), taip padedant sutikrinimui ir operaciniam tolesniam veiksmui.

### Geriausia prekybininkų praktika

Rekomenduojame prekybininkams:

* Prekybininko inicijuotus sandorius pradėkite tik po galiojančio, sėkmingo Kliento inicijuoto sandorio.
* Prekybininko inicijuotus nuskaičiavimus laikykite kliento sutikimo ribose – sumos, dažnumo ir sąlygų atžvilgiu.
* Prieš pasikartojančius nuskaičiavimus praneškite klientams, kai to reikalauja taikytini teisės aktai arba kortelių schemos taisyklės.
* Aiškiai nurodykite pasikartojančio atsiskaitymo sąlygas ir suteikite paprastą atšaukimo procesą.
* Stebėkite mokėjimų pranešimus, reguliariai sutikrinkite sandorius ir atnaujinkite prenumeratos būseną pagal patvirtintą mokėjimo būseną.
* Tinkamai tvarkykite pasibaigusio galiojimo, pakeistus arba deaktyvuotus žetonus, naudodami žetono būsenos pranešimus.
* Vietoje mokėjimo kortelių numerių saugojimo naudokite tokenizavimą ir laikykitės jūsų mokėjimo aplinkai tinkamų PCI DSS reikalavimų.

### Testavimas

Prieš apdorodami realius sandorius, užbaikite visą kūrimo ir validavimo darbą Sandbox aplinkoje. Prieš prašydami aktyvavimo gamybinėje aplinkoje, patikrinkite:

* Pradinis CIT su kliento sutikimo žingsniu ir sėkmingu žetono sukūrimu.
* MIT nuskaičiavimas, nurodantis saugomą žetoną, be kliento sąveikos.
* Atmestų MIT scenarijai ir jūsų pakartotinių bandymų bei pranešimų tvarkymas.
* Elgsena su sustabdytu arba deaktyvuotu žetonu.
* Atgaliniai arba webhook pranešimai ir prenumeratos būsenos atnaujinimai jūsų sistemose.
* Mokėjimų, inicijuotų prekybininko, grąžinimo ir atšaukimo apdorojimas.

### Dažniausiai užduodami klausimai

#### Ar MIT gali būti pirmasis kliento mokėjimas?

Ne. Prekybininko inicijuoti sandoriai reikalauja sėkmingo pradinio Kliento inicijuoto sandorio, kurio metu klientas aiškiai sutiko saugoti savo mokėjimo kredencialus. Būtent per tą mokėjimą sukurtas žetonas yra naudojamas jūsų MIT užklausose.

#### Ar šliuzas planuoja mano prenumeratos mokesčius?

Ne. Šliuzas vykdo jūsų inicijuotus sandorius, tačiau savarankiškai mokėjimų neplanuoja. Jūsų sistemos sprendžia, kada inicijuojamas kiekvienas nuskaičiavimas, ir atitinkamai kviečia Prekybininko API, naudodamos būsenos pranešimus prenumeratos būsenai valdyti.

#### Ar klientas užbaigia 3-D Secure MIT metu?

Ne. Klientas nedalyvauja, todėl nuskaičiavimo metu kortelės turėtojo autentifikavimas nevyksta. SCA, atliktas pradinio CIT metu, apima kredencialų nustatymą, o kai taikoma, šliuzas palaiko EMV® 3DS užklausėjo inicijuotą (3RI) autentifikavimą MIT sandoriams. Autorizavimo sprendimą priima leidėjas.

#### Ar galiu naudoti MIT su kitais mokėjimo būdais, ne kortelėmis?

Prekybininko inicijuoti sandoriai palaikomi tik tiems mokėjimo būdams, kurie leidžia saugoti kredencialus ir juos tokenizuoti – šiuo metu tai mokėjimai kortele. Sąskaitos į sąskaitą mokėjimo būdai taiko kitus modelius; žr. Pay by Bank.

#### Ką turėčiau daryti, kai MIT atmetamas?

Naudokite API atsakyme ir per webhook'us grąžinamą mokėjimo būseną savo pakartotinių bandymų logikai ir prenumeratos būsenos atnaujinimams. Jei atmetimą sukelia sustabdytas arba deaktyvuotas žetonas, paprašykite kliento iš naujo pateikti mokėjimo būdą per naują Kliento inicijuotą sandorį.

#### Ar galiu grąžinti prekybininko inicijuotą mokėjimą?

Taip. Įskaityti MIT mokėjimai gali būti grąžinami visiškai arba iš dalies naudojant standartinį grąžinimo srautą. Žr. Palaikomos operacijos.

### Susijusi dokumentacija

Tęskite su šiomis temomis:

* [Išsaugoti kredencialai](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/issaugoti-duomenys.md)
* [EMV® 3-D Secure](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/emv-r-3-d-secure-emv-3ds.md) (EMV 3DS)
* [Tokenizavimas](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/zetonizavimas.md)
* [Mokėjimai vienu paspaudimu](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/issaugoti-duomenys/atsiskaitymai-vienu-paspaudimu.md)
* [Kliento inicijuoti sandoriai](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/issaugoti-duomenys/kliento-inicijuotos-transakcijos-cit.md) (CIT)
* [Prekybininko API](/seb-docs-draft/seb-docs-public-lt/integracija/prekybininko-api.md)
* [Testavimas](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/testavimas.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-lt/mokejimo-metodai/korteles/issaugoti-duomenys/prekybininko-inicijuotos-transakcijos-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.
