Multi-currency payments: valute, konverzija i settlement

Multi-currency payments omogućavaju da kupac vidi i plati iznos u valuti koja mu je razumljiva, dok se novac trgovcu isplaćuje u jednoj ili više settlement valuta. To nije ista stvar kao dodavanje simbola valute pored cene: checkout mora da zna u kojoj valuti prikazuje cenu, u kojoj šalje payment request, kako se računa kurs i na koji račun stiže novac.

Najvažnija odluka je zato razdvajanje četiri pojma: valuta prikaza, valuta transakcije, valuta settlementa i valuta refundiranja. Kada se te uloge pomešaju, nastaju razlike između cene na sajtu, iznosa koji kupac vidi na izvodu i iznosa koji trgovac dobija na račun. U planiranju tehničkog rešenja za međunarodnu prodaju, multi-currency payments treba posmatrati kao deo šire integracije platnih kartica, a ne kao izolovanu funkciju teme ili checkouta.

Šta zapravo znači plaćanje u više valuta

Jedan međunarodni checkout može da koristi više različitih valuta u različitim fazama:

• Valuta prikaza je valuta koju kupac vidi na stranici proizvoda, u korpi i tokom checkouta.
• Valuta naplate je valuta u kojoj payment provider autorizuje i knjiži transakciju.
• Valuta settlementa je valuta u kojoj provider isplaćuje sredstva trgovcu.
• Valuta knjigovodstva je valuta u kojoj se prihod, naknada i porez evidentiraju u internim sistemima.

Ove valute mogu biti iste, ali ne moraju. Na primer, kupac iz Nemačke može videti cenu u evrima i biti naplaćen u evrima, dok trgovac settlement prima u drugoj podržanoj valuti. U drugom modelu, sajt prikazuje lokalnu valutu, ali se transakcija na payment provideru obrađuje u osnovnoj valuti prodavca. To kupcu može biti manje jasno, a konačan iznos može zavisiti od konverzije koju obavlja banka izdavalac kartice.

Valuta prikaza nije automatski valuta naplate

Pre implementacije treba odlučiti da li je lokalna cena samo informativni prikaz ili predstavlja iznos koji će zaista biti poslat payment provideru. To su dva legitimna modela, ali imaju različita pravila i rizike.

Model 1: lokalni prikaz, naplata u osnovnoj valuti

U ovom modelu sajt može prikazati približnu cenu u RSD, EUR ili drugoj valuti, ali checkout jasno navodi da će naplata biti izvršena u osnovnoj valuti trgovca. Kurs može zavisiti od banke ili kartične mreže kupca. Prednost je jednostavnija cenovna logika i manje varijacija u katalogu. Nedostatak je slabija predvidivost konačnog iznosa za kupca i veći prostor za nesporazum.

Model 2: lokalni prikaz i lokalna naplata

Ovde se iznos u izabranoj valuti šalje u payment requestu i ta valuta postaje valuta transakcije. Kupac dobija jasniju informaciju o iznosu koji plaća, ali sistem mora da podrži valutu, minimalni iznos, broj decimalnih mesta, refund i eventualni settlement za tu valutu.

Praktično pravilo je da se na checkoutu eksplicitno prikaže valuta naplate, a ne samo valuta koja je ranije izabrana u meniju. Promena valute tokom checkouta treba da osveži cenu, porez, dostavu i konačan iznos. Nije dovoljno promeniti samo format prikaza.

Kako funkcioniše konverzija

Konverzija može nastati u više tačaka:

1. web-shop konvertuje osnovnu cenu u valutu prikaza;
2. payment provider konvertuje ili obrađuje iznos u valuti transakcije;
3. kartična mreža ili banka kupca primenjuje sopstveni kurs ako se valuta transakcije razlikuje od valute kartice;
4. provider konvertuje sredstva u settlement valutu;
5. banka trgovca može primeniti dodatnu konverziju prilikom prijema sredstava.

