„Stripe” mokėjimų integravimas lietuviškose svetainėse

Kodėl „Stripe” tapo tokiu populiariu Lietuvoje

Prisimenu, kaip prieš keletą metų integruojant mokėjimų sistemas lietuviškose svetainėse dažniausiai tekdavo rinktis tarp kelių vietinių sprendimų arba „PayPal”. Situacija buvo gana liūdna – dokumentacija prasta, API atgyvenę, o kartais net reikėdavo siųsti faksus (taip, faksus!) dėl techninių klausimų. Tada atsirado „Stripe”, ir viskas pasikeitė.

„Stripe” į Lietuvą oficialiai atėjo 2021 metais, nors daugelis kūrėjų jį naudojo ir anksčiau per įvairius workaround’us. Dabar tai viena populiariausių mokėjimų platformų tarp lietuviškų startuolių ir e-komercijos projektų. Priežastys akivaizdžios – puiki dokumentacija, moderni API, paprasta integracija ir, svarbiausia, galimybė priimti mokėjimus iš viso pasaulio be didesnių galvos skausmų.

Kas įdomiausia, „Stripe” populiarumas Lietuvoje augo ne dėl agresyvaus marketingo, o dėl kūrėjų rekomendacijų. Kai dirbi su įrankiu, kuris tiesiog veikia taip, kaip tikėjaisi, natūraliai nori jį rekomenduoti kitiems. Ir tai tikrai retai pasitaiko mokėjimų sistemų pasaulyje.

Kas reikalinga prieš pradedant integraciją

Prieš šokant į kodą, reikia sutvarkyti keletą dalykų. Pirma, jums reikės „Stripe” paskyros. Registracija paprasta, bet štai čia slypi pirmasis niuansas lietuviškoms įmonėms – jums reikės turėti juridinį asmenį. „Stripe” Lietuvoje dirba su įmonėmis, o ne individualiomis veiklomis. Tai reiškia, kad MB, UAB ar kita juridinio asmens forma yra būtina.

Registracijos metu teks pateikti įmonės dokumentus, vadovų tapatybės patvirtinimą ir banko sąskaitos informaciją. Procesas paprastai užtrunka kelias dienas, nors kartais gali prireikti papildomų dokumentų. Patarimas – iš karto paruoškite visus dokumentus PDF formatu, nes tai paspartins procesą.

Techninėje pusėje jums reikės:

  • Veikiančios svetainės su HTTPS (tai privaloma, ne pasiūlymas)
  • Serverio, kuriame galėsite apdoroti webhook’us
  • Testavimo aplinkos (staging), kur galėsite išbandyti integraciją
  • Bazinių žinių apie REST API ir HTTP užklausas

Dar vienas dalykas, apie kurį daugelis pamiršta – PCI DSS atitiktis. Gera žinia ta, kad naudojant „Stripe” teisingai (per jų Checkout arba Elements), jūs automatiškai atitinkate daugumą reikalavimų, nes kortelių duomenys niekada nepasiekia jūsų serverio.

Integracijos būdai ir kada kurį rinktis

„Stripe” siūlo kelis integracijos būdus, ir čia prasideda tikrasis smagumas. Paprasčiausias variantas – „Stripe Checkout”. Tai iš esmės nukreipimas į „Stripe” puslapį, kur vyksta mokėjimas, o po to klientas grąžinamas atgal į jūsų svetainę. Skamba paprasta? Taip ir yra.

Checkout puikiai tinka, jei:

  • Kuriate MVP ir norite kuo greičiau paleisti mokėjimus
  • Neturite dizainerio, kuris sukurtų custom mokėjimo formą
  • Jums nerūpi pilna kontrolė virš mokėjimo proceso išvaizdos
  • Norite minimalios PCI DSS naštos

Aš pats naudojau Checkout pirmajame SaaS projekte, ir tai buvo išmintingas sprendimas. Per vieną dieną turėjau veikiančius mokėjimus, o galėjau sutelkti dėmesį į produkto funkcionalumą.

Kitas variantas – „Stripe Elements” arba „Payment Element”. Tai JavaScript bibliotekos, leidžiančios įterpti mokėjimo formas tiesiai į jūsų svetainę. Turite pilną kontrolę virš dizaino, bet vis dar neturite reikalo su kortelių duomenimis. Elements automatiškai tvarko validaciją, klaidų pranešimus ir net pritaiko stilių prie jūsų svetainės.

Payment Element – tai naujesnis sprendimas, kuris viename komponente apjungia visus mokėjimo metodus. Vietoj to, kad turėtumėte atskirai integruoti korteles, „Google Pay”, „Apple Pay” ir kitus metodus, Payment Element viską daro už jus. Rimtai rekomenduoju jį naujiems projektams.

