Integracija platnih kartica za stabilno online plaćanje

Pre razvoja mapiramo šta se naplaćuje, kada nastaje porudžbina, koji statusi postoje i ko je izvor istine za transakciju. Drugačiji pristup potreban je za jednokratnu kupovinu, rezervaciju sredstava, pretplatu, članarinu, digitalnu uslugu ili kombinaciju proizvoda i dostave. Na osnovu toga definišemo komunikaciju između frontenda, vašeg servera i payment gateway-a, kao i podatke koji se vraćaju administraciji i korisničkoj podršci.

Posebnu pažnju posvećujemo granicama odgovornosti. Korisnik može napustiti stranicu, gateway može odgovoriti sa zakašnjenjem, a webhook može stići više puta. Zato se status ne zasniva samo na povratku korisnika u browser, već na serverskoj potvrdi i idempotentnoj obradi događaja. Pre implementacije usaglašavamo statusni model, pravila za ručne intervencije i način merenja ključnih tačaka toka, kako bi razvojni, finansijski i operativni tim imali isto tumačenje transakcije.

• jednokratna kartična naplata i autorizacija;
• 3DS tokovi i povratni statusi;
• tokenizacija za bezbedno čuvanje payment referenci;
• recurring payments, kada ih podržavaju model i gateway;
• refundacije, storno i delimični povraćaj novca.

Bezbednost plaćanja nije jedan checkbox u checkout-u. 3DS može zahtevati dodatnu korisničku akciju, preusmeravanje ili prikaz autentifikacionog ekrana, pa tok mora pravilno da obradi i uspeh i prekid. Tokenizacija može smanjiti potrebu da vaš sistem rukuje osetljivim podacima kartice, ali način upotrebe tokena, pristup podacima i odgovornosti i dalje moraju biti jasno definisani sa payment provajderom.

Tokom planiranja razmatramo PCI scope, hosting, logove, pristupe, tajne ključeve i okruženja za testiranje. Sa vašim developerima i provajderom usaglašavamo koji podaci napuštaju sistem, gde se čuvaju reference i ko može da pokrene refundaciju ili promeni konfiguraciju. Ne predstavljamo integraciju kao zamenu za pravnu, bezbednosnu ili regulatornu procenu vašeg provajdera. Naš zadatak je da tehničku implementaciju postavimo tako da se osetljivi podaci ne izlažu nepotrebno, da se greške ne upisuju u logove i da se produkcioni kredencijali odvoje od testnih.

• kontrola podataka koji ulaze u logove i analitiku;
• odvajanje testnog i produkcionog okruženja;
• verifikacija webhook potpisa i dozvola;
• bezbedno upravljanje ključevima i konfiguracijom;
• jasno dokumentovan PCI scope u okviru rešenja.

Korisnik vidi checkout, ali poslovni sistem mora da nastavi da radi nakon toga. Posle potvrđene naplate mogu se aktivirati nalog, digitalna isporuka, rezervacija, faktura, obaveštenje ili interno odobrenje. Zato povezujemo payment događaje sa vašim postojećim modelom porudžbina i definišemo šta se dešava kada isporuka kasni, kada refundacija bude izvršena ili kada se transakcija naknadno označi kao neuspešna.

Za recurring payments dodatno se obrađuju obnova pretplate, neuspešna naplata, promena payment metode i otkazivanje. Kod refundacija razlikujemo pun i delimičan povraćaj, čuvamo vezu sa originalnom transakcijom i omogućavamo da operater ne mora ručno da usklađuje više sistema. Ako je vaš backend deo šire platforme, integraciju uklapamo u postojeće API-je umesto da uvodimo paralelnu evidenciju.

Pre puštanja usaglašavamo i operativna pravila: ko prati neuspešne obnove, kada se šalje obaveštenje korisniku, koji događaj aktivira isporuku i kako se rešava neslaganje između gateway-a i interne evidencije. Tako payment integracija podržava stvarni poslovni proces, a ne samo tehnički završetak checkout-a.

Payment integracija se ne proverava samo jednom uspešnom testnom karticom. Testiramo neuspešne autorizacije, odbijanje 3DS provere, prekid preusmeravanja, zatvaranje prozora, duplirani webhook, zakašnjeli događaj, neusklađen povratak korisnika i pokušaj ponovljene naplate. Proveravamo i da li se porudžbina, korisnički nalog, email obaveštenje i administrativni prikaz menjaju u očekivanom redosledu.

Test plan povezujemo sa rizicima vašeg poslovnog modela. Kod pretplata proveravamo obnovu i otkazivanje; kod robe refundaciju i delimični povraćaj; kod digitalnih usluga aktivaciju tek nakon potvrđenog statusa. Proveravamo i dozvole za refundacije, ponašanje pri ponovljenom webhook-u, sadržaj logova i mogućnost da podrška pronađe transakciju prema dostupnim identifikatorima.

Pre produkcije definišemo šta se smatra uspešnim završetkom i ko dobija informaciju kada je potrebna ručna intervencija. U okviru primopredaje ostavljamo dokumentaciju o konfiguraciji, statusima i testnim scenarijima, kako bi vaš tim mogao da dijagnostikuje problem bez oslanjanja na pretpostavke. Ako već postoji implementacija, prvo radimo pregled tokova, logova i poznatih neusaglašenosti.

Payment komponenta mora da odgovara tehnologiji i ograničenjima sistema u koji se ugrađuje. Radimo sa postojećim backend-om, CMS-om, custom aplikacijom ili zasebnim servisom, uz dogovor oko API-ja, autentifikacije, baza podataka i odgovornosti za deploy. Na početku razdvajamo ono što možemo da implementiramo samostalno od onoga što zahteva pristup vašem kodu, gateway nalogu, hostingu ili internim servisima.

Kada je potreban razvoj administrativnih funkcija ili sadržajnog sistema, možemo ga razdvojiti od payment jezgra kako promene u jednom delu ne ugroze naplatu. Sa vašim developerima usaglašavamo branch, code review, okruženja, migracije i plan puštanja. Za projekte kojima je potreban specifičan sadržajni i operativni sloj relevantan je i Custom CMS.

Za širi projekat izrade i povezivanja sajta pogledajte izradu sajta. Ova stranica, međutim, ostaje fokusirana na integraciju platnih kartica: payment tok, serversku obradu, sigurnost, statusnu logiku i vezu sa vašim poslovnim procesima.