> 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/darbo-pradzia/zodynelis.md).

# Žodynėlis

Sąvokų, su kuriomis susidursite dokumentacijoje ir valdymo skydelyje, apibrėžimai.

Paprastų terminų apibrėžimai, naudojami visoje platformoje. Spustelėkite bet kurį įrašą, kad jį išskleistumėte.

***

## A — F

<details>

<summary>Mokėjimas iš sąskaitos į sąskaitą (A2A) per banką</summary>

### Apibrėžimas

Mokėjimai iš sąskaitos į sąskaitą (A2A) yra elektroniniai mokėjimai, atliekami tiesiogiai iš mokėtojo banko sąskaitos į prekybininko banko sąskaitą, nenaudojant mokėjimo kortelės.

A2A mokėjimai paprastai inicijuojami per atvirąją bankininkystę arba kitas reglamentuojamas banko mokėjimo paslaugas, leidžiančias klientams saugiai autorizuoti mokėjimus naudojant savo internetinės ar mobiliosios bankininkystės programėlę.

### Pagrindiniai privalumai

* Tiesioginis mokėjimų apdorojimas iš banko į banką
* Mokėjimo kortelė nereikalinga
* Mažesnės mokėjimų apdorojimo išlaidos
* Greitas mokėjimo patvirtinimas
* Stiprus kliento autentifikavimas (SCA), kurį palaiko kliento bankas
* Mažesnė su kortelėmis susijusio sukčiavimo rizika

### Kaip tai veikia

1. Atsiskaitymo metu klientas pasirenka mokėjimą per banką.
2. Klientas pasirenka savo banką.
3. Kliento tapatybę saugiai patvirtina jo bankas.
4. Mokėjimas autorizuojamas.
5. Prekybininkas gauna mokėjimo patvirtinimą ir užbaigia užsakymą.

</details>

<details>

<summary>Prieigos kontrolės serveris (ACS)</summary>

EMV® 3-D Secure (3DS) infrastruktūros komponentas, paprastai valdomas kortelės leidėjo arba jo vardu. ACS autentifikuoja kortelės turėtoją mokėjimo proceso metu, nustato, ar reikalingas papildomas patvirtinimas (challenge), ir grąžina autentifikavimo rezultatą, kad būtų užtikrintas saugus sandorio autorizavimas.

</details>

<details>

<summary>Programavimo sąsaja (API)</summary>

Programavimo sąsaja (API) yra taisyklių ir galinių taškų rinkinys, leidžiantis programinėms sistemoms bendrauti tarpusavyje. Mokėjimų vartuose API leidžia prekybininkams integruoti savo programas su vartais ir atlikti tokias operacijas kaip mokėjimų sukūrimas, mokėjimo informacijos gavimas, grąžinimų apdorojimas, žetonų valdymas ir mokėjimo būsenos atnaujinimų gavimas.

</details>

<details>

<summary>Autentifikavimas</summary>

Mokėtojo tapatybės patvirtinimo procesas prieš autorizuojant mokėjimą. Autentifikavimas padeda patvirtinti, kad asmuo, inicijuojantis sandorį, yra teisėtas kortelės turėtojas arba sąskaitos savininkas, ir sumažina sukčiavimo riziką.

Kortelių mokėjimams autentifikavimas paprastai atliekamas naudojant EMV® 3-D Secure (3DS), kuris gali apimti biometrinį patvirtinimą, vienkartinį slaptažodį (OTP) arba kitus kortelės leidėjo teikiamus autentifikavimo metodus.

</details>

<details>

<summary>Authorization</summary>

Autorizavimas yra procesas, kurio metu kortelės leidėjas nustato, ar mokėjimas gali būti patvirtintas. Autorizacijos metu leidėjas patikrina mokėjimo duomenis, įsitikina, kad kortelė galioja, patvirtina, jog pakanka lėšų arba kredito limito, atlieka sukčiavimo ir rizikos patikras ir pateikia patvirtinimo arba atmetimo atsakymą.

Mokėjimams, kurie yra autorizuoti, bet ne iš karto užbaigti, autorizuota suma gali būti rezervuota kortelės turėtojo sąskaitoje, kol ji bus nuskaičiuota arba kol pasibaigs autorizacijos galiojimas.

</details>

<details>

<summary>Banko identifikavimo numeris (BIN)</summary>

Banko identifikavimo numeris (BIN), dar vadinamas leidėjo identifikavimo numeriu (IIN), yra pirmi 6–8 mokėjimo kortelės numerio skaitmenys. BIN identifikuoja kortelės leidėją ir kortelių tinklą, pavyzdžiui, Visa arba Mastercard.

BIN informacija gali būti naudojama identifikuoti:

* Kortelių tinklą (pavyzdžiui, Visa arba Mastercard).
* Finansinę instituciją, kuri išdavė kortelę.