Pažengusiems kūrėjams yra ir Payment Intents API – žemo lygio API, suteikiantis maksimalią kontrolę. Bet jei nesate tikri, ar jums to reikia, greičiausiai nereikia.

Praktinis integravimas su PHP pavyzdžiu

Parodysiu, kaip integruoti „Stripe Checkout” į paprastą PHP svetainę. Tai vienas populiariausių scenarijų Lietuvoje, nes daug įmonių vis dar naudoja PHP projektams.

Pirma, įdiekite „Stripe” PHP biblioteką per Composer:

„`
composer require stripe/stripe-php
„`

Tada sukurkite checkout sesiją:

„`php
‘line_items’ => [[
‘price_data’ => [
‘currency’ => ‘eur’,
‘unit_amount’ => 2999, // suma centais (29.99 EUR)
‘product_data’ => [
‘name’ => ‘Prenumerata’,
‘description’ => ‘Mėnesio prenumerata’,
],
],
‘quantity’ => 1,
]],
‘mode’ => ‘payment’,
‘success_url’ => ‘https://jusu-svetaine.lt/sekme’,
‘cancel_url’ => ‘https://jusu-svetaine.lt/atsaukta’,
]);

header(„Location: ” . $checkout_session->url);
exit();
?>
„`

Atkreipkite dėmesį į keletą dalykų. Pirma, sumos visada nurodomos centais – tai apsaugo nuo slankaus kablelio klaidų. Antra, valiuta nurodoma kaip ‘eur’ – dauguma lietuviškų projektų naudoja eurus, bet galite priimti ir kitas valiutas.

Success ir cancel URL yra svarbūs. Į success_url klientas nukreipiamas po sėkmingo mokėjimo, o į cancel_url – jei jis atsisako mokėti. Bet atsargiai – negalite pasitikėti vien šiais nukreipimais, nes vartotojas gali tiesiog uždaryti naršyklę.

Webhook’ai – dalykas, be kurio neišsiversite

Štai čia daugelis kūrėjų suklysta. Jie integruoja mokėjimus, testuoja, viskas veikia, ir mano, kad baigta. Bet kas nutinka, jei vartotojas sumoka ir uždaro naršyklę prieš grįždamas į success_url? Arba jei mokėjimas užtrunka ilgiau nei tikėtasi?

Webhook’ai – tai „Stripe” būdas pranešti jūsų serveriui apie įvykius realiu laiku. Kai klientas sumoka, „Stripe” siunčia POST užklausą į jūsų nurodytą URL su mokėjimo informacija. Tai vienintelis patikimas būdas patvirtinti mokėjimą.

Štai kaip atrodo paprastas webhook’o apdorojimas PHP:

„`php
case ‘checkout.session.completed’:
$session = $event->data->object;

// Čia jūsų logika: aktyvuoti prenumeratą,
// išsiųsti produktą, atnaujinti duomenų bazę ir t.t.

error_log(‘Mokėjimas gautas: ‘ . $session->id);
break;

case ‘payment_intent.payment_failed’:
$paymentIntent = $event->data->object;
error_log(‘Mokėjimas nepavyko: ‘ . $paymentIntent->id);
break;
}

http_response_code(200);
?>
„`

Webhook’o URL reikia sukonfigūruoti „Stripe” dashboard’e. Svarbu – jūsų webhook’o endpoint’as turi būti prieinamas iš interneto. Tai reiškia, kad localhost neveiks. Testavimui galite naudoti „Stripe CLI” arba įrankius kaip ngrok.

Dar vienas svarbus dalykas – webhook’ai turi būti idempotentiški. „Stripe” gali siųsti tą patį webhook’ą kelis kartus, todėl jūsų kodas turi tai tvarkyti. Paprasčiausias būdas – saugoti apdorotų įvykių ID duomenų bazėje ir ignoruoti dublikatus.

Lietuviški ypatumai ir mokesčiai

Dirbant su mokėjimais Lietuvoje, yra keletas niuansų, kuriuos verta žinoti. Pirma, „Stripe” mokesčiai Lietuvoje yra 1.4% + 0.25 EUR už europines korteles ir 2.9% + 0.25 EUR už ne-europines. Tai konkurencingos kainos, bet vis tiek verta įskaičiuoti į savo verslo modelį.

Antra, PVM. Jei parduodate skaitmeninius produktus ar paslaugas kitų ES šalių klientams, taikomas pirkėjo šalies PVM. „Stripe” turi integruotą „Stripe Tax” sprendimą, kuris automatiškai apskaičiuoja ir tvarko PVM, bet tai papildomas mokestis (0.5% nuo transakcijos). Ar verta? Priklauso nuo jūsų verslo apimčių, bet jei parduodate į daug skirtingų šalių, tai gali sutaupyti daug galvos skausmo.

