> 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/tokenizacija.md).

# Tokenizācija

Droši glabājiet un atkārtoti izmantojiet maksājumu akreditācijas datus, neapstrādājot sensitīvus karšu datus.

Tokenizācija ir process, kurā sensitīvi maksājumu dati, piemēram, Primārais konta numurs (PAN), tiek aizstāti ar unikālu, nesensitīvu vērtību, ko sauc par tokenu. Tokenu var droši uzglabāt un atkārtoti izmantot turpmākajiem maksājumiem, neatklājot sākotnējās kartes datus.

SEB Ecommerce maksājumu vārteja jūsu vārdā izveido un pārvalda tokenus. Tā vietā, lai uzglabātu kartes numurus, jūsu sistēmās tiek glabāta tikai vārtejas tokena atsauce – identifikators, ko iekļaujat turpmākajos maksājumu pieprasījumos. Visi sensitīvie kartes dati paliek vārtejas PCI DSS prasībām atbilstošajā vidē un nekad netiek atklāti jūsu sistēmām vai personālam.

Tokenizācija ir pamats šādām vārtejas funkcijām:

* [Saglabātie akreditācijas dati](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati.md) (Card-on-File)
* [Maksājumi ar vienu klikšķi](/seb-docs-draft/seb-docs-public-lv/funkcijas/maksajumi-ar-vienu-klikski.md)
* [Atkārtotie maksājumi](/seb-docs-draft/seb-docs-public-lv/funkcijas/periodiskie-maksajumi-un-abonementi.md) (Abonementi)
* [Tirgotāja iniciēti darījumi ](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati/tirgotaja-inicieti-darijumi-mit.md)(MIT)

{% hint style="info" %}
Maksājumu tokenam ārpus maksājumu vārtejas nav patstāvīgas vērtības, un to nevar izmantot, lai atjaunotu sākotnējos kartes datus.
{% endhint %}

### Iespēju kopsavilkums

<table><thead><tr><th valign="top">Iespēja</th><th valign="top">Atbalsts</th></tr></thead><tbody><tr><td valign="top">Maksājumu metodes</td><td valign="top">Maksājumu kartes (Visa, Mastercard)</td></tr><tr><td valign="top">Iekšējā (vārtejas) tokenizācija</td><td valign="top">Atbalstīts</td></tr><tr><td valign="top">Tīkla tokenizācija</td><td valign="top">Visa Token Management Service (TMS), Mastercard Secure Card on File (SCOF)</td></tr><tr><td valign="top">Tokenu glabātuve</td><td valign="top">PCI DSS prasībām atbilstoša, ko pārvalda maksājumu vārteja</td></tr><tr><td valign="top">Klienta iniciēti darījumi (CIT)</td><td valign="top">Atbalstīts</td></tr><tr><td valign="top">Tirgotāja iniciēti darījumi (MIT)</td><td valign="top">Atbalstīts, tostarp, ja piemērojams, EMV® 3DS Requestor-Initiated (3RI) autentifikācija</td></tr><tr><td valign="top">Tokenu dzīves cikla pārvaldība</td><td valign="top">Automātiski atjauninājumi no karšu shēmām (tīkla tokeni)</td></tr><tr><td valign="top">Tokenu statusa paziņojumi</td><td valign="top">Atpakaļizsaukuma paziņojumi (webhooks)</td></tr><tr><td valign="top">Integrācijas opcijas</td><td valign="top">Tirgotāja API, Hosted Checkout</td></tr><tr><td valign="top">Testēšana Sandbox vidē</td><td valign="top">Pieejams</td></tr></tbody></table>

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

### Kā darbojas tokenizācija

Tokens tiek izveidots sākotnējā klienta iniciētā darījumā (CIT), kurā klients skaidri piekrīt, ka viņa maksājumu akreditācijas dati var tikt saglabāti turpmākai lietošanai.

Tipiskais process ir šāds:

1. Sākotnējais maksājums (CIT). Klients veic maksājumu un piekrīt maksājumu akreditācijas datu saglabāšanai.
2. Tokena izveide. Vārteja droši saglabā maksājumu akreditācijas datus savā PCI DSS prasībām atbilstošajā tokenu glabātuvē un ģenerē tokenu. Atkarībā no jūsu konfigurācijas var tikt arī nodrošināts shēmas izdots tīkla tokens.
3. Atgriezta tokena atsauce. Tokena ID tiek atgriezts jums maksājuma atbildē kopā ar citu maksājuma informāciju. Saglabājiet šo atsauci savās sistēmās pie attiecīgā klienta profila.
4. Turpmākie maksājumi. Nākamajiem maksājumiem maksājuma pieprasījumā kartes datu vietā iekļaujiet tokena ID. Vārteja atpazīst tokenu un apstrādā darījumu, izmantojot standarta autorizācijas, norēķinu, atgriezeniskās darbības un atmaksas plūsmas.

Turpmākie maksājumi var būt gan klienta iniciēti darījumi (piemēram, maksājums ar vienu klikšķi, kamēr klients ir klātesošs), gan tirgotāja iniciēti darījumi (piemēram, ikmēneša abonēšanas maksa, kas tiek apstrādāta bez klienta aktīvas līdzdalības).

{% hint style="warning" %}
Kartes drošības kods (CVV/CVC) nekad netiek uzglabāts, pat ja tiek izmantota tokenizācija. Tā ir PCI DSS prasība, kas attiecas uz visiem tirgotājiem un pakalpojumu sniedzējiem.
{% endhint %}

### Tokenu veidi

Maksājumu vārteja atbalsta divus savstarpēji papildinošus tokenizācijas modeļus. Atkarībā no jūsu acquiring iestatījuma, shēmas dalības un tirgotāja konfigurācijas tie var darboties neatkarīgi vai kombinācijā. Abos modeļos jūs strādājat ar vienu vārtejas tokena atsauci – vārteja pārvalda pamatā esošos akreditācijas datus caurspīdīgi.

#### Iekšējie (vārtejas) tokeni

Izmantojot iekšējo tokenizāciju, sensitīvi kartes datu elementi tiek aizstāti ar drošu, vārtejas ģenerētu tokenu maksājumu vārtejas PCI DSS prasībām atbilstošajā vidē. Iekšējie tokeni tiek izmantoti tikai vārtejā darījumu apstrādei un akreditācijas datu atkārtotai izmantošanai.

Iekšējā tokenizācija:

* Noņem neapstrādātos kartes datus no jūsu sistēmām, samazinot PCI DSS atbilstības tvērumu.
* Iespējo maksājumus ar vienu klikšķi, atkārtotus darījumus un abonēšanas pakalpojumus.
* Samazina kartes turētāja datu noplūdes risku.

#### Tīkla tokeni

Izmantojot tīkla tokenizāciju, sākotnējais PAN tiek aizstāts ar tīkla tokenu, ko izsniedz un pārvalda pati karšu shēma. Vārteja integrējas ar karšu shēmas tokenizācijas pakalpojumiem, lai nodrošinātu, uzglabātu un izmantotu tīkla tokenus darījumu apstrādei:

* Visa Token Management Service (TMS) Visa kartes akreditācijas datiem.
* Mastercard Secure Card on File (SCOF) un saistītie Mastercard tokenu dzīves cikla pakalpojumi (tostarp mantotās MDES bāzētās integrācijas) Mastercard kartes akreditācijas datiem.

Tīkla tokeni atbilst EMV® Payment Tokenisation Specification un ir piesaistīti konkrētam tirgotāja kontekstam, kas padara tos nelietojamus, ja tie tiek pārtverti. Katrs darījums papildus tiek aizsargāts ar shēmas līmeņa validāciju.

Papildus drošībai tīkla tokeni sniedz arī praktiskus biznesa ieguvumus:

* Automātiski akreditācijas datu atjauninājumi. Kad pamatā esošā karte tiek atkārtoti izdota, nomainīta vai mainās tās derīguma termiņš, karšu shēma tokenu atjaunina automātiski. Saglabātie akreditācijas dati turpina darboties, nelūdzot klientam vēlreiz ievadīt kartes datus – īpaši vērtīgi abonementiem un atkārtotai norēķinu iekasēšanai.
* Augstāks apstiprināšanas rādītājs. Izdevēji parasti apstiprina tokenizētus darījumus biežāk nekā darījumus, kas balstīti uz PAN, jo shēma pirms autorizācijas sasniegšanas izdevēju iepriekš validē katru tokenu. Karšu shēmas ziņo par izmērāmi augstākiem tokenizētu karšu, kas nav klāt pie norēķina, darījumu apstiprināšanas rādītājiem.
* Mazāka maksājumu berze. Mazāk atteikumu novecojušu vai nomainītu karšu dēļ nozīmē mazāk pārtrauktu abonementu un mazāku piespiedu klientu aizplūšanu.

#### Salīdzinājums

<table><thead><tr><th width="146" valign="top">Aspekts</th><th valign="top">Iekšējais (vārtejas) tokens</th><th valign="top">Tīkla tokens</th></tr></thead><tbody><tr><td valign="top">Izsniedz</td><td valign="top">SEB Ecommerce maksājumu vārteja</td><td valign="top">Karšu shēma (Visa, Mastercard)</td></tr><tr><td valign="top">Aizstāj</td><td valign="top">PAN vārtejas vidē</td><td valign="top">PAN maksājumu tīklā</td></tr><tr><td valign="top">Dzīves ciklu pārvalda</td><td valign="top">Maksājumu vārteja</td><td valign="top">Karšu shēma; vārteja apstrādā dzīves cikla notikumus un atjaunina savus ierakstus</td></tr><tr><td valign="top">Automātiski karšu atjauninājumi</td><td valign="top">Nav piemērojams</td><td valign="top">Jā (atkārtota izdošana, derīguma termiņa atjauninājumi, aizstāšana)</td></tr><tr><td valign="top">Apstiprināšanas rādītāja pieaugums</td><td valign="top">–</td><td valign="top">Jā, par tokenizētiem darījumiem ziņo karšu shēmas</td></tr><tr><td valign="top">PCI DSS tvēruma samazināšana</td><td valign="top">Jā</td><td valign="top">Jā</td></tr><tr><td valign="top">Tirgotāja integrācija</td><td valign="top">Vārtejas tokena atsauce</td><td valign="top">Vārtejas tokena atsauce (tīkla tokens ir caurspīdīgs tirgotājam)</td></tr></tbody></table>

{% hint style="info" %}
Jūs nekad tieši neapstrādājat tīkla tokenus. Kad tiek nodrošināts tīkla tokens, vārteja to droši glabā savā tokenu glabātuvē, sasaista to ar attiecīgo tirgotāja vai klienta profilu un turpmākajiem CIT un MIT maksājumiem nodrošina jums vārtejas tokena atsauci.
{% endhint %}

### Tokenu dzīves cikls

Tokeni ir ilgdzīvojoši akreditācijas dati. To statuss nosaka, vai tos var izmantot maksājumu apstrādei.

Tīkla tokeniem dzīves cikla notikumus regulē karšu shēmas un to tokenizācijas pakalpojumi. Kad vārteja saņem dzīves cikla paziņojumu no karšu shēmas, tā atjaunina atbilstošos tokena ierakstus tokenu glabātuvē un pielāgo tokena statusu darījumu apstrādei. Šie atjauninājumi notiek caurspīdīgi – jūsu integrācija un saglabātās tokenu atsauces turpina darboties bez izmaiņām.

#### Dzīves cikla notikumi

