Integracija plaćanja je kod koji stoji između trenutka kada kupac pritisne “Plati” i novca koji legne na vaš račun – i to je dio sajta na kojem “uglavnom radi” nije dovoljno dobro. Propušten webhook ostavlja plaćenu narudžbu označenom kao neplaćenu, loše obrađen 3-D Secure izazov gubi prodaju na zadnjem koraku, a nepažljiva forma može cijeli server uvući u obim PCI DSS standarda.
Sadržaj
U CodeWizu integrišemo Stripe, PayPal i regionalne bankarske procesore u online prodavnice, SaaS proizvode, sisteme za rezervacije i aplikacije po mjeri. Gradimo checkout koji pravilno rješava Strong Customer Authentication, webhook handlere koji ne gube događaj i ne obrade isti dvaput, naplatu pretplata, povrate i usklađivanje uplata, te arhitekturu u kojoj podaci o kartici ne dolaze na vaše servere.
Usluga je namijenjena online prodavnicama koje dodaju ili mijenjaju načine plaćanja, SaaS kompanijama kojima treba ponavljajuća naplata, platformama i marketplace sajtovima koji isplaćuju druge, i firmama čija sadašnja integracija pravi neusaglašene narudžbe, propale obnove ili tikete o uplatama koje su “prošle, a narudžba i dalje piše da nije plaćena”.
Integracija plaćanja preko Stripea
Stripe preporučujemo tamo gdje je dostupan, prije svega zbog kvaliteta API-ja i dokumentacije. Većina Stripe problema koje sređujemo dolazi od integracija na zastarjelim obrascima ili od toga što se povratak u preglednik tretira kao dokaz da je uplata prošla.
Koji Stripe gradivni blok odgovara
- Stripe Checkout: hostovana stranica za plaćanje – najbrži put do usklađenog checkouta, već testiranog na konverziji, sa novčanicima i lokalnim metodama plaćanja.
- Payment Element: ugrađena polja za plaćanje na vašoj stranici, preko PaymentIntents API-ja, kada želite punu kontrolu izgleda i toka.
- SetupIntents: čuvanje kartice za kasnije ili naplatu bez prisustva kupca, uz autentifikaciju urađenu unaprijed.
- Stripe Billing: pretplate, probni periodi, obračun razlike (proration), fakture i korisnički portal, umjesto vlastitog crona za ponavljajuću naplatu.
- Stripe Connect: marketplace i platforme koje naplaćuju u ime prodavaca i dijele isplate.
Webhook je izvor istine
Preglednik kupca može se zatvoriti prije povratka na sajt, pa se narudžba mora označiti kao plaćena iz provjerenog webhooka, na primjer payment_intent.succeeded ili checkout.session.completed, a ne sa stranice zahvalnice. Naši handleri provjeravaju potpis na sirovom tijelu zahtjeva, preskaču događaje koje su već obradili, pravi posao predaju redu i brzo odgovaraju:
app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), async (req, res) => {
let event;
try {
event = stripe.webhooks.constructEvent(
req.body, req.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET
);
} catch (err) {
return res.status(400).send('Invalid signature');
}
if (await processedEvents.has(event.id)) return res.sendStatus(200);
if (event.type === 'payment_intent.succeeded') {
await queue.add('mark-order-paid', { intentId: event.data.object.id });
}
await processedEvents.add(event.id);
res.sendStatus(200);
});Na odlaznoj strani svaki zahtjev za kreiranje šaljemo sa idempotency ključem, tako da ponovni pokušaj zbog mreže ne naplati kupca dvaput. Lokalno cijeli tok testiramo Stripe CLI-jem (stripe listen --forward-to) i Stripe test karticama za 3-D Secure, odbijanja i sporove. Stripeova dokumentacija o webhookovima detaljno opisuje ponovne pokušaje i redoslijed događaja.
PayPal: podešavanje i integracija
Mnogi kupci više vjeruju PayPalu nego unosu podataka kartice u nepoznatu prodavnicu, a kod prekogranične prodaje PayPal često podiže završetak checkouta. Moderna PayPal integracija izgleda sasvim drugačije od starih “Buy Now” dugmadi i IPN skripti koje mnogi sajtovi i dalje koriste.
- Orders API v2: server kreira i naplaćuje narudžbu; preglednik samo prikazuje dugmad PayPal JavaScript SDK-a. Iznose uvijek računa server, a ne klijent.
- Capture ili authorize: trenutni capture za digitalnu robu, authorize pa capture kada naplaćujete tek nakon potvrde zaliha ili otpreme.
- Polja za karticu i Pay Later: tamo gdje su dostupni za vaš nalog i državu, PayPalova polja za karticu i Pay Later poruka mogu stajati pored PayPal dugmeta.
- Webhookovi umjesto IPN-a: PayPal webhookovi provjereni PayPalovim potpisom, obrađeni istim idempotentnim obrascem kao kod Stripea.
- Testiranje u sandboxu: odvojeni sandbox nalozi kupca i prodavca, uključujući neuspjele capture, povrate i sporove.
Pomažemo i oko poslovne strane: ispravno otvaranje business naloga, razumijevanje konverzije valute i vremena isplate, te činjenica da novi PayPal nalozi mogu imati zadržana sredstva neko vrijeme – to treba planirati prije puštanja, a ne otkriti poslije. Ako i dalje koristite PayPal Standard sa IPN-om, prelazak na REST API je obično mali i isplativ posao. PayPal Checkout dokumentacija opisuje trenutne opcije integracije.
Više gatewaya i usmjeravanje plaćanja
Oslanjanje na jednog pružaoca plaćanja je jedna tačka kvara za prihod. Podešavanje sa više gatewaya omogućava metode koje kupci na svakom tržištu očekuju, usmjeravanje transakcija po valuti ili državi i nastavak prodaje kada jedan pružalac padne ili zamrzne nalog.
Kako to projektujemo
- Jedan interni model plaćanja: svaki gateway je adapter iza zajedničkog ugovora, a svaka uplata prati jedan model stanja – na čekanju, autorizovana, naplaćena, vraćen dio iznosa, vraćena u cijelosti ili sporna.
- Pravila usmjeravanja: gateway se bira po državi kupca, valuti, iznosu ili metodi plaćanja, i to se mijenja bez novog deploymenta.
- Pametan failover: prelazak na drugog pružaoca pri tehničkim greškama i isteku vremena, a nikad pri odbijanju kartice – ponovni pokušaj odbijene kartice na drugom gatewayu izdavaocima izgleda kao prevara.
- Zajednički izvještaj: naknade, povrati i isplate svih pružalaca usklađeni sa narudžbama na jednom mjestu.
Plaćanja u Bosni i Hercegovini i regionu
Ovo je posebno važno kod nas. Stripe ne prima firme registrovane u Bosni i Hercegovini ili Srbiji, a PayPalove mogućnosti primanja zavise od države. Lokalne kompanije zato često spajaju bankarski procesor – Monri, WSPay, CorvusPay ili Nestpay stranicu banke – za domaće kartice, a PayPal ili firmu u podržanoj državi za inostrane kupce. Te hostovane stranice i njihove callbackove integrišemo sa istom strogošću kao Stripe, uključujući provjeru potpisa na svakom odgovoru.
Sigurnost plaćanja i PCI DSS
PCI DSS (Payment Card Industry Data Security Standard, trenutno verzija 4.0.1) važi za svaku firmu koja prima kartice. Koliko se standarda na vas odnosi zavisi gotovo u cijelosti od načina na koji je integracija napravljena – zato je arhitektura najjeftiniji alat za usklađenost koji imate.
| Pristup integraciji | Gdje se unose podaci kartice | Tipična PCI DSS samoprocjena | Kontrola checkouta |
|---|---|---|---|
| Hostovana stranica za plaćanje (redirect) | Stranica pružaoca | SAQ A | Ograničen branding |
| Ugrađena iframe polja (Payment Element, PayPal card fields) | Iframe pružaoca na vašoj stranici | SAQ A | Visoka |
| Direct post / forma sastavljena u JavaScriptu | Vaša stranica, šalje se direktno pružaocu | SAQ A-EP | Puna |
| Serverski API sa sirovim brojevima kartica | Vaši serveri | SAQ D (puni obim) | Puna, uz visok trošak usklađenosti |
Koji upitnik važi potvrđuje vaš acquirer ili pružalac, ali obrazac je jasan: gotovo uvijek gradimo na hostovanim stranicama ili iframe poljima, tako da sirovi brojevi kartica ne dotiču vašu infrastrukturu.
Strong Customer Authentication i 3-D Secure
Prema PSD2 u Evropskom ekonomskom prostoru, većina kartičnih plaćanja koja pokreće kupac zahtijeva Strong Customer Authentication, a to se ostvaruje kroz 3-D Secure 2. Kada je urađeno kako treba, mnoge uplate prolaze bez izazova, kroz frictionless tok; autentifikovane uplate u pravilu prebacuju odgovornost za fraud chargeback na izdavaoca kartice. Vodimo računa da integracija podržava izazov u modalu ili redirectu na telefonu, da izuzeća (mali iznos, transaction risk analysis, merchant-initiated ponavljajuća plaćanja) idu kroz pružaoca, a ne nagađanjem, i da se prva uplata pretplate autentifikuje kako bi obnove mogle ići off-session. Mnogi acquireri van EEA, uključujući naš region, takođe traže 3-D Secure.
Mjere sigurnosti oko checkouta
- Brojevi kartica i CVV se ne zapisuju u logove i ne čuvaju; radimo samo sa tokenima pružaoca i ID-jevima plaćanja.
- API ključevi žive u secrets manageru ili konfiguraciji okruženja, sa ograničenim ključevima koji imaju samo dozvole koje servis zaista treba.
- Strogi Content-Security-Policy i popis skripti na stranicama za plaćanje – PCI DSS 4.0 mnogo više insistira na kontroli skripti na tim stranicama.
- Zaštita od card-testing napada kroz rate limiting, bot izazove i alate pružaoca protiv prevare, kao što je Stripe Radar. Naš vodič za API rate limiting objašnjava te tehnike.
- Podaci o plaćanju u skladu sa GDPR-om: minimum ličnih podataka, jasan rok čuvanja i ugovori sa procesorima.
Pretplate, povrati i usklađivanje uplata
Prva uplata je lakši dio. Tekući prihod zavisi od onoga što dolazi poslije:
- Ponavljajuća naplata: planovi, probni periodi, nadogradnje sa obračunom razlike i dunning – pametni ponovni pokušaji plus poruke kojima kupca molite da ažurira isteklu karticu, čime se vraća znatan dio propalih obnova.
- Puni povrati i povrati dijela iznosa pokrenuti iz vašeg admina, usklađeni sa narudžbom, zalihama i knjigovodstvom.
- Sporovi: obavijest kada stigne chargeback, uz automatski prikupljene dokaze o narudžbi, isporuci i kupcu.
- Usklađivanje: svaka isplata povezana sa narudžbama, naknadama i povratima koje sadrži, tako da finansije to ne rade ručno u tabelama.
Iza svega stoji isti princip: nijedan događaj plaćanja ne smije nestati. U članku o e-commerceu bez gubitka podataka objašnjavamo kako narudžbe i uplate ostaju povratljive i kada nešto zakaže.
Integracija plaćanja: najčešće greške
- Narudžba se označava plaćenom na povratnom URL-u, umjesto iz provjerenog webhooka.
- Webhook handler radi spor posao u istom zahtjevu, istekne vrijeme i biva ponovljen, pa nastaju duple narudžbe ili poruke.
- Iznos ili valuta se prihvataju iz preglednika, pa bilo ko može platiti jedan cent za skupu narudžbu.
- Test i živi API ključevi su pomiješani, ili je tajni ključ završio u Gitu.
- Sačuvane kartice se naplaćuju off-session bez početne autentifikovane uplate, pa obnove padaju na grešci autentifikacije.
- Nema upozorenja kada skoči stopa neuspješnih plaćanja, pa pokvaren checkout ostane neprimijećen danima.
Kako radimo
- Upoznavanje: prolazimo tržišta, valute, metode plaćanja, model poslovanja (jednokratno, pretplata ili marketplace) i postojeću integraciju.
- Plan: predlažemo pružaoce i pristup integraciji koji sužava obim PCI DSS-a, i definišemo model stanja plaćanja i webhookove.
- Izrada: radimo checkout, webhookove, povrate, pretplate i usklađivanje, sa tajnama pod kontrolom od prvog dana.
- Testiranje: u sandboxu prolazimo svaki scenario – 3-D Secure izazove, odbijanja, isteke, duple webhookove, povrate i sporove.
- Puštanje: prelazimo na žive ključeve uz malu stvarnu transakciju, pa pomno pratimo stopu uspješnih plaćanja i isporuku webhookova.
- Podrška: pratimo promjene verzija API-ja i ukidanja kod pružalaca i dodajemo nove metode plaćanja kako rastete.
Zašto CodeWiz
- Plaćanja i cijeli stack: gradimo prodavnice, API-je i servere u koje se plaćanja uklapaju, pa probleme rješavamo od početka do kraja.
- Poznavanje regiona: iz Banje Luke razumijemo koje opcije plaćanja imaju firme u Bosni i Hercegovini i regionu, i gdje su ograničenja.
- Sigurnost od početka: sužen PCI obim, provjereni webhookovi i zaštićene tajne dio su svake integracije, a ne dodatna stavka.
- Rješenja po mjeri: hostovani checkout kada je to dovoljno, arhitektura sa više gatewaya kada to poslovanje traži.
- Fer cijene: vrhunski razvoj bez vrhunskih cijena – saznajte više o CodeWizu.
Često postavljana pitanja
Stripe ili PayPal – šta da izaberem?
Često oba. Stripe je odličan za kartice, novčanike i pretplate tamo gdje je dostupan; PayPal dodaje opciju kojoj mnogi kupci vjeruju. Gdje Stripe nije dostupan vašoj firmi, uobičajena kombinacija je lokalni bankarski procesor plus PayPal. Preporuku dajemo prema vašim tržištima i modelu.
Koliko košta integracija plaćanja?
Dodavanje hostovanog checkouta na podržanu platformu mali je posao. Checkout po mjeri, pretplate, marketplace ili usmjeravanje na više gatewaya sa usklađivanjem uplata traže znatno više rada. Naknade po transakciji su odvojene i plaćaju se pružaocu. Procjenu dajemo nakon pregleda zahtjeva.
Da li moram biti PCI DSS usklađen ako koristim Stripe ili PayPal?
Da, svaki trgovac koji prima kartice ima obaveze po PCI DSS-u, ali uz hostovane stranice ili iframe polja one se obično svode na kratki upitnik SAQ A. Obrada sirovih podataka kartice na vlastitim serverima tražila bi mnogo šire kontrole.
Šta je 3-D Secure i hoće li smanjiti konverziju?
3-D Secure je način na koji banka vlasnika kartice potvrđuje uplatu, na primjer potvrdom u aplikaciji banke. Uz 3-D Secure 2 mnoge uplate niskog rizika prolaze bez izazova, a u EEA je to ionako obavezno za većinu online kartičnih plaćanja. Dobro urađen tok drži taj dodatni korak kratkim.
Možete li srediti postojeću integraciju koja gubi narudžbe?
Možemo. Pregledamo kako su plaćanja i narudžbe povezani, dodamo provjerenu, idempotentnu obradu webhookova i usklađivanje, i tamo gdje je moguće uskladimo starije neusaglašene narudžbe iz podataka pružaoca.
Spremni da plaćanja rade pouzdano?
Recite nam gdje prodajete, kako naplaćujete i šta danas ne radi, a mi ćemo predložiti podešavanje plaćanja koje je sigurno i jednostavno za rad. Kontaktirajte nas, pročitajte naš raniji članak o sigurnoj i skalabilnoj integraciji payment gatewaya ili pogledajte naše usluge integracije plaćanja.