Lietuviški klientai mėgsta mokėti kortele, bet taip pat populiarūs ir kiti metodai. „Stripe” Lietuvoje palaiko:

  • Debetines ir kreditines korteles (Visa, Mastercard, Amex)
  • Google Pay ir Apple Pay
  • SEPA debetą (naudinga prenumeratoms)
  • Banko pavedimus (nors tai rečiau naudojama)

Vienas dalykas, kurio „Stripe” Lietuvoje dar nepalaiko – tai tiesioginis bankų integracija per Open Banking API. Tai reiškia, kad jei jūsų klientai nori mokėti per Swedbank, SEB ar kitus lietuviškus bankus tiesiogiai (be kortelės), teks ieškoti papildomų sprendimų arba naudoti vietines mokėjimo sistemas kaip Paysera.

Saugumo aspektai, apie kuriuos negalima pamiršti

Mokėjimų sauga – tai ne tik techninė problema, bet ir reputacijos klausimas. Vienas saugumo incidentas gali sunaikinti metų darbo rezultatus. Todėl štai keletas dalykų, į kuriuos būtina atkreipti dėmesį.

Niekada, girdite, NIEKADA nesaugokite kortelių duomenų savo serveryje. Net jei manote, kad žinote, kaip tai padaryti saugiai. Naudokite „Stripe” tokenizaciją – kortelės duomenys siunčiami tiesiai į „Stripe”, o jūs gaunate tik tokeną, kurį galite saugiai saugoti.

API raktai – dar viena dažna klaida. „Stripe” duoda du raktų tipus: publishable (viešas) ir secret (slaptas). Viešas raktas gali būti JavaScript kode, bet slaptas raktas NIEKADA neturi patekti į frontend’ą. Jį naudokite tik serverio pusėje, ir saugokite aplinkos kintamuosiuose, ne kode.

Pavyzdys, kaip NEDERĖTŲ daryti:

„`javascript
// BLOGAI! Nesaugokite slaptos rakto frontend’e
const stripe = Stripe(‘sk_live_…’);
„`

Teisingas būdas:

„`javascript
// GERAI – naudokite viešą raktą frontend’e
const stripe = Stripe(‘pk_live_…’);
„`

Webhook’ų parašai – dar viena svarbi saugumo priemonė. Visada tikrinkite webhook’o parašą prieš apdorodami duomenis. Tai apsaugo nuo užpuolikų, bandančių siųsti netikrus webhook’us į jūsų serverį.

HTTPS yra privalomas. „Stripe” net neleis jums naudoti production raktų be HTTPS. Ir tai gerai – šiais laikais nėra jokios priežasties nenaudoti HTTPS, ypač kai Let’s Encrypt siūlo nemokamus sertifikatus.

Testavimas ir derinimas

„Stripe” turi puikią test mode funkciją, kuri leidžia testuoti viską be tikrų pinigų. Tai viena iš priežasčių, kodėl su „Stripe” taip malonu dirbti – galite testuoti kiek norite, nieko nemokėdami.

Test mode turi savo API raktus (prasideda `pk_test_` ir `sk_test_`), ir viskas, kas daroma su šiais raktais, yra atskirta nuo production aplinkos. Galite kurti mokėjimus, grąžinimus, prenumeratas – viską.

„Stripe” taip pat suteikia testines kortelių numerius įvairiems scenarijams:

  • 4242 4242 4242 4242 – sėkmingas mokėjimas
  • 4000 0000 0000 9995 – nepakanka lėšų
  • 4000 0000 0000 9987 – kortelė atmesta
  • 4000 0025 0000 3155 – reikia 3D Secure autentifikacijos

Testavimo metu būtinai patikrinkite:

  • Sėkmingus mokėjimus
  • Nesėkmingus mokėjimus (kaip jūsų sistema reaguoja?)
  • 3D Secure scenarijus (daug lietuviškų kortelių naudoja 3D Secure)
  • Webhook’ų apdorojimą (naudokite „Stripe CLI” webhook’ams testuoti lokalioje aplinkoje)
  • Grąžinimus (refunds)

„Stripe” dashboard’as turi puikų logs skiltį, kur matote visas API užklausas ir atsakymus. Tai neįkainojama derinimo priemonė. Kai kas nors neveikia, pirmiausia žiūrėkite į logs – dažniausiai ten rasite atsakymą.

Kaip visa tai sujungti į veikiantį sprendimą

