Integracija plaćanja za agencije iz Beograda: SaaS, e-commerce i marketplace

Agencije u Beogradu najčešće rade tri tipa payment integracija: SaaS pretplate, e-commerce checkout i marketplace tokove. Svaki od ova tri ima drugačije zamke koje se ne vide u prvom estimate-u, ali izađu na površinu u prvom mesecu produkcije. Ovaj vodič vam pomaže da svaki tip postavite stabilno i bez kasnijih iznenađenja sa klijentom.

Zašto agencije ne smeju da uzimaju payment integracije laganog srca

Payment integracija nije samo "implementiraj API". To je sloj proizvoda koji direktno utiče na prihod klijenta i koji je pod regulatornim okvirom. Bitno je odmah razdvojiti šta čije: PSD2/SCA enforce-uje izdavajučka banka kroz ACS, agencija samo wire-uje 3DS2 i exemption flag-ove (TRA za niske rizike, low-value < 30 EUR, MIT za pretplate, recurring); KYC/KYB ne potpada pod PSD2 nego pod AMLD5/6 i Zakon o sprečavanju pranja novca; PCI DSS scope zavisi od integracionog obrasca koji birate, ne od razgovora sa klijentom.

Druga strana priče je da payment integracije, dobro odrađene, jesu jedan od najboljih retainera koje agencija može da gradi. Klijent koji je dobio stabilnu naplatu obično ostaje godinama, jer migracija je bolnija od svake nove funkcije.

PCI DSS scope: SAQ-A vs SAQ-A-EP i šta to znači za agenciju

Najvažnija arhitektonska odluka koju agencija donosi je integracioni obrazac, jer on direktno određuje PCI scope klijenta. Hosted checkout (Stripe Checkout, redirect) i hosted iframe sa potpunim outsourcing-om kartice → SAQ-A (~22 zahteva, jednostavna godišnja samoprocena). Stripe Elements ili sopstvena merchant stranica koja može da utiče na payment flow → SAQ-A-EP (~191 zahtev, kompleksniji audit).

PCI DSS v4.0.1 je obavezan od 2025: zahtevi 6.4.3 (script integrity inventory) i 11.6.1 (payment-page tampering detection) sada važe za SAQ-A-EP i deo SAQ-A merchant-a. Praktično, agencija mora da isporuči CSP politike, SRI hash-ove na payment skripte i monitoring tampering-a. Ovo ne sme biti propušteno u ugovoru - ako ga ne pomenete, klijent se kasnije pita zašto pada audit.

Use-case 1: SaaS pretplate

Klijent dolazi sa proizvodom (često Angular ili Next.js front, Node ili Laravel back) i traži pretplatnu naplatu. Pre nego što napravite estimate, mora se odgovoriti: koje tržište, koja valuta, koji model planova, koja platforma za billing. Razlika između CorvusPay (gradite billing u backend-u) i Paddle (oni daju gotov subscription engine) je između 3 i 12 nedelja rada.

• Definisati planove, pravila prelaska, trial logiku i refund politiku PRE prve linije koda.
• Izabrati platformu na osnovu tržišta klijenta (regional - lokalni gateway, globalno - MoR).
• Implementirati webhook obradu sa idempotentnošću, ne pretpostaviti da ne stiže duplo.
• Postaviti dunning tok za neuspele naplate, sa kombinacijom email i in-app obaveštenja.
• Logovati svaku promenu billing statusa za podršku i finansijski tim klijenta.

Najveća zamka u SaaS projektima je to što klijent često ne razume razliku između "kartica je sačuvana" i "pretplata je aktivna". Ovo treba eksplicitno definisati u acceptance criterijuma, jer u suprotnom QA prolazi, a prva nedelja u produkciji puca jer pretplata nije ispravno povezana sa korisničkim pristupom.

Use-case 2: E-commerce checkout