Mokėjimų vartai gali naudoti BIN informaciją mokėjimų maršrutizavimui, sukčiavimo prevencijai ir su kortele susijusios informacijos rodymui.

</details>

<details>

<summary>Anuliavimas</summary>

Anuliavimas yra autorizuoto mokėjimo atšaukimo procesas prieš jį nuskaitant. Kai mokėjimas anuliuojamas, autorizacija atšaukiama ir lėšos prekybininkui nepervedamos.

Mokėjimas gali būti anuliuotas tik tada, jei jis buvo autorizuotas, bet dar nenuskaitomas. Kai mokėjimas jau nuskaitomas, jo anuliuoti nebegalima. Jei prekybininkui po nurašymo reikia grąžinti lėšas, vietoje to turi būti inicijuojamas grąžinimas.

</details>

<details>

<summary>Nurašymas</summary>

Nurašymas yra anksčiau autorizuoto mokėjimo užbaigimo procesas, prašant pervesti autorizuotas lėšas iš kortelės turėtojo sąskaitos prekybininkui.

Priklausomai nuo prekybininko nustatymų, mokėjimai gali būti nurašomi automatiškai iš karto po sėkmingo autorizavimo arba rankiniu būdu vėliau.

Mokėjimas gali būti nurašytas tik po to, kai jis sėkmingai autorizuojamas.

</details>

<details>

<summary>Kortelių tinklas (kortelių schema)</summary>

Kortelių tinklas, dar vadinamas kortelių schema, yra mokėjimų tinklas, nustatantis taisykles, standartus ir infrastruktūrą kortelių mokėjimams apdoroti. Kortelių tinklai sujungia kortelių leidėjus, įsigyjančiuosius bankus, prekybininkus ir mokėjimo paslaugų teikėjus, kad būtų galima saugiai ir patikimai vykdyti mokėjimo operacijas.

Didžiųjų kortelių tinklų pavyzdžiai:

* Visa
* Mastercard
* American Express
* UnionPay
* JCB
* Discover

Kortelių tinklai nustato mokėjimų apdorojimo, saugumo reikalavimų, ginčų nagrinėjimo ir atsiskaitymo taisykles bei taiko tinklo mokesčius operacijoms, apdorotoms per jų sistemas.

</details>

<details>

<summary>Kortelė nepateikiama (CNP)</summary>

Kortelė nepateikiama (CNP) sandoris yra kortelės mokėjimas, kai fizinė mokėjimo kortelė pirkimo metu nepateikiama prekybininkui.

Dažniausi CNP sandorių pavyzdžiai:

* El. prekybos (internetiniai) mokėjimai
* Mokėjimai programėlėse
* Paštu / telefonu užsakomi (MOTO) mokėjimai

Kadangi kortelė fiziškai nepateikiama, CNP sandoriai paprastai kelia didesnę sukčiavimo riziką nei kortelės pateikiamos (CP) sandoriai. Siekdami sumažinti šią riziką, prekybininkai paprastai naudoja saugumo priemones, tokias kaip EMV® 3-D Secure (3DS), sukčiavimo prevencijos įrankiai ir rizika pagrįstas autentifikavimas.

</details>

<details>

<summary>Kortelės numeris (PAN)</summary>

Pagrindinis sąskaitos numeris (PAN) yra unikalus mokėjimo kortelei priskirtas numeris. Jis identifikuoja kortelę ir naudojamas mokėjimo sandoriams apdoroti.

Pirmieji 6–8 PAN skaitmenys sudaro banko identifikavimo numerį (BIN) arba leidėjo identifikavimo numerį (IIN), kuris identifikuoja kortelės leidėją ir kortelių tinklą.

Kortelė nepateikiama (CNP) sandoriuose PAN paprastai naudojamas kartu su kortelės saugos kodu (CVV/CVC) ir, kai taikoma, EMV® 3-D Secure (3DS) autentifikavimu.

{% hint style="warning" %}
Prekybininkai turėtų vengti saugoti ar apdoroti neapdorotus PAN duomenis, nebent jie turi tam teisę ir laikosi taikomų PCI DSS reikalavimų.
{% endhint %}

</details>

<details>

<summary>Kortelės duomenys saugomi faile (CoF)</summary>

Kortelės duomenys saugomi faile (CoF) reiškia saugų kliento mokėjimo kortelės duomenų arba mokėjimo žetono saugojimą būsimiems sandoriams. Tai leidžia klientams pakartotinai pirkti iš naujo neįvedant kortelės informacijos.

Kortelės duomenys saugomi faile gali būti naudojami:

* Mokėjimams vienu spustelėjimu
* Pasikartojantiems mokėjimams (prenumeratoms)
* Neplanuotoms prekybininko inicijuojamoms operacijoms (MIT)
* Kitiems kliento autorizuotiems pakartotiniams mokėjimams