Dabar, kai suprantate pagrindus, pažiūrėkime į pilną paveikslą. Tipinė „Stripe” integracija lietuviškoje e-komercijos svetainėje atrodo maždaug taip:

Klientas pasirenka produktą ir paspaudžia „Pirkti”. Jūsų serveris sukuria Checkout sesiją su produkto informacija ir nukreipia klientą į „Stripe” mokėjimo puslapį. Klientas įveda kortelės duomenis ir patvirtina mokėjimą. „Stripe” apdoroja mokėjimą ir nukreipia klientą atgal į jūsų success_url. Tuo pačiu metu „Stripe” siunčia webhook’ą į jūsų serverį su mokėjimo patvirtinimu.

Jūsų serveris gauna webhook’ą, patikrina parašą, ir jei viskas gerai – aktyvuoja užsakymą, išsiunčia produktą, atnaujina duomenų bazę ir siunčia patvirtinimo el. laišką klientui. Klientas mato sėkmės puslapį jūsų svetainėje ir gauna el. laišką su užsakymo informacija.

Skamba paprasta, bet yra keletas dalykų, kuriuos verta pridėti prie šio bazinio scenarijaus. Pirma, error handling. Kas nutinka, jei webhook’as nepasiekia jūsų serverio? „Stripe” bandys siųsti jį iš naujo, bet verta turėti backup planą – pavyzdžiui, cron job’ą, kuris periodiškai tikrina neapdorotus mokėjimus.

Antra, klientų aptarnavimas. Integruokite „Stripe” dashboard’ą į savo admin panelę, kad palaikymo komanda galėtų greitai rasti mokėjimų informaciją. „Stripe” turi puikią paiešką ir filtravimą, bet kartais patogu turėti viską vienoje vietoje.

Trečia, analitika. „Stripe” turi įmontuotą analitikos funkciją, bet dažnai norėsite mokėjimų duomenis sujungti su savo verslo metrikomis. Galite naudoti „Stripe” API, kad periodiškai trauktumėte duomenis į savo sistemą, arba naudoti webhook’us, kad realiu laiku atnaujintumėte savo analitikos duomenis.

Dar vienas praktinis patarimas – naudokite „Stripe” metadata laukus. Galite pridėti papildomos informacijos prie kiekvieno mokėjimo (pvz., vartotojo ID, užsakymo numerį, kampanijos kodą), ir tai labai palengvina duomenų sujungimą tarp „Stripe” ir jūsų sistemos.

Ir galiausiai, nepamiršite apie klientų patirtį. Mokėjimo procesas turėtų būti kuo sklandesnis. Naudokite „Stripe” Link funkciją, kuri leidžia klientams išsaugoti mokėjimo informaciją ir mokėti vienu paspaudimu kitą kartą. Pridėkite Apple Pay ir Google Pay – tai tik kelių eilučių kodas, bet labai pagerina konversijas mobiliuose įrenginiuose.

Dirbant su lietuviškais klientais, verta pridėti aiškius pranešimus lietuvių kalba. „Stripe” Checkout palaiko lokalizaciją, bet jūsų success ir error puslapiai turėtų būti pilnai išversti. Taip pat verta aiškiai nurodyti, kad mokėjimas yra saugus ir kad kortelės duomenys nesaugomi jūsų serveryje – tai padidina pasitikėjimą.

Realybėje „Stripe” integracija nėra vienkartinis projektas. Tai procesas, kuris vystosi kartu su jūsų verslu. Pradėsite nuo paprasto Checkout, vėliau galbūt pridėsite prenumeratas, tada galbūt marketplace funkcionalumą su „Stripe Connect”. Gera žinia ta, kad „Stripe” auga kartu su jumis – jų API yra pakankamai lanksti, kad palaikytų ir paprastus, ir sudėtingus scenarijus.

Taigi, ar „Stripe” yra tinkamas pasirinkimas jūsų lietuviškai svetainei? Jei kuriate modernų, į tarptautinę rinką orientuotą produktą, atsakymas greičiausiai yra taip. Dokumentacija puiki, palaikymas greitas, funkcionalumas platus. Taip, yra mokesčiai, bet jie atperkami laiko, kurį sutaupysite, ir galvos skausmų, kurių išvengsite, forma. O jei jūsų verslas daugiausia orientuotas į vietinę rinką ir jums reikia specifinių lietuviškų mokėjimo metodų, galbūt verta pažiūrėti ir į vietines alternatyvas. Bet daugumai projektų „Stripe” bus daugiau nei pakankamas – ir tai sakau iš asmeninės patirties, integravęs jį daugiau nei dešimtyje skirtingų projektų.

Parašykite komentarą

El. pašto adresas nebus skelbiamas. Būtini laukeliai pažymėti *