Tipičan e-commerce projekat traži checkout sa karticama, IPS-om, opcijom rate i pouzeća. Različiti klijenti imaju različite kombinacije i različite preferencije po kategoriji proizvoda. Agencija koja u prvom workshop-u napravi mapu metoda po kategoriji i prosečnoj korpi štedi sebi nedelje preformulisanja kasnije.

• Map metoda po kategoriji - niska korpa traži brzu karticu, visoka traži rate i poverenje.
• Mobilni checkout je default, ne dodatak - testirati na sporijoj mreži pre lansiranja.
• Trust signali (povraćaj, podrška, bezbedno plaćanje) više utiču na konverziju nego dizajn.
• 3DS2 tok mora biti glatko integrisan, sa jasnom porukom korisniku da sledi potvrda.
• Refund i chargeback procedura - ko šta radi, ko obaveštava klijenta, ko vodi evidenciju.

E-commerce klijenti često misle da je checkout završen kad transakcija prođe. Realnost je da checkout završava kad se obradi povraćaj, kad chargeback bude rešen u korist trgovca, i kad se reklamacija razreši bez gubitka kupca. Agencija koja u handover paketu uključi i ove tokove dobija mnogo manje hitnih poziva tri meseca kasnije.

Use-case 3: Marketplace i split payment

Marketplace je najteža kategorija. Imate prodavca (više njih), kupca, platformu (klijenta agencije) i pravnu konstrukciju ko je zapravo prodavac. Tehnički sloj zahteva split payment: kupac plaća jedan iznos, deo ide prodavcu, deo platformi. Pravni sloj zahteva ugovore, KYC/KYB svakog prodavca i tretman PDV-a koji često nije rešen na početku projekta.

Bitan detalj: u većini jurisdikcija, da biste legalno držali tuđa sredstva, potrebna je EMI (e-money institution) licenca. Agencija ne može jednostavno da otvori "escrow račun" - mora se osloniti na licencirani sloj. To su tipično platforme koje su već licencirane: Stripe Connect, Adyen for Platforms, Mangopay (EMI licenca u EU), Mollie Connect, Ryft, Lemonway. Bez licenciranog provajdera, kombinacija je ili pravno problematična ili tehnički neelegantna.

Marketplace platforme: konkretne opcije

• Stripe Connect Standard - prodavac ima sopstveni Stripe nalog, KYC self-served, najmanje pravne odgovornosti za platformu.
• Stripe Connect Express - Stripe-hosted KYC, branded sa imenom platforme, default za ~90% slučajeva.
• Stripe Connect Custom - puna API kontrola, platforma vlasnik svih KYC/KYB obaveza, traži dedicated tim.
• Adyen for Platforms (formerly MarketPay) - enterprise, balance accounts, ~£50M+ volumena.
• Mangopay - EMI-licencirana u EU, e-wallet i escrow built-in, 15 valuta - jak fit za EU marketplace-e koji moraju da drže sredstva.
• Ryft, Lemonway - EU alternative sa fleksibilnijim onboarding-om za nove platforme.

Iz Srbije, marketplace dodatno nailazi na zid: lokalni gateway-i ne podržavaju split payment elegantno, a većina MoR platformi (Paddle, FastSpring, 2Checkout) ne prihvata marketplace modele. Stripe Connect zahteva strani entitet za platformu. Mangopay je obično optimalan za marketplace iz EU.

• Pravna struktura PRE tehnike - ko je prodavac u pravnom smislu, kako tretira PDV.
• KYC za prodavce na platformi - obaveza po AMLD5/6, ne PSD2; specifično pravilo zavisi od jurisdikcije.
• Audit log za svaku transakciju sa razdvajanjem provizije platforme i payout-a prodavcu.
• Plan za rešavanje sporova između kupca i prodavca - ko vodi proces, ko odlučuje.
• Compliance officer ili partner koji prati AML alarme - bez ovoga marketplace ne sme da krene.

