AI nepieslēgs Klix, eParaksts vai e-rēķinus tavai mājaslapai

AI uzģenerē maksājumu pogu, kas izskatās ideāli. Tikai nauda caur to nepienāk. Uzģenerē „pieslēgties ar Smart-ID" formu, kas neko neautentificē. Apsola e-rēķina eksportu, ko VID nekad nepieņem. Tā nav nejaušība un nav slikts prompts: tā ir fundamentāla robeža, pie kuras pašreizējie AI rīki apstājas. Šajā rakstā paskaidrošu, kāpēc tā ir, kuras konkrētās Latvijas integrācijas prasa cilvēku un ko tas reāli nozīmē tava projekta cenai un termiņam.

Rakstu to kā izstrādātājs, kurš regulāri saņem ziņas stilā „uztaisīju ar Lovable, bet tālāk nestrādā" vai „prototips ir, bet nevaru palaist produkcijā". Gandrīz vienmēr iestrēgšanas vieta ir tieši integrācijas: maksājumi, eID, e-rēķini, pakomāti. Tieši tur AI iespējas beidzas un sākas reāls darbs.

Kāpēc AI labi ģenerē saskarni, bet ne integrācijas

Lietotāja saskarne ir tā joma, kurā AI patiešām ir spēcīgs. Pogas, formas, režģi, animācijas — tie visi ir atkārtoti raksti, kuru internetā aprakstīti miljoni piemēru. AI ir mācīts tieši uz šāda koda, tāpēc skaistu un pat responsīvu frontend tas uztaisa iespaidīgi ātri. Ja tev vajag, lai mājaslapa izskatās labi, AI tiešām palīdzēs.

Integrācija ar reālu sistēmu ir pavisam cita lieta. Klix, eParaksts, VID vai Omniva nav koda gabaliņi, ko AI var „atcerēties" un uzģenerēt. Tās ir dzīvas sistēmas, kas pastāv ārpus tavas mājaslapas un kurām vajadzīgas trīs lietas, kuru AI fiziski nav: tava uzņēmuma līgumiskās attiecības ar nodrošinātāju, tavas slepenās produkcijas atslēgas un drošs serveris, kurā šī loģika strādātu. AI nevar tavā vietā parakstīt līgumu ar Citadele par Klix. Nevar apstiprināt tavu juridisko personu VID EDS sistēmā. Nevar droši glabāt tavas API atslēgas, jo tas tās vienkārši ieliek kodā, ko redz katrs pārlūka lietotājs.

Tā ir būtiskā atšķirība starp „izskatās, ka strādā" un „strādā produkcijā ar reālu naudu". Tā pati robeža iezīmējas arī tad, kad AI projekts apstājas pusceļā — par to esmu rakstījis sīkāk rakstā par „bezmaksas" AI mājaslapas īsto cenu. Integrācijas ir tā daļa, kurā iestrēgst visvairāk cilvēku.

Latvijas integrācijas, kurām vajag cilvēku

Paskatīsimies konkrēti. Lūk, integrācijas, ar kurām reāli saskaras katrs Latvijas biznesa projekts, un kāpēc katrai no tām vajag cilvēku, nevis promptu.

Integrācija	Kam vajag	Kāpēc AI nepieslēgs
Klix / Swedbank / SEB vārtejas	Maksājumi (banklink, kartes, Apple/Google Pay)	Līgums ar banku, produkcijas atslēgas, maksājuma apstiprinājums ar paraksta pārbaudi serverī
eParaksts / eParaksts mobile / Smart-ID	Identitātes noteikšana, pieteikšanās, parakstīšana	Līgumiskā piekļuve, droša pieprasījumu parakstīšana, identitātes plūsma, VDAR
Strukturētie e-rēķini / VID EDS / eAdrese	Rēķinu un nodokļu iesniegšana	Reģistrācija VID sistēmā, stingrs PEPPOL/EN 16931 formāts, atbilstība, kļūdu apstrāde
Omniva / DPD / Latvijas Pasts	Pakomāti, etiķetes, sekošana	Līgums ar kurjeru, konta atslēgas, pakomātu saraksti, etiķešu ģenerēšana
Grāmatvedības sistēma (Horizon / Jumis u.c.)	Grāmatvedība, krājumu sinhronizācija	Biznesa loģikas saskaņošana, divvirzienu datu plūsma, kļūdu saskaņa ar grāmatvedību

