WooCommerce i plaćanje karticama u Srbiji: šta zaista treba pripremiti
Papiri, obavezne stranice prodavnice i detalji naplate koje domaća WooCommerce prodavnica mora da ima pre nego što kartično plaćanje bude odobreno i pušteno u rad.
Marko Stančić8 minuta
Beleška s terena / Priprema za naplatu
Kartično plaćanje u domaćoj prodavnici ne uključuje se pluginom. Pre nego što banka ili procesor odobri prodavnicu, morate imati registrovanu firmu sa poslovnim računom i potpisan ugovor o prihvatanju platnih kartica, a sajt već tada mora da sadrži uslove prodaje, politiku privatnosti, postupak reklamacije i povraćaja novca, uslove i rokove dostave, cene u dinarima sa jasnim PDV statusom i punu identifikaciju firme.
Dva posla ovde teku paralelno i ne završavaju se u isto vreme. Tehnička integracija WooCommerce prodavnice sa sistemom za kartičnu naplatu je merljiv zadatak sa jasnim krajem. Odobrenje trgovca nije: ono zavisi od toga šta neko sa druge strane vidi kada otvori vaš sajt bez ijedne reči objašnjenja. Ovo je spisak onoga što mora da postoji pre nego što predate prijavu, i onoga što se u samoj integraciji najčešće previdi.
Šta mora da postoji pre nego što sajt uopšte pogledaju
Prihvatanje kartica je finansijska usluga i ugovara se sa institucijom, ne sa softverom. Osnovni preduslovi su isti bez obzira na to kome se obraćate:
Registrovano privredno društvo ili preduzetnik, sa delatnošću koja pokriva ono što zaista prodajete.
Poslovni račun kod banke na koji sredstva stižu posle obračuna.
Ugovor o prihvatanju platnih kartica sa bankom koja obrađuje kartična plaćanja, ili sa platnim procesorom koji taj deo preuzima na sebe.
Dokumentacija za proveru klijenta: izvod iz APR-a, podaci o ovlašćenom licu i stvarnim vlasnicima i potvrda o PIB-u.
Opis asortimana, realna procena prosečne vrednosti porudžbine i mesečnog prometa, i adresa sajta koji ide u produkciju.
Tu se donosi i prva odluka sa tehničkim posledicama. Ugovor direktno sa bankom, na primer sa Banca Intesom za web shop, znači jedan ugovorni odnos, jednu integraciju i pregovor o proviziji sa jednom stranom. Platni procesor kao što je CorvusPay stoji između prodavnice i banke, a zauzvrat nudi jedan tehnički priključak za više kartičnih brendova, održavan WooCommerce modul i sopstvenu podršku onda kada transakcija zapne.
Nijedan izbor nije unapred jeftiniji. Uporedite proviziju po transakciji, fiksne mesečne troškove, rok za isplatu na račun i količinu posla koja ostaje na vama kada nešto krene naopako. Pitajte i šta je tačno obuhvaćeno: DinaCard, Visa i Mastercard, plaćanje na rate, IPS QR kod za instant plaćanje, kao i to da li se delimičan povraćaj i povraćaj posle obračuna rade kroz isti kanal ili ručno. Poslednje pitanje deluje sitno sve dok vam ne zatreba.
Jedna napomena o planiranju. Datum lansiranja ne vezujte za datum odobrenja koji ne kontrolišete. Prodavnica treba da može da radi sa pouzećem i uplatnicom od prvog dana, a kartično plaćanje da se uključi kada odobrenje stigne. Tako lansiranje ne zavisi od tuđeg reda čekanja.
Šta se proverava na sajtu
Kada prijava stigne, neko otvara sajt kao običan posetilac i traži konkretne stvari. Ne čita marketinški tekst i neće vas zvati da pita. Ako u nekoliko minuta ne nađe ovo, prijava se vraća:
Uslove prodaje pisane za vašu prodavnicu, sa vašim poslovnim imenom u samom tekstu.
Politiku privatnosti koja kaže koje podatke prikupljate, zašto, koliko dugo ih čuvate i kome ih prosleđujete, uključujući i platnog procesora.
Postupak reklamacije i povraćaja novca: kako se reklamacija izjavljuje, u kom roku odgovarate i na koji način novac stiže nazad kupcu.
Uslove i rokove dostave, sa cenom dostave i teritorijom koju pokrivate.
Cene u dinarima, sa jasno naznačenim PDV statusom. Ako niste u sistemu PDV-a, i to mora da piše.
Punu identifikaciju firme: poslovno ime, adresu sedišta, matični broj i PIB, dostupne sa svake stranice, obično u futeru.
Kontakt koji stvarno radi: telefon i imejl adresu, ne samo formu.
Logotipe kartica koje prihvatate i tekst o zaštiti podataka o transakciji u obliku koji banka traži, kao i izjavu o valuti naplate ako cene prikazujete i u drugoj valuti.
Poslovno ime, sedište, matični broj i PIB na sajtu nisu zahtev banke nego zakonska obaveza privrednog društva, pa tu nema pregovora. Dva roka se najčešće pogrešno prepišu: pravo potrošača da odustane od ugovora zaključenog na daljinu u roku od četrnaest dana i rok u kome ste dužni da odgovorite na izjavljenu reklamaciju. Otvorite aktuelni tekst Zakona o zaštiti potrošača i upišite tačne rokove umesto da preuzmete formulaciju sa tuđeg sajta. Prepisani uslovi prodaje u kojima je ostalo ime druge firme najbrži su poznati način da prijava bude vraćena.
Isto važi i za mesto na kome te stranice stoje. Treba da budu dostupne iz futera na svakoj stranici, a ne samo u poslednjem koraku naplate, a polje za prihvatanje uslova na naplati mora da vodi do njih linkom koji radi.
Radni princip
Prodavnicu ne odobrava plugin. Odobrava je ono što na sajtu piše kada ga neko otvori bez najave.
Zbog čega se prijave najčešće vraćaju
Razlozi se ponavljaju i skoro nijedan nije tehnički težak:
Sajt je još iza lozinke ili u režimu održavanja, ili je prijavljena staging adresa umesto produkcijske.
Cene stoje samo u evrima, ili se PDV pojavljuje tek u poslednjem koraku naplate.
Adrese sedišta, matičnog broja i PIB-a nema nigde na sajtu.
Stranica o dostavi i uslovi prodaje navode različite rokove.
Asortiman na sajtu ne odgovara delatnosti i opisu iz prijave.
SSL sertifikat je istekao ili deo stranica i dalje ide preko nezaštićene veze.
Na telefon sa sajta niko se ne javlja, a poruke poslate na navedenu imejl adresu vraćaju se pošiljaocu.
Sve je to jeftino dok se prodavnica gradi, a skupo kada se prijava vrati, jer se tada čeka novi krug provere. Kada radimo razvoj WooCommerce prodavnica, ove stavke ulaze u plan zajedno sa katalogom i naplatom, a ne posle lansiranja.
HTTPS, 3-D Secure i izbor forme za plaćanje
HTTPS ide na ceo sajt, ne samo na korpu. Mešani sadržaj je dovoljan da provera padne: jedna stara slika ili skripta učitana preko nezaštićene veze. Sertifikat mora da ima automatsku obnovu i nadzor, jer istekli sertifikat ne obara samo sajt nego i povratni poziv procesora, a to se primeti tek kada porudžbine počnu da stoje.
3-D Secure 2 je danas podrazumevan. Kupca autentifikuje njegova banka izdavalac, ne vi. Ponekad se to završi bez ijednog dodatnog koraka, a ponekad kupac mora da potvrdi kupovinu u mobilnoj aplikaciji banke ili kodom koji stigne SMS-om. Prodavnica ne bira koji će se scenario dogoditi i ne sme da pretpostavi da će kupac ostati u istom tabu i istoj sesiji.
Odatle sledi druga odluka: redirekcija ili forma na vašem domenu. Redirekcija vodi kupca na stranicu procesora, smanjuje vaš PCI DSS obim na najlakši upitnik i skida vam s vrata svaki dodir sa podacima o kartici, ali dizajn te stranice nije vaš. Hostovana forma, ili polja za karticu u okviru na vašem domenu, zadržavaju kupca kod vas i daju bolji tok, ali obim usklađenosti raste jer stranica koja prikuplja podatke sada nastaje na vašem sajtu. Ono što ne dolazi u obzir ni u jednom scenariju jeste da broj kartice prođe kroz vaš server ili vašu bazu.
Jedan detalj obara integracije baš u produkciji. Povratak sa strane banke često stiže kao POST zahtev sa drugog domena, a kolačić sesije sa podrazumevanim SameSite pravilom tada ne stiže uz taj zahtev, pa korpa i sesija izgledaju prazno iako je novac naplaćen. Porudžbina se zato prepoznaje po identifikatoru i ključu iz samog zahteva, nikada po sesiji.
Statusi porudžbine: plaćena ne sme da ostane na čekanju
Ovde integracije najčešće tiho pucaju. WooCommerce ima svoje statuse (na čekanju, u obradi, završeno, otkazano, neuspelo, refundirano), procesor ima svoje šifre odgovora, i neko mora da napiše prevod između ta dva rečnika. Pravilo je jednostavno: izvor istine je serverska notifikacija procesora, a ne povratak kupca u browseru. Kupac zatvori tab, izgubi mrežu ili se vrati posle pet minuta. Ako se status menja samo na povratnoj adresi, deo naplaćenih porudžbina ostaće u statusu koji izgleda kao neplaćen, pa će ih neko ručno tražiti po izveštaju procesora.
// Serverska notifikacija je izvor istine, povratak kupca nije.
$order = wc_get_order( $orderId );
if ( ! $order || ! $order->needs_payment() ) {
return; // već obrađeno, otkazano ili duplirano
}
if ( 'approved' === $responseStatus && $order->get_total() == $amount ) {
$order->payment_complete( $transactionId );
} else {
$order->update_status( 'failed', 'Procesor: ' . $responseCode );
}
Tri stvari se lako previde. Obrada notifikacije mora da bude idempotentna, jer procesor ume da je pošalje dva puta. Iznos i valuta iz notifikacije moraju da se uporede sa porudžbinom pre nego što se plaćanje potvrdi. I svaki odgovor procesora treba upisati u belešku porudžbine, da bi reklamacija posle mesec dana imala trag koji niko ne mora da traži po logovima servera.
Proverite i da povratna adresa uopšte može da primi zahtev. Zaštitni zid, pravilo koje blokira POST sa nepoznatih adresa ili plugin za režim održavanja umeju da odbiju poziv procesora bez ijedne poruke o grešci, a prodavnica u tom slučaju izgleda ispravno sve dok neko ne uporedi izveštaje.
Test okruženje daje test kartice, mogućnost da odgovor prinudno bude odobren ili odbijen, i tačan oblik notifikacije. To je dovoljno da se logika napiše, ali nije dovoljno da se u nju veruje. U produkciji se prvi put sreću prava 3-D Secure potvrda na kupčevom telefonu, banka izdavalac koja sporo odgovara, dupli klik na dugme za plaćanje, delimičan povraćaj novca i usaglašavanje dnevnog izveštaja procesora sa izvodom sa računa. Zato posle prelaska na produkcione ključeve uradite jednu stvarnu transakciju sopstvenom karticom i odmah je refundirajte kroz isti kanal, pre nego što bilo kome kažete da naplata radi.
Integracija plaćanja je gotova kada povraćaj novca radi, a ne kada prva naplata prođe.
Pouzeće ne nestaje, radi uporedo
Kartica ne zamenjuje pouzeće na domaćem tržištu. Deo kupaca i dalje bira da plati kuriru, i to nije greška u dizajnu naplate nego navika i pitanje poverenja. Uvođenje kartica menja odnos ta dva načina plaćanja, a ne ukida nijedan od njih.
Posledica su dva različita toka porudžbine u istom sistemu. Kod kartice je novac naplaćen pre slanja, porudžbina automatski prelazi u obradu, a povraćaj ide kroz procesora i ostavlja trag. Kod pouzeća se naplata dešava tek na vratima, pa je porudžbina do tada obaveza a ne prihod, odbijena pošiljka kod isporuke je stvaran trošak, a povraćaj novca je poseban postupak. Statusi, izveštaji i uputstvo za tim moraju to da odražavaju, inače se magacin i knjigovodstvo razilaze već posle prve nedelje.
U prodavnici Cvetam za dostavu cveća kartično plaćanje preko Banca Intese radi uporedo sa pouzećem, u produkciji od 2022. godine. Na naplati nijedan način nije izuzetak: oba stoje na istom mestu, opisana istim jezikom i sa istim brojem koraka. Kupac koji naručuje buket u četiri popodne ne bi trebalo da bira između brzine i navike.
Okvir odlučivanja za vlasnike prodavnica koji biraju između plugina, temeljnijeg podešavanja i nekoliko linija custom koda na naplati, uz iskren podrazumevani izbor za većinu.
Beleška s terena / Priprema za naplatu
Kartično plaćanje u domaćoj prodavnici ne uključuje se pluginom. Pre nego što banka ili procesor odobri prodavnicu, morate imati registrovanu firmu sa poslovnim računom i potpisan ugovor o prihvatanju platnih kartica, a sajt već tada mora da sadrži uslove prodaje, politiku privatnosti, postupak reklamacije i povraćaja novca, uslove i rokove dostave, cene u dinarima sa jasnim PDV statusom i punu identifikaciju firme.
Dva posla ovde teku paralelno i ne završavaju se u isto vreme. Tehnička integracija WooCommerce prodavnice sa sistemom za kartičnu naplatu je merljiv zadatak sa jasnim krajem. Odobrenje trgovca nije: ono zavisi od toga šta neko sa druge strane vidi kada otvori vaš sajt bez ijedne reči objašnjenja. Ovo je spisak onoga što mora da postoji pre nego što predate prijavu, i onoga što se u samoj integraciji najčešće previdi.
Šta mora da postoji pre nego što sajt uopšte pogledaju
Prihvatanje kartica je finansijska usluga i ugovara se sa institucijom, ne sa softverom. Osnovni preduslovi su isti bez obzira na to kome se obraćate:
Tu se donosi i prva odluka sa tehničkim posledicama. Ugovor direktno sa bankom, na primer sa Banca Intesom za web shop, znači jedan ugovorni odnos, jednu integraciju i pregovor o proviziji sa jednom stranom. Platni procesor kao što je CorvusPay stoji između prodavnice i banke, a zauzvrat nudi jedan tehnički priključak za više kartičnih brendova, održavan WooCommerce modul i sopstvenu podršku onda kada transakcija zapne.
Nijedan izbor nije unapred jeftiniji. Uporedite proviziju po transakciji, fiksne mesečne troškove, rok za isplatu na račun i količinu posla koja ostaje na vama kada nešto krene naopako. Pitajte i šta je tačno obuhvaćeno: DinaCard, Visa i Mastercard, plaćanje na rate, IPS QR kod za instant plaćanje, kao i to da li se delimičan povraćaj i povraćaj posle obračuna rade kroz isti kanal ili ručno. Poslednje pitanje deluje sitno sve dok vam ne zatreba.
Jedna napomena o planiranju. Datum lansiranja ne vezujte za datum odobrenja koji ne kontrolišete. Prodavnica treba da može da radi sa pouzećem i uplatnicom od prvog dana, a kartično plaćanje da se uključi kada odobrenje stigne. Tako lansiranje ne zavisi od tuđeg reda čekanja.
Šta se proverava na sajtu
Kada prijava stigne, neko otvara sajt kao običan posetilac i traži konkretne stvari. Ne čita marketinški tekst i neće vas zvati da pita. Ako u nekoliko minuta ne nađe ovo, prijava se vraća:
Poslovno ime, sedište, matični broj i PIB na sajtu nisu zahtev banke nego zakonska obaveza privrednog društva, pa tu nema pregovora. Dva roka se najčešće pogrešno prepišu: pravo potrošača da odustane od ugovora zaključenog na daljinu u roku od četrnaest dana i rok u kome ste dužni da odgovorite na izjavljenu reklamaciju. Otvorite aktuelni tekst Zakona o zaštiti potrošača i upišite tačne rokove umesto da preuzmete formulaciju sa tuđeg sajta. Prepisani uslovi prodaje u kojima je ostalo ime druge firme najbrži su poznati način da prijava bude vraćena.
Isto važi i za mesto na kome te stranice stoje. Treba da budu dostupne iz futera na svakoj stranici, a ne samo u poslednjem koraku naplate, a polje za prihvatanje uslova na naplati mora da vodi do njih linkom koji radi.
Prodavnicu ne odobrava plugin. Odobrava je ono što na sajtu piše kada ga neko otvori bez najave.
Zbog čega se prijave najčešće vraćaju
Razlozi se ponavljaju i skoro nijedan nije tehnički težak:
Sve je to jeftino dok se prodavnica gradi, a skupo kada se prijava vrati, jer se tada čeka novi krug provere. Kada radimo razvoj WooCommerce prodavnica, ove stavke ulaze u plan zajedno sa katalogom i naplatom, a ne posle lansiranja.
HTTPS, 3-D Secure i izbor forme za plaćanje
HTTPS ide na ceo sajt, ne samo na korpu. Mešani sadržaj je dovoljan da provera padne: jedna stara slika ili skripta učitana preko nezaštićene veze. Sertifikat mora da ima automatsku obnovu i nadzor, jer istekli sertifikat ne obara samo sajt nego i povratni poziv procesora, a to se primeti tek kada porudžbine počnu da stoje.
3-D Secure 2 je danas podrazumevan. Kupca autentifikuje njegova banka izdavalac, ne vi. Ponekad se to završi bez ijednog dodatnog koraka, a ponekad kupac mora da potvrdi kupovinu u mobilnoj aplikaciji banke ili kodom koji stigne SMS-om. Prodavnica ne bira koji će se scenario dogoditi i ne sme da pretpostavi da će kupac ostati u istom tabu i istoj sesiji.
Odatle sledi druga odluka: redirekcija ili forma na vašem domenu. Redirekcija vodi kupca na stranicu procesora, smanjuje vaš PCI DSS obim na najlakši upitnik i skida vam s vrata svaki dodir sa podacima o kartici, ali dizajn te stranice nije vaš. Hostovana forma, ili polja za karticu u okviru na vašem domenu, zadržavaju kupca kod vas i daju bolji tok, ali obim usklađenosti raste jer stranica koja prikuplja podatke sada nastaje na vašem sajtu. Ono što ne dolazi u obzir ni u jednom scenariju jeste da broj kartice prođe kroz vaš server ili vašu bazu.
Jedan detalj obara integracije baš u produkciji. Povratak sa strane banke često stiže kao POST zahtev sa drugog domena, a kolačić sesije sa podrazumevanim SameSite pravilom tada ne stiže uz taj zahtev, pa korpa i sesija izgledaju prazno iako je novac naplaćen. Porudžbina se zato prepoznaje po identifikatoru i ključu iz samog zahteva, nikada po sesiji.
Statusi porudžbine: plaćena ne sme da ostane na čekanju
Ovde integracije najčešće tiho pucaju. WooCommerce ima svoje statuse (na čekanju, u obradi, završeno, otkazano, neuspelo, refundirano), procesor ima svoje šifre odgovora, i neko mora da napiše prevod između ta dva rečnika. Pravilo je jednostavno: izvor istine je serverska notifikacija procesora, a ne povratak kupca u browseru. Kupac zatvori tab, izgubi mrežu ili se vrati posle pet minuta. Ako se status menja samo na povratnoj adresi, deo naplaćenih porudžbina ostaće u statusu koji izgleda kao neplaćen, pa će ih neko ručno tražiti po izveštaju procesora.
Tri stvari se lako previde. Obrada notifikacije mora da bude idempotentna, jer procesor ume da je pošalje dva puta. Iznos i valuta iz notifikacije moraju da se uporede sa porudžbinom pre nego što se plaćanje potvrdi. I svaki odgovor procesora treba upisati u belešku porudžbine, da bi reklamacija posle mesec dana imala trag koji niko ne mora da traži po logovima servera.
Proverite i da povratna adresa uopšte može da primi zahtev. Zaštitni zid, pravilo koje blokira POST sa nepoznatih adresa ili plugin za režim održavanja umeju da odbiju poziv procesora bez ijedne poruke o grešci, a prodavnica u tom slučaju izgleda ispravno sve dok neko ne uporedi izveštaje.
Test okruženje daje test kartice, mogućnost da odgovor prinudno bude odobren ili odbijen, i tačan oblik notifikacije. To je dovoljno da se logika napiše, ali nije dovoljno da se u nju veruje. U produkciji se prvi put sreću prava 3-D Secure potvrda na kupčevom telefonu, banka izdavalac koja sporo odgovara, dupli klik na dugme za plaćanje, delimičan povraćaj novca i usaglašavanje dnevnog izveštaja procesora sa izvodom sa računa. Zato posle prelaska na produkcione ključeve uradite jednu stvarnu transakciju sopstvenom karticom i odmah je refundirajte kroz isti kanal, pre nego što bilo kome kažete da naplata radi.
Pouzeće ne nestaje, radi uporedo
Kartica ne zamenjuje pouzeće na domaćem tržištu. Deo kupaca i dalje bira da plati kuriru, i to nije greška u dizajnu naplate nego navika i pitanje poverenja. Uvođenje kartica menja odnos ta dva načina plaćanja, a ne ukida nijedan od njih.
Posledica su dva različita toka porudžbine u istom sistemu. Kod kartice je novac naplaćen pre slanja, porudžbina automatski prelazi u obradu, a povraćaj ide kroz procesora i ostavlja trag. Kod pouzeća se naplata dešava tek na vratima, pa je porudžbina do tada obaveza a ne prihod, odbijena pošiljka kod isporuke je stvaran trošak, a povraćaj novca je poseban postupak. Statusi, izveštaji i uputstvo za tim moraju to da odražavaju, inače se magacin i knjigovodstvo razilaze već posle prve nedelje.
U prodavnici Cvetam za dostavu cveća kartično plaćanje preko Banca Intese radi uporedo sa pouzećem, u produkciji od 2022. godine. Na naplati nijedan način nije izuzetak: oba stoje na istom mestu, opisana istim jezikom i sa istim brojem koraka. Kupac koji naručuje buket u četiri popodne ne bi trebalo da bira između brzine i navike.