Šta agencija mora da uradi PRE potpisa ugovora

Najveće finansijske gubitke agencije prave kada ugovor uđe u obim koji nije realno specificiran. Payment integracija je posebno opasna jer izgleda jednostavno u prvom razgovoru ("samo dodaj Stripe"), a u praksi otvara desetine pitanja koja zahtevaju klijentove odluke. Workshop pre potpisa, plaćen ako treba, vraća se 5x u izbegnutim revizijama opsega.

• Mapa tržišta i valuta u kojima klijent prodaje.
• Lista metoda plaćanja koje klijent zaista treba (ne sve što postoji).
• Pravna struktura: ko je prodavac, gde je registrovan, kako se tretira PDV.
• Kalendar zakonskih i regulatornih obaveza (PSD2, PCI, BOI ako je strani entitet).
• Plan održavanja posle launch-a - retainer, SLA na incidente, ko prati metrike.

Webhook arhitektura koja zaista radi pod opterećenjem

Idempotentnost se često pomene ali retko ispravno implementira. Pravi obrazac: verifikuj signature (HMAC-SHA256, constant-time compare, 5-min timestamp tolerance) → enqueue u brokera → odgovori 2xx u <2s → procesiraj asinhrono. Idempotency proverava se kroz unique constraint na event-id u bazi (ne kroz "check then write" - tu je race uslov). Stripe pokušava 3 dana, Adyen do ACK-a; potreban je dead-letter queue za poison events sa manual replay.

Drugi tipičan propust: redosled događaja NIJE garantovan. customer.subscription.updated može stići pre customer.subscription.created. Handler-i moraju biti order-independent ili koristiti buffer/resequence po "created" timestamp-u. Bez ovoga, race uslovi ulaze u produkciju i pojavljuju se nedeljama kasnije kao "tajanstveni" bug-ovi.

Money handling: integeri, ne floats

Najpoznatiji bug u payment integracijama: čuvanje iznosa kao float. JavaScript 0.1 + 0.2 daje 0.30000000000000004 - na 100,000 transakcija to su ozbiljne razlike u finansijama. Pravilno: čuvajte iznose kao integere u najmanjim jedinicama (centi, para, fillers), formatirajte tek u UI sloju. Ovo važi za bazu, API kontrakte, izveštaje i sve ostalo.

Drugi tipičan bug: currency mismatch. Refund u različitoj valuti od originalne transakcije, FX margin koji se ne računa pri payout-u, exchange rate koji se uzima u pogrešnom trenutku (na trenutku transakcije vs trenutku settlement-a). Ovo se ne hvata bez eksplicitnih test scenarija.

Klopke koje stalno vidimo u handover-u

• Webhook obrada bez idempotency keya - prvi dupli event pravi haos u bazi.
• Floats za novac umesto integera u minor units - subtilne greške koje se kumuliraju.
• 3DS2 fallback nije pokriven (ACS može da overrides exemption request), neki kupci ne mogu da plate.
• Webhook race vs DB write - status promene stižu pre nego što se osnovni record zapiše.
• Timezone drift na subscription anchor datumima - pretplata se obnavlja u 23:59 prethodnog dana.
• Refund logika živi samo u admin panelu - kada klijent zatraži automatski refund, ništa ne radi.
• Chargeback obaveštenja se "progutaju" - stigne webhook ali ga niko ne procesira.
• Nema audit log-a za promene billing statusa, pa podrška ne može da rekonstruiše šta je bilo.

Realan estimate u satima po use-case-u

• Discovery faza (workshop + payment audit) - 16-40h.
• SaaS sa Stripe Billing/Paddle (gotov subscription engine) - 80-160h.
• SaaS sa custom recurring (CorvusPay/Monri + sopstveni billing) - 200-500h.
• E-commerce checkout (kartice + IPS QR + 3DS2 + chargeback flow) - 120-280h.
• Marketplace Stripe Connect Express - 250-600h.
• Marketplace Connect Custom ili Mangopay sa custom KYC tokovima - 800h+.