Maksājumi: Klix, Swedbank, SEB, Stripe

Latvijā banklink jeb tiešie bankas maksājumi ir standarts — cilvēki grib samaksāt caur savu internetbanku, nevis ievadīt kartes datus. Klix (Citadele maksājumu vārteja) ir kļuvis par de facto vietējo standartu e-veikaliem, jo vienā integrācijā dod kartes, bankas tiešos maksājumus, Apple Pay, Google Pay un pat Klix Pay Later. Lielajiem veikaliem alternatīvas ir Swedbank vai SEB vārtejas, bet starptautiskiem un SaaS projektiem bieži Stripe. Lai tas strādātu, vajag līgumu ar nodrošinātāju, apstiprinātu biznesa kontu un produkcijas atslēgas. Bet svarīgākā daļa ir neredzama: kad klients samaksā, banka atsūta apstiprinājumu uz tavu serveri, un tavam serverim pirms pasūtījuma atzīmēšanas par apmaksātu jāpārbauda šī paziņojuma paraksts. Bez šīs pārbaudes jebkurš var atsūtīt viltotu „apmaksāts" paziņojumu un dabūt preci par velti. AI šo servera loģiku neģenerē, jo tam nav tavu atslēgu un tas nesaprot tava biznesa sekas.

Autentifikācija: eParaksts, eParaksts mobile un Smart-ID

Ja tavam pakalpojumam vajag uzticamu identitātes noteikšanu — finanses, veselība, līgumi, reģistrācijas — tad eParaksts, eParaksts mobile (autentifikācija ar PIN1, parakstīšana ar PIN2) vai Smart-ID ir tas, ko latvietis sagaida. Tas ir pieejams caur oficiāliem nodrošinātājiem, uz līguma pamata, un prasa pareizu pieprasījumu parakstīšanu un identitātes apstiprinājuma plūsmu. Kļūdai te ir divas puses: vai nu neviens nevar pieslēgties, vai arī, kas daudz ļaunāk, ielaid nepareizo cilvēku. Tā nav forma — tā ir drošības sistēma, kas jābūvē un jātestē cilvēkam, kurš saprot, ar ko beidzas kļūda. Bankas internetbanku pieteikšanās (Swedbank, SEB, Citadele, Luminor) kā identitātes nodrošinātāji ir vēl viens vietējais variants ar tādām pašām prasībām.

E-rēķini un VID: „gandrīz pareizo" nepieņem

Pēc preces pārdošanas vajag rēķinu, un rēķinu dati ceļo uz VID. Šeit AI apsola „eksportēt rēķinu", bet sistēma pieņem tikai precīzi pēc prasībām formatētus datus ar pareiziem laukiem, nodokļu kodiem un struktūru. „Gandrīz pareiza" formāta nav — vai nu dati tiek pieņemti, vai noraidīti ar kļūdu, ko vajag saprast un izlabot. Latvijā tas tagad ir īpaši aktuāli: no 2026. gada 1. janvāra strukturētie e-rēķini B2G/G2G/G2B ir obligāti, bet B2B kļūs obligāti no 2028. gada 1. janvāra (brīvprātīgi caur eAdresi jau no 2026. gada 30. marta). Tehniski tas nozīmē PEPPOL tīklu un PEPPOL BIS Billing 3.0 standartu (EN 16931) ar strukturētiem XML rēķiniem, ko iesniedz caur eAdresi un VID EDS. Šo atbilstību nodrošina cilvēks, kurš zina, kā VID sistēma reāli uzvedas, nevis teksts, kas izskatās pārliecinoši.