<table><thead><tr><th width="129" valign="top">Notikums</th><th valign="top">Apraksts</th><th valign="top">Ietekme uz tirgotāju</th></tr></thead><tbody><tr><td valign="top">Aktivizēšana</td><td valign="top">Tokens ir nodrošināts un gatavs lietošanai.</td><td valign="top">Tokena atsauci var izmantot maksājumiem.</td></tr><tr><td valign="top">Atjaunināšana</td><td valign="top">Tokena metadati ir mainījušies, piemēram, pēc kartes atkārtotas izdošanas ir jauns derīguma termiņš.</td><td valign="top">Nav – atjauninājums tiek piemērots automātiski.</td></tr><tr><td valign="top">Aizstāšana</td><td valign="top">Pamatā esošā karte tika nomainīta (piemēram, nozaudēta vai nozagta), un shēma piesaistīja tokenu jaunajai kartei.</td><td valign="top">Nav – esošā tokena atsauce paliek derīga.</td></tr><tr><td valign="top">Pagaidu apturēšana</td><td valign="top">Tokens ir uz laiku apturēts, piemēram, pēc izdevēja vai kartes turētāja pieprasījuma.</td><td valign="top">Maksājumi ar tokenu tiek atteikti, līdz tas tiek atkārtoti aktivizēts.</td></tr><tr><td valign="top">Deaktivizēšana/dzēšana</td><td valign="top">Tokens ir neatgriezeniski deaktivizēts.</td><td valign="top">Tokena atsauci vairs nevar izmantot. Lūdziet klientam vēlreiz norādīt maksājuma metodi.</td></tr></tbody></table>

#### Tokenu statusa paziņojumi

Vārteja informē jūsu sistēmas par tokenu statusa izmaiņām, izmantojot atpakaļizsaukuma paziņojumus (webhooks). Izmantojiet šos paziņojumus, lai uzturētu ar jūsu klientu profiliem saistītās saglabātās maksājumu metodes aktuālas – piemēram, lai paslēptu deaktivizētu karti no klienta saglabātajām maksājumu metodēm vai aicinātu klientu pievienot jaunu karti pirms nākamās abonēšanas maksas.

### Lietošanas gadījumi

#### Maksājumi ar vienu klikšķi

Atgriezies klients izvēlas saglabātu maksājuma metodi un apstiprina pirkumu, vēlreiz neievadot kartes datus. Maksājums tiek apstrādāts kā klienta iniciēts darījums, izmantojot saglabāto tokenu, un atkarībā no normatīvajām prasībām un izdevēja riska novērtējuma var būt nepieciešama EMV® 3-D Secure autentifikācija.

#### Atkārtotie maksājumi un abonementi

Pēc sākotnējā CIT, kurā klients piekrīt periodiskai norēķinu iekasēšanai, jūs iekasējat maksājumu no saglabātā tokena saskaņotos intervālos kā tirgotāja iniciētus darījumus. Ja piemērojams, MIT var izmantot EMV® 3DS Requestor-Initiated (3RI) autentifikāciju un var kvalificēties Stiprās klienta autentifikācijas (SCA) izņēmumiem saskaņā ar piemērojamajiem noteikumiem un izdevēja autorizācijas lēmumu.

#### Neplānoti tirgotāja iniciēti darījumi

Uz lietojumu balstīta norēķinu iekasēšana, aizkavēti maksājumi, papildinājumi vai konta maksas tiek apstrādātas no saglabātā tokena, kad iestājas aktivizējošais notikums, klientam neesot klātesošam. Katram MIT ir jāatsaucas uz sākotnējo klienta piekrišanu, kas noteikta sākotnējā CIT laikā.

Piezīme: Tokenizācija un tirgotāja iniciētie darījumi ir atbalstīti kartes maksājumiem. Sīkāku informāciju par CIT/MIT klasifikāciju, klienta piekrišanas prasībām un Visa un Mastercard saglabāto akreditācijas datu ietvaru skatiet sadaļā Saglabātie akreditācijas dati.

### Drošība un atbilstība

Tokenizācija samazina sensitīvu maksājumu datu apstrādi un uzlabo maksājumu apstrādes drošību:

* PCI DSS prasībām atbilstoša tokenu glabātuve. Visi kartes akreditācijas dati tiek glabāti vārtejas PCI DSS prasībām atbilstošajā tokenu glabātuvē. Neapstrādātie kartes dati tirgotājiem netiek atklāti.
* Samazināts PCI DSS tvērums. Tā kā jūsu sistēmās tiek glabātas tikai tokenu atsauces, tokenizācija var būtiski samazināt jūsu PCI DSS atbilstības tvērumu. Piemērojamā pašnovērtējuma anketa (SAQ) tiek noteikta, ņemot vērā visu jūsu maksājumu vidi un ieviešanu.
* Nav patstāvīgas vērtības. Tokenu nevar izmantot, lai atjaunotu sākotnējos kartes datus, un tam nav vērtības ārpus maksājumu vārtejas.
* Shēmas līmeņa aizsardzība. Tīkla tokenus izsniedz un validē karšu shēmas saskaņā ar EMV® Payment Tokenisation Specification.
* CVV netiek glabāts. Kartes drošības kods (CVV/CVC) pēc autorizācijas nekad netiek glabāts, ievērojot PCI DSS prasības.

Tirgotājiem nekad nevajadzētu glabāt kartes turētāja datus, ja vien viņu PCI DSS atbilstības tvērums to nepārprotami atļauj. Maksājumu kartes numuru glabāšanas vietā izmantojiet tokenizāciju.

### Tokenizācija un digitālie maki

Digitālie maki, piemēram, Apple Pay un Google Pay, izmanto savus, pakalpojumu sniedzējam specifiskos tokenizācijas mehānismus. Kartes datus klients neievada manuāli; tie tiek droši izgūti no izvēlētā maka un nodoti vārtejai maksājumu tokena veidā. Šos maka tokenus pārvalda maka pakalpojumu sniedzējs un piemērojamie karšu shēmas noteikumi, un tie atšķiras no šajā lapā aprakstītajiem vārtejas un tīkla tokeniem.

Sīkāku informāciju skatiet Apple Pay un Google Pay sadaļā “Maki”.

### Tirgotāja prasības

Pirms tokenizācijas izmantošanas pārliecinieties, ka:

* Tokenizācija un saglabātie akreditācijas dati ir iekļauti jūsu tirgotāja līgumā un ir iespējoti jūsu tirgotāja kontam.
* Jūsu norēķinu lapa iegūst klienta nepārprotamu piekrišanu, pirms maksājumu akreditācijas dati tiek saglabāti. Piekrišanā skaidri jāapraksta akreditācijas datu saglabāšanas mērķis, maksājumu biežums un summa vai norēķinu modelis (ja piemērojams), kā arī atcelšanas process.
* Jūsu sistēmas saglabā maksājuma atbildē atgriezto tokena ID un atsaucas uz to turpmākajos maksājumu pieprasījumos.
* Jūsu integrācija apstrādā tokenu statusa paziņojumus (webhooks) un uztur saglabātās maksājumu metodes aktuālas.

Tīkla tokenizācijas pieejamība papildus ir atkarīga no karšu shēmas programmas reģistrācijas, apstiprinājumiem un acquiring konfigurācijas.

### Testēšana

Pabeidziet visu izstrādi un validāciju Sandbox vidē, pirms apstrādājat tiešos darījumus. Pirms pieprasāt Production aktivizēšanu, pārliecinieties:

* Tokena izveide sākotnējā klienta iniciētā darījumā, tostarp klienta piekrišanas solis.
* Tokena ID tiek saņemts maksājuma atbildē un pareizi saglabāts jūsu sistēmās.
* Maksājumi ar vienu klikšķi, izmantojot saglabātu tokenu (CIT).
* Atkārtotie maksājumi, izmantojot saglabātu tokenu (MIT).
* Atteiktu maksājumu scenāriji, tostarp maksājumi ar apturētu vai deaktivizētu tokenu.
* Tokenu statusa paziņojumi (webhooks) un no tiem izrietošie atjauninājumi jūsu sistēmās.
* Atmaksu apstrāde maksājumiem, kas balstīti uz tokeniem.