Prekybininkai neturėtų saugoti neapdorotų kortelės duomenų, nebent jie turi tam teisę ir laikosi taikomų PCI DSS reikalavimų. Kaip alternatyvą, Mokėjimų vartai palaiko žetonizaciją, leidžiančią prekybininkams saugoti ir naudoti mokėjimo žetonus vietoje jautrių kortelės duomenų.

</details>

<details>

<summary>Kortelės patvirtinimo vertė (CVV/CVC/CID)</summary>

Kortelės patvirtinimo vertė (CVV/CVC/CID) yra 3 arba 4 skaitmenų saugos kodas, atspausdintas ant mokėjimo kortelės. Jis daugiausia naudojamas kortelėms nepateikiamiems (CNP) sandoriams, siekiant patikrinti, kad klientas fiziškai turi kortelę.

Saugos kodas skirtinguose kortelių tinkluose vadinamas skirtingai:

* Visa – Kortelės patvirtinimo vertė (CVV/CVV2)
* Mastercard – Kortelės patvirtinimo kodas (CVC/CVC2)
* American Express – Kortelės identifikavimo numeris (CID)
* Discover – Kortelės identifikavimo numeris (CID)

Saugumo ir PCI DSS atitikties sumetimais prekybininkai niekada neturi saugoti kortelės saugos kodo po to, kai sandoris buvo autorizuotas, net ir naudodami žetonizaciją ar kortelės duomenų saugojimo faile paslaugas.

</details>

<details>

<summary>Kortelės turėtojas</summary>

Kortelės turėtojas yra fizinis arba juridinis asmuo, kuriam kortelės leidėjas išdavė mokėjimo kortelę ir kuris yra įgaliotas naudoti tą kortelę pirkimams arba kitoms mokėjimo operacijoms atlikti.

Kortelės turėtojas inicijuoja mokėjimą ir, kai to reikalaujama, užbaigia autentifikavimo procesą (pavyzdžiui, naudodamas EMV® 3-D Secure (3DS)) prieš autorizuojant sandorį.

</details>

<details>

<summary>Kortelės</summary>

Mokėjimo kortelės yra kortelių leidėjo išduotos mokėjimo priemonės, leidžiančios klientams atlikti mokėjimus be grynųjų pinigų fizinėse parduotuvėse, internetu arba mobiliosiose programėlėse. Mokėjimo kortelės gali būti fizinės arba virtualios ir paprastai išduodamos kaip:

* Debeto kortelės
* Kredito kortelės
* Išankstinio mokėjimo kortelės

Dauguma mokėjimo kortelių veikia kortelių tinkle, pavyzdžiui, Visa arba Mastercard, ir taip pat gali būti įtrauktos į skaitmenines pinigines, tokias kaip Apple Pay ar Google Pay, kad būtų galima saugiai atlikti bekontakčius ir internetinius mokėjimus.

</details>

<details>

<summary>Atgalinis nurašymas</summary>

Atgalinis nurašymas yra procesas, kai kortelės turėtojas ginčija kortelės sandorį per savo kortelės leidėją ir prašo grąžinti sandorio sumą.

Atgaliniai nurašymai gali įvykti dėl įvairių priežasčių, įskaitant:

* Sukčiavimo arba neautorizuotos operacijos
* Negautos prekės ar paslaugos
* Apdorojimo arba autorizavimo klaidos
* Dvigubos operacijos
* Kliento ginčai dėl pirkinio

Kai inicijuojamas atgalinis nurašymas, prekybininkas gali turėti galimybę jį užginčyti pateikdamas patvirtinamuosius įrodymus, tokius kaip pristatymo įrodymas, sandorio įrašai ar kita dokumentacija. Įrodymai pateikiami per įsigyjantįjį banką, kuris atstovauja prekybininkui atgalinio nurašymo proceso metu.

</details>

<details>

<summary>Ginčijimas</summary>

Ginčijimas yra procesas, kai prekybininkas ginčija kortelės turėtojo per savo kortelės leidėją inicijuotą atgalinį nurašymą.

Jei prekybininkas mano, kad sandoris buvo teisėtas, jis gali per savo įsigyjantįjį banką pateikti patvirtinamuosius įrodymus, kad užginčytų atgalinį nurašymą. Tipiniai įrodymai gali būti:

* Pristatymo arba paslaugos užbaigimo įrodymas
* Sandorio ir užsakymo duomenys
* Kliento komunikacija
* Autentifikavimo rezultatai (pvz., EMV® 3-D Secure (3DS))
* Bet kokia kita dokumentacija, pagrindžianti sandorio teisėtumą

Kortelės leidėjas peržiūri įrodymus pagal taikomas kortelių tinklo taisykles ir nustato, ar atgalinis nurašymas turėtų būti paliktas galioti, ar panaikintas.