Piegāde: Omniva, DPD un Latvijas Pasts

E-veikalam vajag, lai pircējs izvēlas pakomātu, lai automātiski uzģenerējas sūtījuma etiķete un lai klients var sekot līdzi sūtījumam. Latvijā pakomāts ir pati pirmā piegādes izvēle — pircēji izvēlas pēc tuvākā pakomāta, tāpēc checkout obligāti vajag dzīvu pakomātu sarakstu no Omniva, DPD vai Latvijas Pasta (un nereti arī Venipak vai Unisend). Tam vajag līgumu ar kurjeru, konta atslēgas, terminālu saraksta ielādi un etiķešu ģenerēšanu caur viņu sistēmu. AI var uzzīmēt pakomātu izvēles lodziņu, bet tas būs tukšs — bez reālas saites ar piegādātāja sistēmu tur nav ne terminālu, ne etiķešu.

Grāmatvedība: krājumu un rēķinu sinhronizācija

Ja bizness jau strādā ar kādu grāmatvedības sistēmu (Horizon, Jumis vai līdzīgu), e-veikalam jāsarunā ar grāmatvedību: krājumi, cenas, pasūtījumi jāceļo uz abām pusēm un jāsakrīt. Tā ir visdziļākā integrācija no visām, jo tā skar tavu reālo biznesa loģiku un grāmatvedību. Te kļūda nozīmē, ka krājumu atlikumi nesakrīt vai rēķini dubultojas — un to risina, saskaņojot ar konkrēto tavu grāmatvedības iestatījumu, nevis ģenerējot kodu no nekā.

Kāpēc tas nav „pieslēdz API 5 minūtēs"

Bieži dzirdu: „bet jau ir dokumentācija, vienkārši pieslēdz API". Jā, demo, kurā poga izskatās pēc maksājuma, tiešām aizņem 5 minūtes. Reāls pieslēgums, kam nedrīkst zaudēt naudu, nedrīkst pieņemt dubultmaksājumus un kam jāiztur nodrošinātāja audits, sastāv no vairākiem posmiem, no kuriem nevienu nevar izlaist.

• Līgums un konta apstiprināšana. Nodrošinātājam jāapstiprina tava juridiskā persona un jāizsniedz produkcijas piekļuve. Tas bieži aizņem ilgāk par pašu kodu.
• Sandbox testēšana. Katram nodrošinātājam ir testa vide, kurā plūsmu izmēģina pirms reālas naudas ieslēgšanas. Izlaidīsi šo soli — pirmais reālais klients kļūst par tavu testu.
• Parakstu un apstiprinājumu pārbaude. Serverim jāpārbauda, ka maksājuma apstiprinājums tiešām nāca no nodrošinātāja, nevis no krāpnieka.
• Atbilstība un VDAR. Identitātes un maksājumu dati ir jutīgi — to apstrādei jāatbilst tiesību prasībām, ne tikai jāstrādā. Latvijā uzraudzību veic Datu valsts inspekcija, kas piemēro sankcijas.
• Robežgadījumi. Ko darīt, kad maksājums pusceļā pārtrūkst, kad klients nospiež divreiz, kad nodrošinātājs neatbild, kad jāatmaksā nauda. Tieši šie gadījumi atšķir demo no produkta.

Tas ir tas pats „smagais 30 %", par ko runāju gandrīz katram klientam. AI aizved projektu līdz 70 % — skaistam, redzamam, iespaidīgam. Atlikušie 30 % — integrācijas, drošība, robežgadījumi, atbilstība — ir vissmagākā un visdārgākā daļa. Ne tāpēc, ka to „grūti pabeigt", bet tāpēc, ka tieši tā arī ir reālais produkts. Ja gribi dziļāk saprast, kad AI tev tiešām pietiek un kad bez cilvēka neiztikt, izlasi rakstu par to, kad pietiek ar AI, kad vajag izstrādātāju — tur godīgi izklāstu abas puses.

