Štai scena, kurią matau vis dažniau. Žmogus su Lovable, Bolt ar v0 per savaitgalį susidėlioja gražią e-parduotuvę. Dizainas tvarkingas, produktų puslapiai veikia, krepšelis skaičiuoja teisingai. Tada ateina momentas, kai reikia, kad klientas realiai sumokėtų per Paysera, kad pirkėjas prisijungtų su Smart-ID ir kad pardavus prekę automatiškai išsirašytų e-sąskaita. Ir būtent čia viskas sustoja.
AI sugeneruoja mokėjimo mygtuką, kuris atrodo idealiai. Tik pinigai per jį neateina. Sugeneruoja „prisijungti su Smart-ID" formą, kuri nieko neautentifikuoja. Pažada e-sąskaitos eksportą, kurio VMI niekada nepriima. Tai nėra atsitiktinumas ar blogas prompt'as — tai fundamentali riba, ties kuria dabartiniai AI įrankiai stoja. Šiame straipsnyje paaiškinsiu, kodėl taip yra, kurios konkrečios lietuviškos integracijos reikalauja žmogaus, ir ką tai realiai reiškia tavo projekto kainai bei terminui.
Kodėl AI gerai generuoja sąsają, bet ne integracijas
Vartotojo sąsaja yra ta sritis, kurioje AI iš tiesų stiprus. Mygtukai, formos, tinkleliai, animacijos — visa tai yra pasikartojantys raštai, kurių internete aprašyta milijonai pavyzdžių. AI mokytas būtent ant tokio kodo, todėl gražų ir net responsyvų frontend'ą jis sukuria įspūdingai greitai. Jei tau reikia, kad svetainė atrodytų gerai, AI tikrai padės.
Integracija su realia sistema yra visiškai kitas reikalas. Paysera, Smart-ID, VMI ar Omniva nėra kodo gabaliukai, kuriuos AI gali „prisiminti" ir sugeneruoti. Tai gyvos sistemos, kurios egzistuoja už tavo svetainės ribų ir kurioms reikia trijų dalykų, kurių AI fiziškai neturi: tavo įmonės sutartinio santykio su tiekėju, tavo slaptų produkcinių raktų ir saugaus serverio, kuriame ta logika veiktų. AI negali už tave pasirašyti sutarties su Paysera. Negali patvirtinti tavo juridinio asmens VMI sistemoje. Negali saugiai laikyti tavo API raktų, nes jis paprasčiausiai juos įklijuoja į kodą, kurį mato kiekvienas naršyklės naudotojas.
Tai esminis skirtumas tarp „atrodo, kad veikia" ir „veikia produkcijoje su realiais pinigais". Plačiau apie tą patį reiškinį rašiau straipsnyje apie tai, ką daryti, kai AI aplikacija įstrigo — integracijos yra ta dalis, kur įstringa daugiausia žmonių.
Klasikinė klaida, kurią randu AI svetainėse
Atsidarai sugeneruotą e-parduotuvę, paspaudži „Apmokėti" — ir patenki į puslapį, kuris tiesiog parodo „Ačiū už užsakymą". Jokio realaus mokėjimo neįvyko. AI sugeneravo mokėjimo srauto vizualą, bet ne patį atsiskaitymą. Dar blogiau, kai produkciniai raktai paliekami matomame frontend kode — tada bet kas gali juos pamatyti ir piktnaudžiauti. Tai ne smulkmena, kurią „vėliau pataisysi". Tai visa serverinė dalis, kurios paprasčiausiai nėra.
Lietuviškos integracijos, kurioms reikia žmogaus
Pažvelkime konkrečiai. Štai integracijos, su kuriomis realiai susiduria kiekvienas lietuviškas verslo projektas, ir kodėl kiekvienai iš jų reikia žmogaus, o ne prompt'o.
| Integracija | Kam reikia | Kodėl AI nepajungs |
|---|---|---|
| Paysera / Montonio / Kevin | Mokėjimai (banklink, kortelės) | Sutartis su tiekėju, produkciniai raktai, atsiskaitymo patvirtinimas su parašo tikrinimu serveryje |
| Smart-ID / Mobilusis parašas | Tapatybės nustatymas, prisijungimas | Sutartinė prieiga, saugus užklausų pasirašymas, identiteto srautas, BDAR |
| E-sąskaita / i.SAF (VMI) | Sąskaitų ir mokesčių teikimas | Registracija VMI sistemoje, griežtas duomenų formatas, atitiktis, klaidų tvarkymas |
| Omniva / LP Express | Siuntų terminalai, etiketės, sekimas | Sutartis su kurjeriu, paskyros raktai, terminalų sąrašai, etikečių generavimas |
| Rivile / Centas | Apskaita, atsargų sinchronizacija | Verslo logikos derinimas, dvipusis duomenų srautas, klaidų suderinimas su buhalterija |
Mokėjimai: Paysera, Montonio, Kevin
Lietuvoje banklink per Paysera ar Montonio yra standartas — žmonės nori sumokėti per savo banką, ne suvesti kortelės duomenis. Kad tai veiktų, reikia sutarties su tiekėju, patvirtintos verslo paskyros ir produkcinių raktų. Bet svarbiausia dalis yra nematoma: kai klientas sumoka, tiekėjas atsiunčia patvirtinimą į tavo serverį, ir tavo serveris privalo patikrinti to pranešimo parašą prieš pažymėdamas užsakymą kaip apmokėtą. Be šio patikrinimo bet kas gali atsiųsti suklastotą „apmokėta" pranešimą ir gauti prekę nemokamai. AI šios serverinės logikos negeneruoja, nes jis neturi tavo raktų ir nesupranta tavo verslo pasekmių.
Autentifikacija: Smart-ID ir Mobilusis parašas
Jei tavo paslaugai reikia patikimo tapatybės nustatymo — finansai, sveikata, sutartys, registracijos — Smart-ID ar Mobilusis parašas yra tai, ko lietuvis tikisi. Tai pasiekiama per oficialius tiekėjus, sutartiniu pagrindu, ir reikalauja teisingo užklausų pasirašymo bei identiteto patvirtinimo srauto. Klaida čia turi dvi puses: arba niekas negali prisijungti, arba, kas daug blogiau, įsileidi ne tą žmogų. Tai ne forma — tai saugumo sistema, kurią turi statyti ir testuoti žmogus, suprantantis, kuo baigiasi klaida.
E-sąskaita ir i.SAF: VMI nepriima „beveik teisingo"
Pardavus prekę reikia sąskaitos, o sąskaitų duomenys keliauja į VMI per i.SAF. Čia AI pažada „eksportuoti sąskaitą", bet VMI sistema priima tik tiksliai pagal reikalavimus suformatuotus duomenis su teisingais laukais, mokesčių kodais ir struktūra. „Beveik teisingo" formato nėra — arba duomenys priimami, arba atmetami su klaida, kurią reikia suprasti ir ištaisyti. Šitą atitiktį užtikrina žmogus, kuris žino, kaip VMI sistema realiai elgiasi, ne tekstas, kuris atrodo įtikinamai.
Siuntos: Omniva ir LP Express
E-parduotuvei reikia, kad pirkėjas pasirinktų paštomatą, kad automatiškai susigeneruotų siuntos etiketė ir kad klientas galėtų sekti siuntą. Tam reikia sutarties su kurjeriu, paskyros raktų, terminalų sąrašo užkrovimo ir etikečių generavimo per jų sistemą. AI gali nupiešti paštomatų pasirinkimo langelį, bet jis bus tuščias — be realaus ryšio su Omniva sistema ten nėra nei terminalų, nei etikečių.
Apskaita: Rivile ir Centas
Jei verslas jau dirba su Rivile ar Centu, e-parduotuvė turi susikalbėti su apskaita: atsargos, kainos, užsakymai turi keliauti į abi puses ir sutapti. Tai giliausia integracija iš visų, nes ji liečia tavo realią verslo logiką ir buhalteriją. Čia klaida reiškia, kad atsargų likučiai nesutampa arba sąskaitos dvejinasi — ir tai sprendžiama derinant su konkrečia tavo apskaitos sąranka, ne generuojant kodą iš nieko.
Bendras vardiklis
Pastebėk dėsningumą: visos šios integracijos reikalauja sutartinio santykio su išorine sistema, tavo slaptų raktų ir serverinės logikos su patikrinimais. Nė vienas iš šių trijų dalykų neegzistuoja AI sugeneruotame frontend'e. Štai kodėl mygtukas atrodo, bet neveikia — trūksta būtent tos dalies, kurios nematai.
Kodėl tai ne „prijunk API per 5 minutes"
Dažnai išgirstu: „bet juk yra dokumentacija, tiesiog prijunk API". Taip, demo, kuriame mygtukas atrodo kaip mokėjimas, tikrai užtrunka 5 minutes. Realus pajungimas, kuris neturi prarasti pinigų, nepriimti dvigubų mokėjimų ir atlaikyti tiekėjo audito, susideda iš kelių etapų, kurių nė vieno negali praleisti.
- Sutartis ir paskyros patvirtinimas. Tiekėjas turi patvirtinti tavo juridinį asmenį ir suteikti produkcinę prieigą. Tai dažnai trunka ilgiau nei pats kodas.
- Sandbox testavimas. Kiekvienas tiekėjas turi bandomąją aplinką, kurioje srautas išbandomas prieš įjungiant realius pinigus. Praleisi šį žingsnį — pirmas realus klientas tampa tavo testu.
- Parašų ir patvirtinimų tikrinimas. Serveris privalo patikrinti, kad mokėjimo patvirtinimas tikrai atėjo iš tiekėjo, o ne nuo apsimetėlio.
- Atitiktis ir BDAR. Tapatybės ir mokėjimų duomenys yra jautrūs — jų tvarkymas turi atitikti teisės reikalavimus, ne tik veikti.
- Kraštiniai atvejai. Ką daryti, kai mokėjimas pusiaukelėje nutrūksta, kai klientas paspaudžia du kartus, kai tiekėjas neatsako, kai reikia grąžinti pinigus. Būtent šie atvejai skiria demo nuo produkto.
Tai tas pats „sunkusis 30 %", apie kurį kalbu beveik kiekvienam klientui. AI nuveda projektą iki 70 % — gražaus, matomo, įspūdingo. Likę 30 % — integracijos, saugumas, kraštiniai atvejai, atitiktis — yra sunkiausia ir brangiausia dalis. Ne todėl, kad ją „sunku užbaigti", o todėl, kad būtent ji ir yra realus produktas. Jei nori giliau suprasti, kada AI tau tikrai užtenka, o kada be žmogaus neapsieisi, paskaityk kada AI įrankio užtenka, o kada reikia developerio — ten sąžiningai išdėlioju abi puses.
Ką tai reiškia kainai ir terminui
Būdamas atviras, štai realūs orientaciniai diapazonai, kiek kainuoja švariai prijungti lietuviškas integracijas prie svetainės ar e-parduotuvės. Tai ne „kodo lopymas", o sistema, kuri atlaiko realų srautą ir tiekėjo auditą.
| Integracija | Orientacinė kaina | Terminas (esant paskyrai) |
|---|---|---|
| Viena mokėjimų sistema (Paysera / Montonio / Kevin) | 600 - 1 500 EUR | 1 - 2 sav. |
| Smart-ID / Mobiliojo parašo autentifikacija | 1 200 - 3 000 EUR | 2 - 3 sav. |
| E-sąskaita / i.SAF teikimas VMI | 1 500 - 3 500 EUR | 2 - 4 sav. |
| Omniva / LP Express siuntos | 700 - 1 800 EUR | 1 - 2 sav. |
| Apskaitos sinchronizacija (Rivile / Centas) | nuo 1 500 EUR | 2 - 4 sav. |
Du dalykai, kuriuos verta įsidėmėti dėl termino. Pirma, didžiausią laiko dalį dažnai užima ne kodas, o tiekėjo paskyros patvirtinimas ir produkcinių raktų gavimas — tą procesą verta pradėti kuo anksčiau, nepriklausomai nuo to, kas stato svetainę. Antra, integracijos retai būna izoliuotos: mokėjimas, sąskaita ir siunta dažniausiai sudaro vieną grandinę, todėl jas verta planuoti kartu, ne lopyti po vieną.
Kada AI tau visiškai užtenka
Būsiu sąžiningas: jei tau reikia tik informacinės svetainės, landing puslapio idėjai patikrinti ar vidinio įrankio be realių mokėjimų ir tapatybės — AI įrankio gali visiškai pakakti, ir neperšu tau developerio be reikalo. Riba aiški: integracijos su realiais pinigais, klientų tapatybe ir VMI prasideda ten, kur AI baigiasi. Tą ribą peržengus reikia žmogaus, suprantančio pasekmes.
Kaip prie to einu aš
Kai paimu projektą, kuriame integracijos neveikia, nelopu sugeneruoto kodo po gabaliuką. Pažiūriu, ką realiai reikia pajungti, susidėlioju visą grandinę — mokėjimas, sąskaita, siunta, autentifikacija — ir pastatau serverinę dalį su visais patikrinimais, sandbox testavimu ir kraštiniais atvejais. Tikslas ne „kad mygtukas atrodytų", o kad pinigai realiai ateitų, sąskaita išsirašytų ir VMI ją priimtų. Tu lieki su veikiančiu produktu ir kodu, kurį turi sau, ne su gražiu fasadu, už kurio nieko nėra.
Turi AI svetainę, kuriai neveikia mokėjimai ar integracijos?
Parodyk, ką jau turi, ir aptarsime, ką realiai reikia pajungti, kad veiktų produkcijoje. Pateiksiu konkretų planą su kaina ir terminu — be įsipareigojimų.
Aptarti integracijasDažniausiai užduodami klausimai
Kodėl AI gali sukurti svetainę, bet negali prijungti Paysera?
AI puikiai generuoja vartotojo sąsają, nes ji pasikartojanti ir gausiai aprašyta internete. Paysera integracija reikalauja realios verslo sutarties su Paysera, patvirtintos juridinio asmens paskyros, prieigos prie produkcinių raktų, atsiskaitymų patvirtinimo per serverį su parašo tikrinimu ir saugaus hostingo. Šių dalykų AI fiziškai negali padaryti už tave — jis neturi tavo įmonės duomenų, negali pasirašyti sutarties ir negali saugiai laikyti tavo slaptų raktų. Todėl sugeneruotas mokėjimo mygtukas atrodo gerai, bet pinigai per jį neateina.
Ar galima prijungti Smart-ID prie svetainės savarankiškai?
Smart-ID ir Mobiliojo parašo autentifikacija pasiekiama per oficialius tiekėjus, dažniausiai sutartiniu pagrindu, ir reikalauja saugaus serverio, teisingo užklausų pasirašymo, identiteto patvirtinimo srauto bei asmens duomenų tvarkymo pagal BDAR. Tai ne mygtukas, kurį įklijuoji — tai autentifikacijos sistema, kurioje klaida reiškia, kad arba niekas neprisijungia, arba įsileidi ne tą žmogų. Tokias integracijas turi statyti ir testuoti žmogus, suprantantis pasekmes.
Kiek kainuoja prijungti lietuviškas integracijas prie svetainės?
Vienos mokėjimų integracijos (Paysera, Montonio ar Kevin) švarus pajungimas su sandbox testavimu ir produkcijos patvirtinimu paprastai kainuoja nuo 600 iki 1 500 EUR, priklausomai nuo srauto sudėtingumo. Smart-ID arba Mobiliojo parašo autentifikacija — nuo 1 200 iki 3 000 EUR. E-sąskaitos ir i.SAF teikimo VMI automatizavimas arba apskaitos sistemos (Rivile, Centas) sinchronizacija — nuo 1 500 EUR ir aukštyn. Tikslus skaičius priklauso nuo to, kiek integracijų ir kaip giliai jos susietos su tavo verslo logika.
Kodėl negalima tiesiog prijungti API per 5 minutes?
Mokėjimų ir tapatybės API reikalauja registracijos pas tiekėją, sutarties, produkcinių ir bandomųjų raktų, sandbox testavimo prieš įjungiant realius pinigus, parašų tikrinimo, klaidų ir grąžinimų scenarijų, BDAR atitikties ir saugaus raktų laikymo. Demo, kuriame mygtukas tik atrodo kaip mokėjimas, tikrai užtrunka 5 minutes. Realus pajungimas, kuris nepraranda pinigų, nepriima dvigubų mokėjimų ir atlaiko tiekėjo auditą, užtrunka dienas — ir tai yra normalu.
Ar AI sugeneruotas mokėjimo mygtukas yra saugus?
Vizualiai — taip, jis atrodo kaip mokėjimo mygtukas. Funkciškai — beveik niekada nesaugus produkcijai. Dažniausios problemos: slapti raktai paliekami matomame kode naršyklėje, atsiskaitymo patvirtinimas nepatikrinamas serveryje, todėl užsakymą galima suklastoti, nėra parašo tikrinimo, todėl patvirtinimą gali atsiųsti bet kas. Tokias spragas radau ne vienoje AI pradėtoje svetainėje. Saugumą čia lemia ne mygtuko išvaizda, o serverinė logika, kurios sugeneruotame variante paprasčiausiai nėra.
Per kiek laiko prijungsi mokėjimus ir e-sąskaitas mano svetainei?
Jei tiekėjo paskyra ir sutartis jau yra, vienos mokėjimų integracijos švarų pajungimą su sandbox testavimu paleidžiu per 1–2 savaites. E-sąskaitos teikimo VMI automatizavimas arba apskaitos sinchronizacija — 2–4 savaites, nes čia daugiau kraštinių atvejų ir derinimo su buhalterija. Didžiausią laiko dalį paprastai užima ne kodas, o tiekėjo paskyros patvirtinimas ir produkcinių raktų gavimas — tą verta pradėti kuo anksčiau.
Nuo gražaus fasado iki veikiančio produkto
Jei AI tave nuvedė iki 70 %, o mokėjimai, tapatybė ir sąskaitos vis dar neveikia — galiu pastatyti tą sunkųjį 30 %, kad realiai veiktų. Atviras pokalbis apie tavo atvejį, konkretus planas, jokių įsipareigojimų.
Gauti konkretų planą