{% hint style="info" %}
Ne visi atgaliniai nurašymai gali būti ginčijami. Galimybė ginčyti atgalinį nurašymą priklauso nuo kortelių tinklo taisyklių ir atgaliniam nurašymui priskirto priežasties kodo.
{% endhint %}

</details>

<details>

<summary>El. prekybos mokėjimai</summary>

El. prekybos mokėjimai, dar vadinami internetiniais mokėjimais, yra mokėjimo sandoriai, kuriuos klientai inicijuoja skaitmeniniais kanalais, pavyzdžiui, svetainėse, internetinėse parduotuvėse arba mobiliosiose programėlėse, siekdami įsigyti prekių ar paslaugų.

Mokėjimų vartai palaiko kelis internetinius mokėjimo būdus, įskaitant:

* Mokėjimo kortelės
* Skaitmeninės piniginės (pvz., Apple Pay, Google Pay, PayPal ir Click to Pay)
* Atvirosios bankininkystės mokėjimai, naudojant mokėjimo inicijavimo paslaugas (PIS)

El. prekybos mokėjimai yra kortelė nepateikiama (CNP) sandoriai, kai naudojama mokėjimo kortelė, ir gali reikėti kliento autentifikavimo, pavyzdžiui, EMV® 3-D Secure (3DS), siekiant sustiprinti saugumą.

</details>

<details>

<summary>EMV® 3-D Secure (EMV 3DS)</summary>

### Apibrėžimas

EMV® 3-D Secure (EMV 3DS), dažnai vadinamas 3DS2, yra pasaulinis internetinių kortelių mokėjimų autentifikavimo protokolas (kortelė nepateikiama arba CNP sandoriai). Sukurtas EMVCo, jis leidžia kortelių leidėjams patikrinti kortelės turėtojo tapatybę prieš autorizuojant internetinį mokėjimą.

Saugiai keičiantis autentifikavimo ir sandorio duomenimis tarp prekybininko, leidėjo ir kortelių tinklo, EMV 3DS padeda sumažinti sukčiavimą ir suteikia sklandesnę bei saugesnę atsiskaitymo patirtį.

### Pagrindiniai privalumai

* Sumažina internetinių mokėjimų sukčiavimą
* Didina mokėjimų autorizavimo rodiklius, sumažindamas klaidingus atmetimus
* Padeda įgyvendinti stipraus kliento autentifikavimo (SCA) reikalavimus pagal PSD2
* Pagerina kliento atsiskaitymo patirtį, nes autentifikavimas vyksta sklandžiai
* Optimizuota žiniatinklio, mobiliesiems įrenginiams ir programėlėse atliekamiems mokėjimams

### Autentifikavimo rezultatai

Priklausomai nuo leidėjo rizikos vertinimo, autentifikavimas gali baigtis:

* Sklandus autentifikavimas – sandoris autentifikuojamas nereikalaujant jokio papildomo kortelės turėtojo veiksmo.
* Papildomas autentifikavimas – kortelės turėtojo prašoma atlikti papildomą patvirtinimo veiksmą, pavyzdžiui, įvesti vienkartinį slaptažodį (OTP), patvirtinti sandorį savo bankininkystės programėlėje arba naudoti biometrinį autentifikavimą.

</details>

<details>

<summary>Sukčiavimas</summary>

Sukčiavimas yra tyčinis apgaulės naudojimas siekiant atlikti neautorizuotas arba neteisėtas mokėjimo operacijas. Sukčiavimas gali būti nukreiptas prieš kortelių turėtojus, prekybininkus, leidėjus arba kitus mokėjimų ekosistemos dalyvius.

Dažniausi mokėjimų sukčiavimo pavyzdžiai:

* Pavogtų arba pažeistų mokėjimo duomenų naudojimas be leidimo
* Tapatybės vagystė
* Sąskaitos perėmimas
* Kortelių testavimo atakos
* Draugiškas sukčiavimas (piktnaudžiavimas atgaliniais nurašymais)

Siekiant sumažinti sukčiavimo riziką, Mokėjimų vartai palaiko kelias saugumo priemones, įskaitant EMV® 3-D Secure (3DS), sukčiavimo prevencijos įrankius, rizika pagrįstą autentifikavimą, žetonizaciją ir operacijų stebėseną realiuoju laiku.

</details>

***

## G — P

<details>

<summary>Leidėjas (leidžiantis bankas)</summary>

Leidėjas, arba leidžiantis bankas, yra finansinė institucija, kuri klientui (kortelės turėtojui arba sąskaitos savininkui) suteikia mokėjimo kortelę arba mokėjimo sąskaitą.

Kortelių mokėjimų atveju leidėjas atsako už:

* Mokėjimo kortelės išdavimą
* Kortelės turėtojo autentifikavimą, kai to reikalaujama
* Mokėjimo sandorių autorizavimą arba atmetimą
* Kliento sąskaitos, turimų lėšų arba kredito limito valdymą

