Payment launch checklista treba da odgovori na jedno praktično pitanje: da li je integracija spremna da bezbedno primi stvarne porudžbine i da li tim zna šta radi kada nešto pođe po zlu? Provera se ne završava uspešnom test transakcijom. Pre produkcije treba obuhvatiti pristupne podatke, tok statusa, webhook događaje, korisničko iskustvo, monitoring i plan za kontrolisano isključivanje plaćanja.
Ovaj vodič je namenjen timu koji priprema puštanje kartičnog plaćanja na sajtu ili u web aplikaciji. Za širi pregled izbora i implementacije payment rešenja pogledajte integraciju platnih kartica, dok je ovde fokus na poslednjoj proveri pred launch i procedurama za period neposredno nakon njega.
1. Definišite šta tačno puštate u produkciju
Pre tehničke provere zapišite granice izdanja. Nije isto da li se pušta nova checkout stranica, novi payment provider, samo Apple Pay ili kompletan tok sa refundacijama i sačuvanim načinima plaćanja.
- Koji način plaćanja je obuhvaćen izdanjem?
- Koje valute, zemlje, tipovi kartica i iznosi su podržani?
- Da li se autorizacija i naplata izvršavaju odmah ili u odvojenim koracima?
- Koji sistem je izvor istine za status porudžbine?
- Ko može da odobri puštanje, a ko može da zaustavi plaćanje?
Ova specifikacija sprečava da se „uspešan launch“ proceni samo na osnovu jedne kartice i jednog pozitivnog scenarija. Ako se istovremeno menja i ostatak sajta, jasno odvojite payment promene od drugih izmena. Za složenije projekte može pomoći i izrada sajta sa jasno definisanim scope-om, odgovornostima i planom izdanja.
2. Bezbednosna provera pre produkcije
Payment podaci zahtevaju strogo upravljanje pristupom i pažljivo rukovanje logovima. Konkretne obaveze zavise od arhitekture i načina na koji se podaci kartice obrađuju, pa pre launch-a proverite primenljive zahteve sa payment providerom i stručnim licem za usklađenost. Kao referentni okvir koristite aktuelni PCI DSS standard, a za širu proveru bezbednosti aplikacije i OWASP ASVS.
- Produkcioni ključevi nisu u repozitorijumu, front-end kodu, ticketima ili javnim logovima.
- Testni i produkcioni nalozi, ključevi i webhook endpointi jasno su razdvojeni.
- Pristup dashboardu providera koristi individualne naloge i odgovarajuće privilegije.
- Webhook endpoint proverava autentičnost događaja prema preporučenom mehanizmu providera.
- Osetljivi podaci, tokeni i kompletni podaci kartice ne pojavljuju se u aplikacionim logovima.
- Greške ne otkrivaju interne detalje sistema, ključeve ili korisničke podatke.
- Postoje evidentirani vlasnici tajni, procedura rotacije i plan za opoziv kompromitovanih ključeva.
Posebno proverite da li se korisniku prikazuje jasan rezultat kada se korisnik vrati sa payment stranice, ali webhook još nije obrađen. Povratak u browseru nije dovoljan dokaz da je transakcija uspešno završena.
3. Testirajte ceo tok, ne samo „success“ slučaj
Pre produkcije prođite kroz scenarije u sandboxu, ali testove organizujte prema stvarnim poslovnim posledicama. Za detaljniju razradu test matrice korisni su tekst Testiranje payment integracije: sandbox, edge cases i failure scenariji i sledeća kratka kontrolna lista:
- uspešna autorizacija i uspešna naplata;
- odbijena kartica, nedovoljno sredstava i neuspešna autentikacija;
- prekid ili zatvaranje browsera tokom plaćanja;
- duplo klikanje na dugme za plaćanje i ponovljen zahtev;
- kašnjenje, ponavljanje ili promena redosleda webhook događaja;
- uspešna naplata uz grešku pri ažuriranju porudžbine;
- refundacija, delimični refund i otkazivanje porudžbine;
- razlika između iznosa, valute ili identifikatora porudžbine;
- istekao checkout session ili povratak na zastarelu stranicu.
Za svaki scenario zapišite očekivani status porudžbine, poruku korisniku, događaj u logu i sledeću operativnu radnju. Ako se isti zahtev može ponoviti, definišite kako sistem sprečava duplu naplatu ili duplo kreiranje porudžbine.
4. Monitoring koji pokazuje šta se zaista dešava
Monitoring ne treba da prati samo da li je checkout stranica dostupna. Potrebno je posmatrati ceo tok od kreiranja porudžbine do konačnog statusa naplate.
| Oblast | Šta pratiti | Zašto je važno |
|---|---|---|
| Checkout | Greške pri učitavanju, prekidi i neuspešni pokušaji | Otkriva probleme pre nego što stignu do providera |
| Provider | Odbijanja, timeout-i, greške API-ja i status servisa | Razdvaja lokalni problem od problema spoljnog sistema |
| Webhook | Primljeni, obrađeni, ponovljeni i neuspešni događaji | Pokazuje da li se status naplate pravilno prenosi u aplikaciju |
| Porudžbine | Porudžbine bez konačnog payment statusa | Ukazuje na moguće zaglavljene ili neusaglašene slučajeve |
| Finansije | Razlike između porudžbina, transakcija i izveštaja | Omogućava pravovremenu proveru obračuna |
Definišite pragove za alarmiranje bez izmišljanja univerzalnih procenata. Prag treba da zavisi od uobičajenog obima, sezonalnosti, poslovnog rizika i mogućnosti ručne intervencije. Alarm bez vlasnika i procedure nije monitoring, već samo još jedna notifikacija.
Za finansijsko usklađivanje podataka koristite zaseban proces. Vodič Reconciliation: kako povezati porudžbine, transakcije i bankarske izveštaje detaljnije obrađuje vezu između porudžbine, transakcije i bankarskog izveštaja.
5. Rollback plan: šta se isključuje i kojim redom
Rollback nije samo vraćanje prethodne verzije koda. Kod payment integracije može postojati transakcija koja je uspešna kod providera, ali nije pravilno evidentirana u aplikaciji. Zato plan mora razdvojiti tehničko vraćanje izdanja od obrade već započetih plaćanja.
- Uslov za aktiviranje: navedite ko donosi odluku i koji simptomi zahtevaju pauzu, na primer nekonzistentni statusi ili neobrađeni webhook događaji.
- Način ograničavanja štete: odredite da li se isključuje payment metoda, checkout, određena zemlja ili cela nova funkcija.
- Bezbedna obrada postojećih transakcija: proverite status kod providera pre ponavljanja naplate ili izdavanja refundacije.
- Vraćanje kompatibilne verzije: baza, webhook format i konfiguracija moraju ostati kompatibilni sa događajima koji kasne.
- Komunikacija: odredite poruku korisničkoj podršci, finansijama i korisnicima koji su ostali bez jasnog statusa.
- Reconciliation posle incidenta: napravite spisak neusaglašenih porudžbina i zatvorite ga tek nakon provere.
Rollback treba probati u kontrolisanom okruženju, makar kroz tabletop vežbu: jedna osoba prijavljuje incident, druga proverava payment dashboard, treća prati porudžbine i komunikaciju. Cilj nije simulirati svaki kvar, već proveriti da li odluke, pristupi i odgovornosti postoje pre stvarnog problema.
6. Launch dan i period posle puštanja
Na dan puštanja uvedite jasan redosled:
- sačuvajte verziju koda i konfiguracije koja je puštena;
- potvrdite da su produkcioni ključevi i webhook konfiguracija aktivni;
- izvedite kontrolisanu stvarnu transakciju ako je to dozvoljeno i dogovoreno;
- proverite da su porudžbina, email potvrda i payment status usklađeni;
- pratite dashboard, logove i neusaglašene slučajeve;
- zapišite vreme puštanja, nalaze i sve ručne intervencije.
Nemojte zatvoriti proveru odmah nakon prve uspešne kupovine. Ostavite dogovoren period pojačanog nadzora i unapred definišite kada se launch smatra stabilnim. Ako se uvedu sačuvane kartice ili ponovljene kupovine, potrebna je dodatna provera UX-a, tokenizacije i kontrola pristupa; za tu temu pogledajte Saved cards: UX i bezbednosni zahtevi za ponovnu kupovinu.
Praktičan kriterijum spremnosti
Payment integracija je spremna za launch kada tim može da pokaže ne samo uspešnu naplatu, već i jasan odgovor na četiri pitanja: kako se proverava identitet događaja, kako se otkriva neusaglašen status, ko zaustavlja rizičan tok i kako se obrađuju već započete transakcije tokom rollback-a. Ako na bilo koje pitanje nema konkretnog vlasnika, loga ili procedure, sledeći korak nije agresivnije puštanje već zatvaranje te praznine.