Ko tas nozīmē cenai un termiņam

Būšu atklāts: lūk, reāli orientējoši diapazoni, cik maksā tīri pieslēgt Latvijas integrācijas mājaslapai vai e-veikalam. Visas cenas norādītas bez PVN (klāt nāk 21 % PVN). Tas nav „koda lāpīšana", bet sistēma, kas iztur reālu plūsmu un nodrošinātāja auditu.

Integrācija	Orientējoša cena (bez PVN)	Termiņš (esot kontam)
Viena maksājumu sistēma (Klix / Swedbank / Stripe)	no 600 līdz 1500 EUR	1 līdz 2 ned.
eParaksts / Smart-ID autentifikācija	no 1200 līdz 3000 EUR	2 līdz 3 ned.
Strukturētie e-rēķini caur eAdresi / VID	no 1500 līdz 3500 EUR	2 līdz 4 ned.
Omniva / DPD / Latvijas Pasts pakomāti	no 700 līdz 1800 EUR	1 līdz 2 ned.
Grāmatvedības sinhronizācija (Horizon / Jumis)	no 1500 EUR	2 līdz 4 ned.

Divas lietas, ko vērts paturēt prātā par termiņu. Pirmkārt, lielāko laika daļu bieži aizņem nevis kods, bet nodrošinātāja konta apstiprināšana un produkcijas atslēgu saņemšana — to procesu vērts sākt pēc iespējas agrāk neatkarīgi no tā, kas būvē mājaslapu. Otrkārt, integrācijas reti ir izolētas: maksājums, rēķins un sūtījums parasti veido vienu ķēdi, tāpēc tās vērts plānot kopā, nevis lāpīt pa vienai.

Salīdzinājumam par mērogu: profesionāla mājaslapa Latvijā sākas no 999 EUR, individuāli kodēta custom mājaslapa no 5000 EUR, bet e-veikals reāli svārstās no 2400 EUR līdz 20 000 EUR un vairāk — un tieši integrācijas bieži ir tas, kas nosaka, kur tu esi šajā diapazonā. „No 999 €" template aģentūras šo daļu vienkārši neietver.

Kā pie tā eju es

Kad paņemu projektu, kurā integrācijas nestrādā, es nelāpu uzģenerēto kodu pa gabaliņam. Paskatos, ko reāli vajag pieslēgt, salieku visu ķēdi — maksājums, rēķins, sūtījums, autentifikācija — un uzbūvēju servera daļu ar visām pārbaudēm, sandbox testēšanu un robežgadījumiem. Mērķis nav „lai poga izskatās", bet lai nauda reāli pienāk, rēķins izrakstās un VID to pieņem. Tu paliec ar strādājošu produktu un kodu, kas pieder tev, nevis ar skaistu fasādi, aiz kuras nekā nav. Strādāju kā viens cilvēks no sākuma līdz galam, tāpēc tu zini, ar ko runā un kurš atbild par rezultātu.

Biežāk uzdotie jautājumi

Kāpēc AI var uztaisīt mājaslapu, bet nevar pieslēgt Klix?

AI lieliski ģenerē lietotāja saskarni, jo tā ir atkārtota un internetā bagātīgi aprakstīta. Klix integrācija prasa reālu biznesa līgumu ar Citadele, apstiprinātu juridiskas personas kontu, piekļuvi produkcijas atslēgām, maksājuma apstiprinājumu caur serveri ar paraksta pārbaudi un drošu hostingu. Šīs lietas AI fiziski nevar izdarīt tavā vietā: tam nav tava uzņēmuma datu, tas nevar parakstīt līgumu un nevar droši glabāt tavas slepenās atslēgas. Tāpēc uzģenerētā maksājumu poga izskatās labi, bet nauda caur to nepienāk.