Zato izraz „kurs“ nije dovoljan. Potrebno je znati ko postavlja kurs, u kom trenutku i prema kom iznosu. Referentni kursevi centralnih banaka mogu biti korisni za analizu i internu kontrolu, ali ne moraju biti jednaki kursu koji se primenjuje u konkretnoj kartičnoj transakciji.

Ako se cene preračunavaju u web-shopu, sistem treba da čuva izvorni iznos, korišćenu valutu i pravilo po kojem je izveden lokalni iznos. Za komercijalne proizvode često je praktičnije imati unapred definisane cenovnike po valutama nego preračunavati svaku cenu u realnom vremenu. Kod promenljivih kurseva važno je definisati koliko često se cene osvežavaju i da li se iznos zaključava kada proizvod uđe u korpu.

Settlement: gde završava novac

Settlement je proces isplate obrađenih sredstava trgovcu nakon transakcije i eventualnog perioda obrade. On se razlikuje od autorizacije: autorizacija potvrđuje da je plaćanje prihvaćeno ili rezervisano, dok settlement određuje kada i u kojoj valuti sredstva postaju dostupna na nalogu trgovca.

Kod multi-currency payments treba proveriti:

• koje valute provider podržava za naplatu;
• koje valute podržava za settlement;
• da li se sredstva po valutama vode odvojeno ili se automatski konvertuju;
• koje naknade i kurs važe za konverziju;
• na koji bankovni račun ili payout kanal se sredstva isplaćuju;
• kako se u izvodu označavaju bruto iznos, naknada, konverzija i neto settlement.

Podrška za valutu naplate ne znači nužno i podršku za držanje ili isplatu te valute. Ove informacije treba proveriti u aktuelnoj dokumentaciji konkretnog payment providera, jer se dostupne valute i pravila razlikuju prema zemlji trgovca, tipu naloga i ugovorenom modelu.

Za finansijsko usklađivanje nije dovoljno sačuvati samo iznos porudžbine iz web-shopa. Dobro modelovan sistem čuva najmanje valutu i iznos porudžbine, valutu i iznos transakcije, identifikator paymenta, naknadu, settlement iznos, kurs ako postoji i status isplate. Tako se refund, reklamacija i knjiženje mogu povezati sa konkretnim događajem.

Decimalna mesta, zaokruživanje i prikaz cena

Valute nemaju uvek isti način zapisa. Neke se u korisničkom interfejsu prikazuju sa dve decimale, dok druge imaju drugačija pravila najmanje obračunske jedinice. Zbog toga iznos ne treba čuvati kao formatirani tekst, niti se poslovna logika sme oslanjati na simbol valute.

Pre izrade treba definisati:

• internu jedinicu za čuvanje novca, na primer najmanju podržanu obračunsku jedinicu;
• pravilo zaokruživanja po stavci, porezu, dostavi i ukupnom iznosu;
• kako se zaokruživanje prikazuje kupcu;
• da li se popust računa pre ili posle konverzije;
• da li se prag besplatne dostave i drugi poslovni pragovi računaju u osnovnoj ili lokalnoj valuti.

Posebno treba testirati kombinacije proizvoda, popusta i poreza. Razlika od najmanje obračunske jedinice može se pojaviti ako se svaka stavka zaokružuje posebno, a zatim sabira, umesto da se zaokruži tek konačan iznos. Pravilo mora biti isto na katalogu, korpi, payment requestu, računu i administrativnom izveštaju.

Refund, chargeback i otkazivanje u više valuta

Refund ne treba tretirati kao novu prodaju. On treba da bude vezan za originalnu transakciju, originalni payment ID i iznos koji je dozvoljeno vratiti. Ako je transakcija izvršena u lokalnoj valuti, povraćaj se obično modeluje u toj valuti, ali konačan iznos koji korisnik vidi na kartičnom računu može zavisiti od kursa i pravila banke izdavaoca.

Poslovna pravila moraju jasno odgovoriti da li su mogući puni i delimični refund, da li se refund radi po stavci ili samo po celoj porudžbini i kako se tretiraju dostava, kupon i porez. Za detaljniji model statusa i veza između originalne naplate i povraćaja korisno je pogledati tekst Refund i partial refund: kako modelovati povraćaj sredstava.