Atvirosios bankininkystės mokėjimų atveju leidėjas yra sąskaitą aptarnaujantis mokėjimo paslaugų teikėjas (ASPSP), kuris laiko kliento mokėjimo sąskaitą ir autorizuoja mokėjimo inicijavimą arba teikia sąskaitos informaciją.

</details>

<details>

<summary>Juridinis asmuo</summary>

Juridinis asmuo yra fizinis arba juridinis vienetas, kuris yra teisiškai pripažintas ir gali sudaryti sutartis, turėti turtą ir vykdyti verslo veiklą.

Mokėjimų vartų kontekste juridinis asmuo reiškia prekybininką arba įmonę, kuri sudaro sutartį su įsigyjančiuoju banku arba mokėjimo paslaugų teikėju, kad galėtų priimti mokėjimus.

Informacija, susijusi su juridiniu asmeniu, paprastai apima:

* Teisinį pavadinimą
* Registruotą adresą
* Verslo registracijos duomenis
* Mokesčių identifikavimo informaciją
* Įgaliotuosius atstovus

Ši informacija naudojama prekybininko įtraukimo ir vykdomų atitikties procesų metu, siekiant įvykdyti reguliavimo reikalavimus, įskaitant principo „Pažink savo klientą“ (KYC) ir kovos su pinigų plovimu (AML) įpareigojimus.

</details>

<details>

<summary>Pažink savo klientą (KYC)</summary>

Pažink savo klientą (KYC) yra klientų tapatybės nustatymo ir patvirtinimo procesas pagal taikomus reguliavimo reikalavimus, įskaitant kovos su pinigų plovimu (AML) ir kovos su terorizmo finansavimu (CTF) taisykles.

KYC patikros gali būti atliekamos prekybininko įtraukimo metu ir viso verslo santykių laikotarpiu, siekiant patikrinti fizinių arba juridinių asmenų tapatybę, įvertinti galimą riziką ir užtikrinti atitiktį taikomiems įstatymams bei mokėjimų pramonės reikalavimams.

Tipinė KYC informacija gali apimti:

* Tapatybės ir verslo registracijos duomenis
* Informaciją apie naudos gavėjus
* Verslo veiklą
* Patvirtinamuosius dokumentus, kurių reikalauja įsigyjantysis bankas arba mokėjimo paslaugų teikėjas

</details>

<details>

<summary>Prekybininkas</summary>

Prekybininkas yra verslas arba organizacija, kuri su SEB yra sudariusi prekybininko sutartį, kad per Mokėjimų vartus priimtų elektroninius mokėjimus.

Prekybininkai gali priimti mokėjimus už prekes ir paslaugas naudodami SEB įgalintus mokėjimo būdus, įskaitant mokėjimo korteles, skaitmenines pinigines ir atvirosios bankininkystės mokėjimus (kai taikoma).

Kai prekybininkas įtraukiamas, jis gauna prieigą prie Prekybininko portalo, kuriame gali konfigūruoti savo parduotuvę, generuoti API prisijungimo duomenis, valdyti mokėjimo nustatymus, stebėti sandorius ir pasiekti ataskaitas.

</details>

<details>

<summary>Prekybininko kategorijos kodas (MCC)</summary>

Prekybininko kategorijos kodas (MCC) yra keturių skaitmenų kodas, kurį įsigyjantysis bankas priskiria prekybininkui pagal pagrindinę prekybininko verslo veiklą.

MCC naudojamas mokėjimo tinklų ir finansinių institucijų, kad:

* Klasifikuotų prekybininko verslo tipą
* Taikytų kortelių tinklo taisykles ir tarpininkavimo mokesčius
* Palaikytų sukčiavimo prevenciją ir rizikos valdymą
* Nustatytų tam tikrų mokėjimo produktų arba kortelės turėtojo naudų tinkamumą

Jūsų MCC priskiriamas prekybininko įtraukimo į SEB procesą metu ir yra susietas su jūsų prekybininko sutartimi.

{% hint style="info" %}
Jei manote, kad jums priskirtas MCC tiksliai neatspindi jūsų verslo veiklos, susisiekite su SEB dėl pagalbos.
{% endhint %}

</details>

<details>

<summary>Mokėjimai vienu paspaudimu</summary>

Mokėjimai vienu spustelėjimu leidžia grįžtantiems klientams greičiau užbaigti būsimus pirkimus naudojant anksčiau išsaugotus mokėjimo duomenis.

Pradinio sandorio metu klientas pateikia savo mokėjimo duomenis ir sutinka, kad jie būtų naudojami ateityje. Vėlesniems pirkimams klientas gali užbaigti mokėjimą iš naujo neįvesdamas visų kortelės duomenų. Priklausomai nuo kortelės leidėjo reikalavimų ir taikomų teisės aktų, papildomas autentifikavimas (pavyzdžiui, EMV® 3-D Secure (3DS)) vis tiek gali būti reikalingas.