Vai eParaksts vai Smart-ID var pieslēgt mājaslapai pašam?

eParaksts un Smart-ID autentifikācija ir pieejama caur oficiāliem nodrošinātājiem, parasti uz līguma pamata, un prasa drošu serveri, pareizu pieprasījumu parakstīšanu, identitātes apstiprinājuma plūsmu un personas datu apstrādi atbilstoši VDAR. Tā nav poga, ko ielīmē: tā ir autentifikācijas sistēma, kurā kļūda nozīmē, ka vai nu neviens nevar pieslēgties, vai arī ielaid nepareizo cilvēku. Šādas integrācijas jābūvē un jātestē cilvēkam, kurš saprot sekas.

Cik maksā pieslēgt Latvijas integrācijas mājaslapai?

Vienas maksājumu integrācijas (Klix, Swedbank vai Stripe) tīrs pieslēgums ar sandbox testēšanu un produkcijas apstiprinājumu parasti maksā no 600 līdz 1500 EUR bez PVN, atkarībā no plūsmas sarežģītības. eParaksts vai Smart-ID autentifikācija: no 1200 līdz 3000 EUR bez PVN. Strukturēto e-rēķinu iesniegšanas caur eAdresi un VID EDS automatizācija vai grāmatvedības sistēmas sinhronizācija: no 1500 EUR bez PVN un augšup. Precīzs skaitlis atkarīgs no tā, cik integrāciju un cik dziļi tās saistītas ar tavu biznesa loģiku.

Kāpēc nevar vienkārši pieslēgt API 5 minūtēs?

Maksājumu un identitātes API prasa reģistrāciju pie nodrošinātāja, līgumu, produkcijas un testa atslēgas, sandbox testēšanu pirms reālas naudas ieslēgšanas, parakstu pārbaudi, kļūdu un atmaksu scenārijus, VDAR atbilstību un drošu atslēgu glabāšanu. Demo, kurā poga tikai izskatās pēc maksājuma, tiešām aizņem 5 minūtes. Reāls pieslēgums, kas nezaudē naudu, nepieņem dubultmaksājumus un iztur nodrošinātāja auditu, aizņem dienas — un tas ir normāli.

Vai AI uzģenerētā maksājumu poga ir droša?

Vizuāli jā, tā izskatās pēc maksājumu pogas. Funkcionāli gandrīz nekad nav droša produkcijai. Biežākās problēmas: slepenās atslēgas atstātas redzamā pārlūka kodā, maksājuma apstiprinājums netiek pārbaudīts serverī, tāpēc pasūtījumu var viltot, nav paraksta pārbaudes, tāpēc webhook var atsūtīt jebkurš. Tādas nepilnības esmu atradis ne vienā AI iesāktā mājaslapā. Drošību šeit nosaka nevis pogas izskats, bet servera loģika, kuras uzģenerētajā variantā vienkārši nav. Bez tam Latvijā Datu valsts inspekcija piemēro sankcijas par VDAR pārkāpumiem, un sīkdatņu piekrišana ar privātuma politiku AI prototipos gandrīz nekad nav iztaisīta pareizi.

Cik ilgā laikā pieslēgsi maksājumus un e-rēķinus manai mājaslapai?

Ja nodrošinātāja konts un līgums jau ir, vienas maksājumu integrācijas tīru pieslēgumu ar sandbox testēšanu palaižu 1 līdz 2 nedēļās. Strukturēto e-rēķinu iesniegšanas caur eAdresi un VID automatizācija vai grāmatvedības sinhronizācija: 2 līdz 4 nedēļas, jo te vairāk robežgadījumu un saskaņošanas ar tavu grāmatvedību. Lielāko laika daļu parasti aizņem nevis kods, bet nodrošinātāja konta apstiprināšana un produkcijas atslēgu saņemšana, to vērts sākt pēc iespējas agrāk.