Acceptance criteria template

• Happy path - signup, naplata, faktura.
• 3DS challenge tok - korisnik prima OTP, vraća se u istu sesiju.
• Declined card - hard decline, soft decline, retry logika za soft.
• Network timeout pri create payment - korisnik ne plaća dva puta.
• Duplicate webhook - status se ne menja drugi put.
• Refund - puni i delimični, sa pravilnim accounting.
• Partial refund - sa pravilnim računovodstvom u finansijama klijenta.
• Chargeback - notifikacija, evidencija, plan odgovora.
• Subscription pause/resume - access se gasi/vraća, billing se zaustavlja.
• Failed renewal + dunning - retry sekvenca, korisnik dobija obaveštenja, dobija šansu da ažurira karticu.
• Currency mismatch - refund u istoj valuti kao naplata, FX se ne računa pogrešno.

Šta agencija ugovorom isporučuje vs šta ostaje na klijentu

Eksplicitno razdvojite u ugovoru. Agencija isporučuje: bezbednu integraciju u skladu sa odabranim integracionim obrascem (SAQ-A ili SAQ-A-EP), handover dokumentaciju (runbook, retry logika, monitoring), test pokrivenost gore navedenih scenarija, monitoring/alerting setup. Klijent zadržava: PCI DSS atestaciju (SAQ ili ROC), AML/KYC obaveze ako je marketplace, dispute handling i komunikaciju sa kupcima, poreske obaveze (PDV, sales tax, OSS), monitoring fraud-a posle launch-a.

Ako se ovo ne razdvoji, klijent posle mesec dana zove sa pitanjem ko treba da popuni SAQ - i ako je vaš ugovor neeksplicitan, posao pada na vas i ne plaća se. RACI matrica u ugovoru je 30 minuta rada koje vraća dane kasnije.

Kako pakovati ponudu klijentu

Trostepena ponuda obično prolazi najbolje: discovery (workshop + payment audit), implementation (integracija po izabranoj platformi) i ongoing support (retainer za održavanje). Klijent dobija jasan put, agencija dobija predvidiv prihod, a proizvod dobija stabilnu naplatu.

Neka discovery faza bude plaćena. Ako klijent nije spreman da plati 1-3 dana stručnog rada za pravilan setup, kasnije neće biti spreman ni za hitne intervencije. To je rani signal da odnos neće dobro završiti.

Kada da pošaljete klijenta drugom timu

Ne svaki payment projekat odgovara svakoj agenciji. Ako klijent traži marketplace sa kompleksnim KYC-om, a vaš tim do sada radio samo standardne kartične integracije, iskreno preporučite specijalizovanog partnera. Bolje je da klijent ode kod nekog ko zna, nego da vi učite na njegovom budžetu i izgubite ga zauvek.

Slično, ako klijent traži Stripe iz Srbije, a vi nemate iskustva sa američkim LLC-om i transfer pricing-om, partnerstvo sa specijalizovanom firmom (poput Pejmo) daje bolji ishod od improvizacije. Klijent dobija ispravan setup, vi dobijate proviziju ili partnerski deal, niko ne gubi.

Zaključak

Payment integracije su dobar posao za beogradske agencije, ali samo ako se tretiraju kao specijalizovan domen, ne kao standardni feature. SaaS pretplate, e-commerce checkout i marketplace tokovi imaju različite zamke koje se rešavaju različitim arhitekturama. Workshop pre potpisa, jasan handover paket i retainer posle launch-a su tri stuba koji projekte čine profitabilnim za obe strane.

Ako vam treba partner koji vam pomaže da pripremite payment deo projekta, ili da specijalizovani sloj (Stripe Atlas, MoR, marketplace setup) bude rešen profesionalno - javite nam se. Radimo direktno sa agencijama na podelama uloga koje funkcionišu.