Chargeback je odvojen proces: banka ili kartična mreža može pokrenuti spor, a sredstva i naknade mogu biti evidentirani drugačije od dobrovoljnog refundiranja. Zato izveštaji treba da razlikuju refund, reversal, chargeback i neuspešnu naplatu, čak i kada korisnički interfejs za svaki od njih prikazuje sličnu poruku.

Kako multi-currency payments utiče na checkout

Izbor načina plaćanja može promeniti količinu informacija koju checkout mora da prikaže. Kod hosted checkouta provider često preuzima deo logike za prikaz valuta, validaciju iznosa i status transakcije. Kod embedded forme ili potpuno prilagođenog checkouta trgovac ima veću kontrolu, ali i veću odgovornost za sinhronizaciju cene, valute, greške i statusa.

Razlike između ova dva pristupa, uključujući uticaj na kontrolu interfejsa i tehničko održavanje, opisane su u vodiču Hosted checkout ili embedded payment forma: prednosti i kompromisi.

Valutu ne treba menjati nakon što je payment request već kreiran. Ako kupac promeni valutu u poslednjem koraku, prethodni payment intent ili checkout session treba bezbedno osvežiti ili zameniti, uz proveru da se stari iznos ne može slučajno naplatiti. Webhook događaji treba da budu izvor istine za konačan status transakcije, a ne samo redirect stranica u browseru.

Test plan pre puštanja u rad

Testiranje treba da obuhvati ceo tok, od izbora zemlje do settlement izveštaja:

1. izaberite svaku podržanu valutu i proverite katalog, korpu, porez i dostavu;
2. uporedite iznos prikazan kupcu sa iznosom poslatim payment provideru;
3. testirajte promenu valute nakon dodavanja proizvoda u korpu;
4. proverite decimalna mesta, minimalni iznos i zaokruživanje;
5. simulirajte uspešnu, odbijenu i prekinutu transakciju;
6. testirajte puni i delimični refund;
7. uporedite payment događaje sa narudžbinom i settlement izveštajem;
8. proverite šta se dešava kada valuta nije dostupna za izabranu zemlju ili način plaćanja.

Posebno proverite mobilni prikaz. Simbol valute, decimalni zapis i pozicija iznosa moraju biti dovoljno jasni da korisnik ne zameni lokalni informativni iznos sa konačnom naplatom. Ako se koriste digitalni novčanici, njihovo ponašanje i podržane valute testiraju se kao zaseban scenario; dodatni kontekst je u vodiču Apple Pay i Google Pay integracija: gde se uklapaju u checkout.

Kako izabrati model za međunarodnu prodaju

Ne postoji univerzalno najbolji model. Odluka zavisi od tržišta, poslovnog sistema i očekivanja kupaca.

Bez obzira na model, specifikacija treba unapred da odgovori na četiri pitanja: šta kupac vidi, šta se šalje payment provideru, šta se knjiži u poslovnom sistemu i šta se isplaćuje trgovcu. Tek kada su ti odgovori usklađeni, ima smisla birati checkout tehnologiju i način implementacije.

Ako se međunarodna prodaja tek uvodi, ova odluka je povezana i sa arhitekturom kataloga, lokalizacijom, porezima i administracijom porudžbina. Zato je korisno da se multi-currency zahtev definiše zajedno sa ostatkom projekta izrade sajta, umesto da se naknadno dodaje samo promena simbola valute.

Sledeći korak

Pre razgovora sa payment providerom pripremite kratku matricu: zemlje kupaca, valute prikaza, valute naplate, očekivani settlement, pravila refundiranja i način knjiženja. Na osnovu te matrice može se proveriti da li izabrani provider zaista podržava potreban tok i gde se pojavljuje konverzija. Zatim se tehnička specifikacija može povezati sa planom integracije platnih kartica, uključujući webhook događaje, izveštaje i testiranje.