Mokėjimai vienu spustelėjimu įgyvendinami naudojant saugomus prisijungimo duomenis ir priskiriami kliento inicijuojamiems sandoriams (CIT).

</details>

<details>

<summary>Mokėjimų vartai</summary>

SEB el. prekybos mokėjimų vartai yra platforma, kuri leidžia prekybininkams saugiai priimti ir valdyti elektroninius mokėjimus per vieną integraciją.

Ji suteikia prieigą prie kelių mokėjimo būdų, įskaitant:

* Mokėjimo kortelės
* Skaitmeninės piniginės
* Atvirosios bankininkystės mokėjimai (mokėjimo inicijavimo paslaugos)

Mokėjimų vartai saugiai apdoroja mokėjimo užklausas, palaiko kliento autentifikavimą, nukreipia sandorius autorizavimui ir apdorojimui bei grąžina mokėjimo rezultatus prekybininkui. Ji taip pat teikia tokias paslaugas kaip Prekybininko portalas, Prekybininko API, talpinamas atsiskaitymas, žiniatinklio papildiniai, mobilieji SDK, žetonizacija ir EMV® 3-D Secure (3DS).

Prekybininkai prie Mokėjimų vartų prisijungia pagal savo su SEB sudarytą prekybininko sutartį, o SEB veikia kaip prekybininko įsigyjantis bankas.

</details>

<details>

<summary>PSD2 (Antroji mokėjimo paslaugų direktyva)</summary>

### Apibrėžimas

Antroji mokėjimo paslaugų direktyva (PSD2) yra Europos Sąjungos reglamentas, nustatantis teisinį pagrindą elektroniniams mokėjimams ir mokėjimo paslaugoms Europos ekonominėje erdvėje (EEE).

PSD2 įvedė griežtesnius elektroninių mokėjimų saugumo reikalavimus, padidino konkurenciją, įgalindama atvirąją bankininkystę, ir sustiprino vartotojų apsaugą.

### Pagrindiniai reikalavimai

PSD2 įvedė keletą svarbių pakeitimų mokėjimo paslaugų teikėjams ir prekybininkams, įskaitant:

* Stiprų kliento autentifikavimą (SCA) daugumai elektroninių mokėjimų
* Atvirąją bankininkystę, leidžiančią licencijuotiems trečiųjų šalių teikėjams, gavus kliento sutikimą, saugiai per API pasiekti banko paslaugas
* Sustiprintą vartotojų apsaugą ir mokėjimų skaidrumą
* Standartizuotus mokėjimo paslaugų teikėjų saugumo reikalavimus

### Poveikis prekybininkui

Prekybininkams PSD2 pirmiausia daro įtaką tam, kaip autentifikuojami internetiniai mokėjimai.

Priklausomai nuo mokėjimo būdo, klientams gali reikėti atlikti stiprų kliento autentifikavimą (SCA) prieš autorizuojant mokėjimą. Autentifikavimas paprastai atliekamas naudojant tokias technologijas kaip EMV® 3-D Secure kortelių mokėjimams arba kliento internetinės ar mobiliosios bankininkystės programėlę atvirosios bankininkystės mokėjimams.

Tam tikri sandoriai gali atitikti reguliavimo išimtis, kai tai leidžiama leidėjo ir taikomų teisės aktų.

</details>

<details>

<summary>PCI DSS savęs vertinimo klausimynas (SAQ)</summary>

### Apibrėžimas

PCI DSS savęs vertinimo klausimynas (SAQ) yra PCI Security Standards Council (PCI SSC) paskelbtas patvirtinimo įrankis. Jis leidžia tinkamiems prekybininkams ir paslaugų teikėjams įvertinti ir patvirtinti savo atitiktį Mokėjimo kortelių pramonės duomenų saugumo standartui (PCI DSS).

SAQ tipas, kurį prekybininkas turi užpildyti, priklauso nuo to, kaip jo mokėjimo aplinkoje priimami, apdorojami ar perduodami kortelės turėtojo duomenys.

### Įprasti SAQ tipai el. prekybai

Dažniausiai el. prekybos prekybininkams taikomi SAQ yra:

* SAQ A – prekybininkams, kurie visą kortelės turėtojo duomenų rinkimą, apdorojimą ir perdavimą visiškai perduoda PCI DSS atitinkančiam mokėjimo paslaugų teikėjui. Prekybininko sistemos nesaugo, neapdoroja ir neperduoda kortelės turėtojo duomenų.
* SAQ A-EP – prekybininkams, kurių mokėjimo puslapis gali paveikti mokėjimo sandorio saugumą, net jei kortelės turėtojo duomenis apdoroja PCI DSS atitinkantis mokėjimo paslaugų teikėjas.

### SEB Ecommerce Payment Gateway