### Tirgotāja labākā prakse

Mēs iesakām tirgotājiem:

* Izmantot tokenizāciju maksājumu kartes numuru glabāšanas vietā.
* Pirms maksājumu akreditācijas datu saglabāšanas iegūt klienta nepārprotamu piekrišanu un saglabāt pierādījumus par šo piekrišanu.
* Skaidri komunicēt atkārtotas norēķinu iekasēšanas noteikumus un, ja to prasa piemērojamie noteikumi vai karšu shēmas noteikumi, informēt klientus pirms atkārtotām maksām.
* Uzsākt tirgotāja iniciētus darījumus tikai pēc derīga klienta iniciēta darījuma.
* Abonēt tokenu statusa paziņojumus un atbilstoši apstrādāt beigušos, aizstātos vai deaktivizētos tokenus.
* Atļaut klientiem skatīt, atjaunināt un dzēst savas saglabātās maksājumu metodes.
* Uzturēt PCI DSS atbilstību, kas atbilst jūsu maksājumu videi.

### Biežāk uzdotie jautājumi

#### Vai tokens mainās, kad klienta karte tiek atkārtoti izdota?

Nē. Tīkla tokeniem karšu shēma automātiski piesaista esošo tokenu jaunajai kartei, un vārteja caurspīdīgi atjaunina savus ierakstus. Jūsu saglabātā tokena atsauce paliek derīga, un atkārtotie maksājumi turpinās bez pārtraukuma.

#### Vai vienu tokenu var izmantot vairākos veikalos?

Tokeni ir saistīti ar tirgotāja vai klienta profilu, zem kura tie tika izveidoti. Tas, vai tokenu var kopīgot starp vairākiem jūsu veikaliem, ir atkarīgs no jūsu tirgotāja konfigurācijas. Sīkākai informācijai sazinieties ar savu SEB pārstāvi.

#### Vai CVV tiek glabāts kopā ar tokenu?

Nē. Kartes drošības kods nekad nedrīkst tikt glabāts pēc autorizācijas, pat ja tiek izmantota tokenizācija. Maksājumi ar saglabātiem akreditācijas datiem tiek apstrādāti bez CVV, saskaņā ar karšu shēmas noteikumiem par saglabāto akreditācijas datu darījumiem.

#### Vai tokenizētiem maksājumiem joprojām ir nepieciešama 3-D Secure?

Klienta iniciētiem darījumiem ar saglabātu tokenu var būt nepieciešama EMV® 3-D Secure autentifikācija atkarībā no normatīvajām prasībām un izdevēja riska novērtējuma. Tirgotāja iniciētie darījumi ir ārpus SCA tvēruma un, ja piemērojams, var izmantot 3DS Requestor-Initiated (3RI) autentifikāciju; galīgais autorizācijas lēmums vienmēr paliek izdevēja ziņā.

#### Kas notiek, ja tokens tiek deaktivizēts?

Maksājumi, kuros izmantota šī tokena atsauce, tiek atteikti. Jūs saņemsiet tokena statusa paziņojumu, lai varētu aicināt klientu norādīt jaunu maksājuma metodi.

### Saistītā dokumentācija

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

* [Saglabātie akreditācijas dati](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati.md)
* [Klienta iniciēti darījumi (CIT)](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati/klienta-inicieti-darijumi-cit.md)
* [Tirgotāja iniciēti darījumi (MIT)](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati/tirgotaja-inicieti-darijumi-mit.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)
* [Atkārtotie maksājumi un abonementi](/seb-docs-draft/seb-docs-public-lv/funkcijas/periodiskie-maksajumi-un-abonementi.md)
* [EMV® 3-D Secure (EMV 3DS)](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/emv-r-3-d-secure-emv-3ds.md)
* [Atpakaļizsaukuma paziņojumi](/seb-docs-draft/seb-docs-public-lv/integracija/tirgotaja-api/webhook.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/tokenizacija.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.