SEB el. prekybos mokėjimų vartai atitinka PCI DSS 1 lygį, aukščiausią PCI DSS sertifikavimo lygį paslaugų teikėjams.

Priklausomai nuo pasirinkto integracijos būdo, jūsų PCI DSS patvirtinimo reikalavimai gali skirtis.

Svarbu: taikomas SAQ nustatomas pagal visą jūsų mokėjimo aplinką ir įgyvendinimą. Prekybininkai ir toliau atsako už savo PCI DSS atitikties reikalavimų įvertinimą.

</details>

***

## R — Z

<details>

<summary>Pasikartojantys mokėjimai</summary>

Pasikartojantys mokėjimai – tai mokėjimai, kurie automatiškai nurašomi sutartais intervalais (pavyzdžiui, kas savaitę, kas mėnesį arba kasmet) po to, kai klientas pateikė pradinį autorizavimą ir sutikimą.

Pasikartojantys mokėjimai dažniausiai naudojami:

* Prenumeratos paslaugoms
* Narystėms
* Komunalinėms sąskaitoms
* Kitiems reguliariai suplanuotiems mokėjimams

Mokėjimų vartai palaiko pasikartojančius mokėjimus, naudodami saugomus prisijungimo duomenis ir žetonizaciją, todėl prekybininkai gali saugiai inicijuoti būsimus mokėjimus nesaugodami jautrių kortelės duomenų. Priklausomai nuo mokėjimo scenarijaus ir taikomų teisės aktų, pradinis mokėjimas gali reikalauti EMV® 3-D Secure (3DS) autentifikavimo.

Pasikartojantys mokėjimai po pradinio kliento inicijuoto sandorio (CIT) priskiriami prekybininko inicijuojamiems sandoriams (MIT).

</details>

<details>

<summary>Pinigų grąžinimas</summary>

Grąžinimas yra lėšų grąžinimo klientui procesas po to, kai mokėjimas sėkmingai nuskaitomas.

Prekybininkai gali atlikti grąžinimą dėl įvairių priežasčių, pavyzdžiui:

* Atšaukto užsakymo
* Sugrąžintų prekių
* Paslaugos atšaukimo
* Kliento geranoriškumo
* Užsakymo koregavimų

Grąžinimus inicijuoja prekybininkas ir apdoroja per Mokėjimų vartus. Kai jie užbaigiami, lėšos grąžinamos į kliento mokėjimo sąskaitą pagal kortelių tinklo arba mokėjimo būdo taisykles.

</details>

<details>

<summary>Schemos mokestis</summary>

Schemos mokestis yra kortelių tinklo (pvz., Visa arba Mastercard) taikomas mokestis už kortelių mokėjimo sandorių apdorojimą per jo mokėjimų tinklą.

Schemos mokesčius nustato taikomas kortelių tinklas ir jie paprastai yra taikomi įsigyjančiajam bankui. Priklausomai nuo prekybininko sutarties, šie mokesčiai gali būti įtraukti į bendrus prekybininko mokėjimų apdorojimo mokesčius.

</details>

<details>

<summary>Jautrūs autentifikavimo duomenys (SAD)</summary>

Jautrūs autentifikavimo duomenys (SAD) yra su saugumu susijusi informacija, naudojama kortelės turėtojui autentifikuoti arba mokėjimo sandoriui autorizuoti.

Jautrių autentifikavimo duomenų pavyzdžiai:

* Kortelės patvirtinimo vertė (CVV/CVC/CID)
* PIN kodai ir PIN blokai
* Visi magnetinės juostos (takelio) duomenys
* Lustinės (EMV) autentifikavimo duomenys

Jautriems autentifikavimo duomenims taikomi griežti PCI DSS reikalavimai, ir jų negalima saugoti po mokėjimo autorizavimo, net jei prekybininkas atitinka PCI DSS.

</details>

<details>

<summary>Stiprus kliento autentifikavimas (SCA)</summary>

### Apibrėžimas

Stiprus kliento autentifikavimas (SCA) yra saugumo reikalavimas, įvestas Antrosios mokėjimo paslaugų direktyvos (PSD2), siekiant sumažinti sukčiavimą ir padidinti elektroninių mokėjimų saugumą Europos ekonominėje erdvėje (EEE).

SCA reikalauja, kad klientai patvirtintų savo tapatybę naudodami bent du nepriklausomus autentifikavimo veiksnius prieš autorizuojant tam tikrus elektroninius mokėjimus.

### Autentifikavimo veiksniai

SCA grindžiamas šiais autentifikavimo veiksniais:

* Žinojimas – kažkas, ką klientas žino, pavyzdžiui, slaptažodis arba PIN kodas.
* Turėjimas – kažkas, ką klientas turi, pavyzdžiui, mobilusis įrenginys, aparatinis žetonas arba vienkartinis slaptažodis (OTP).
* Būdingumas – kažkas, kas yra klientas, pavyzdžiui, piršto atspaudas, veido atpažinimas arba kitas biometrinis požymis.

Autentifikavimui turi būti naudojami bent du iš šių trijų veiksnių.

### Kaip taikomas SCA

Internetiniams kortelių mokėjimams SCA paprastai atliekamas naudojant EMV® 3-D Secure (EMV 3DS).

Atvirosios bankininkystės ir mokėjimų iš sąskaitos į sąskaitą (A2A) atveju autentifikavimas paprastai užbaigiamas per kliento internetinės arba mobiliosios bankininkystės programėlę.

Tam tikri sandoriai gali atitikti reguliavimo išimtis arba būti laikomi nepatenkančiais į taikymo sritį, atsižvelgiant į taikomus teisės aktus ir leidėjo rizikos vertinimą.

</details>

<details>

<summary>Prenumeratos</summary>

Prenumeratos yra pasikartojančių mokėjimų rūšis, kai klientui automatiškai nurašoma nustatytais intervalais (pavyzdžiui, kas savaitę, kas mėnesį arba kasmet) už nuolat teikiamą produktą ar paslaugą.

Dažniausi pavyzdžiai:

* Vaizdo ir muzikos transliavimo paslaugos
* Programinės įrangos prenumeratos (SaaS)
* Narystėms
* Komunalinių paslaugų arba paslaugų planai

Prenumeratos apdorojamos kaip prekybininko inicijuojami sandoriai (MIT) po pradinio kliento inicijuoto sandorio (CIT), kurio metu klientas suteikia sutikimą būsimiems pasikartojantiems mokesčiams.

</details>

<details>

<summary>Tokenizavimas</summary>

Žetonizacija yra jautrių mokėjimo duomenų, pavyzdžiui, pagrindinio sąskaitos numerio (PAN), pakeitimo unikaliu, nejautriu reikšmės vienetu, vadinamu žetonu, procesas.

Žetoną galima saugiai saugoti ir naudoti būsimoms mokėjimo operacijoms neatskleidžiant originalių kortelės duomenų. Žetonizacija padeda sumažinti jautrių mokėjimo duomenų tvarkymą ir padidina mokėjimų apdorojimo saugumą.

Mokėjimų vartai naudoja žetonizaciją tokioms funkcijoms kaip:

* Išsaugoti kredencialai
* Mokėjimai vienu paspaudimu
* Pasikartojantys mokėjimai (prenumeratos)
* Prekybininko inicijuojamos operacijos (MIT)

{% hint style="info" %}
Mokėjimo žetonas neturi jokios vidinės vertės už Mokėjimų vartų ribų ir negali būti naudojamas atkurti originalių kortelės duomenų.
{% endhint %}

</details>

<details>

<summary>Sandoris (Tx)</summary>

Sandoris (Tx) yra mokėjimo operacija, apdorojama per Mokėjimų vartus. Sandoris atspindi mokėjimo gyvavimo ciklą nuo inicijavimo iki autorizavimo, nurašymo, atsiskaitymo, grąžinimo ar anuliavimo, priklausomai nuo mokėjimo srauto.

Sandoriai gali būti inicijuojami naudojant palaikomus mokėjimo būdus, įskaitant:

* Mokėjimo kortelės
* Skaitmeninės piniginės
* Atvirosios bankininkystės mokėjimai (mokėjimo inicijavimo paslaugos)

Kiekvienam sandoriui priskiriamas unikalus mokėjimo ID, kurį galima naudoti mokėjimui identifikuoti, sekti ir suderinti viso jo gyvavimo ciklo metu.

</details>

<details>

<summary>Webhook</summary>

A **Webhook'ą (dar vadinamą atgalinio iškvietimo pranešimais)** yra HTTP pranešimas, siunčiamas Mokėjimų vartų į prekybininko nurodytą galinį tašką kiekvieną kartą, kai įvyksta mokėjimo įvykis.

Webhook pranešimai pateikia realiuoju laiku atnaujinamą informaciją apie mokėjimo būsenos pokyčius. Jie leidžia prekybininkams automatizuoti verslo procesus, tokius kaip:

* Užsakymo būsenos atnaujinimas
* Sėkmingų mokėjimų patvirtinimas
* Grąžinimų arba anuliavimų apdorojimas
* Atsiėmimo arba pristatymo procesų inicijavimas
* Mokėjimo sandorių suderinimas

Kiekviename webhook pranešime yra mokėjimo ID ir naujausia mokėjimo būsena. Gavę webhook, prekybininkai turėtų iškviesti Get Payment Information API, kad gautų visus ir naujausius mokėjimo duomenis.

{% hint style="info" %}
Kad gautų webhook pranešimus, prekybininkai turi sukonfigūruoti Callback URL Prekybininko portale.
{% endhint %}

</details>

***


---

# 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/darbo-pradzia/zodynelis.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.
