Încasarea online: ce se întâmplă între atingerea clientului și banii ajunși la tine

Un client apasă Plătește pe pagina ta de comenzi și vede o bifă verde. În spatele acelei bife, patru sau cinci lucruri trebuiau să iasă bine, iar unul dintre ele decide dacă banii sunt într-adevăr ai tăi sau ai doar permisiunea de a-i lua. Majoritatea disputelor cu un procesator de plăți încep pentru că un restaurant a presupus că e același lucru.

Gateway-ul ia întâi consimțământul, apoi banii

Orice rețea de carduri împarte o plată în două momente:

1. Autorizarea — banca emitentă confirmă că banii există și îi rezervă.
2. Captura — comerciantul spune „ia-i acum”, iar banii se mișcă.

Unele gateway-uri contopesc cei doi pași pentru tine. Altele nu, și îți lasă o comandă aprobată, acoperită și complet neîncasată până când o ceri. PayPal funcționează în al doilea fel: un client care aprobă pe pagina PayPal a consimțit să te plătească, iar până la captură nimic nu i-a părăsit contul. Stripe Checkout, configurat obișnuit, face ambele lucruri pentru tine.

Asta contează dintr-un motiv foarte practic. Dacă sistemul tău marchează o comandă plătită din clipa în care clientul este redirecționat înapoi, mai devreme sau mai târziu vei servi mâncare pe baza unor aprobări niciodată capturate — și vei afla la sfârșit de lună, de la bancă, nu de la casa de marcat.

Regula este, așadar, simplă și merită impusă oricărui furnizor: o vânzare este plătită când banii s-au mișcat, nu când clientul s-a întors.

Patru căi, și la ce folosește sincer fiecare

Fawry este excepția utilă: nu acceptă deloc carduri. Emite un cod, clientul îl plătește la un chioșc sau la o farmacie, iar confirmarea îți ajunge după aceea. Pe o piață unde o bună parte dintre oameni nu au card, asta nu e o soluție de rezervă — e drumul principal.

Numerarul și terminalul de pe tejghea rămân alte două căi, fără niciun gateway. Se înregistrează la casă și se reconciliază cu sertarul la închiderea turei.

Moneda ta alege gateway-ul, nu preferința ta

Aceasta este partea care surprinde, așa că să o spunem clar: un furnizor decontează într-o listă fixă de monede, iar dacă a ta nu e pe listă, nicio configurare nu ajută.

Paymob și Fawry decontează în lire egiptene. Sunt răspunsul corect în Cairo și irelevante în Madrid. Stripe ajunge aproape peste tot. PayPal ajunge într-o bună parte a lumii, dar nu acceptă deloc lira egipteană, nici rialul, nici dirhamul — așa că un restaurant egiptean care își stabilește prețurile în EGP nu poate pune PayPal în spatele plății, oricât și-ar dori.

Un sistem bun îți spune asta la configurare, nu la prima comandă eșuată. Unui restaurant care facturează în euro nu ar trebui să i se ofere deloc căile egiptene; unuia care facturează în lire nu ar trebui să i se permită discret să configureze un furnizor care îi va refuza prima tranzacție.

Dacă operezi în mai multe țări, stabilește prețurile fiecărei locații în moneda ei și lasă fiecare să își poarte furnizorul. Ceea ce ne duce la următoarea greșeală.

Cheile unei sucursale nu sunt cheile sediului

Datele de acces ale unui furnizor aparțin unui cont de comerciant, iar un cont de comerciant decontează într-un cont bancar, într-o monedă.

Prin urmare, când un grup are o sucursală în altă țară, aceasta nu poate moșteni datele de acces ale sediului — nu ca decizie de politică internă, ci ca aritmetică. Cheile acelea și-ar trimite clienții către un procesator incapabil să îi încaseze banii.

Aranjamentul sănătos: o sucursală care facturează în aceeași monedă moștenește setările și nu are nevoie de configurare separată. Una care facturează în alta își păstrează propriile date, propria adresă de retur și propria decontare. Întreabă orice furnizor cum rezolvă asta înainte de a deschide a doua țară, nu după.

Webhook-ul este confirmarea

Când un client termină de plătit se întâmplă două lucruri independente:

• browserul său este redirecționat către pagina ta, și
• furnizorul trimite serverului tău o notificare semnată cu ce s-a întâmplat.

Doar a doua este demnă de încredere. O redirecționare poate fi întreruptă de o conexiune pierdută, o filă închisă, o baterie descărcată sau un client care pur și simplu a apăsat înapoi — iar în toate aceste cazuri banii s-ar putea foarte bine să se fi mișcat. Mai rău: o redirecționare este un URL, iar un URL poate fi tastat.

Notificarea semnată — webhook-ul — este furnizorul care îi spune serverului tău, de la server la server și cu o semnătură pe care o verifici, că plata s-a decontat. Acesta este evenimentul care trebuie să marcheze comanda ca plătită, să elibereze bonul către bucătărie și să apară în încasările zilei.

Două consecințe practice:

• Adresa ta de retur trebuie să fie accesibilă din internet. Un webhook este o cerere de intrare. Nu funcționează către un laptop pe WiFi-ul unei cafenele, și de aceea un test care trece pe mașina unui programator poate eșua în producție.
• Furnizorul va trimite același eveniment de două ori. Rețelele pierd confirmări și orice furnizor serios reîncearcă. Atenția la acest lucru este ceea ce împiedică o comandă să fie înregistrată ca două plăți.

Rambursările se întorc pe aceeași cale

O rambursare nu este un transfer înapoi — este instrucțiunea dată căii originale de a anula o încasare anume. Asta înseamnă că poți rambursa doar prin furnizorul care a încasat și, de regulă, ai nevoie de referința capturii, nu a comenzii.

De aici decurg două lucruri. Întâi, o rambursare în numerar și una prin gateway sunt operațiuni diferite și trebuie să arate diferit în rapoarte, pentru că una golește un sertar, iar cealaltă ajustează o decontare bancară. Apoi, o rambursare parțială trebuie legată de încasarea pe care o anulează, altfel reconcilierea nu se va închide niciodată.

Ce pierde cu adevărat comanda

În practică, plata online eșuează din motive plictisitoare, nu exotice:

• Suma e corectă, moneda nu. Furnizorul refuză, iar clientul vede o eroare neexplicată.
• URL-ul de retur este un link de aplicație, nu o adresă web. Unii furnizori acceptă doar adrese https obișnuite și le resping pe celelalte din start — comanda nici măcar nu este creată.
• Nimeni nu a configurat webhook-ul. Plățile reușesc, clienții sunt debitați, și nimic din restaurant nu știe. Este cea mai frecventă defecțiune, și este tăcută.
• Cheile de test nu au fost niciodată schimbate cu cele reale. Totul funcționează impecabil și nu ajunge niciun ban.

Niciuna dintre acestea nu este o problemă ingenioasă. Sunt probleme de listă de verificare, și tocmai de aceea ar trebui să stea pe una — și de aceea un test de conexiune care chiar apelează furnizorul, în loc să se mulțumească să îți salveze cheile, își merită locul în ecranul de setări.

Pe scurt

Oferă căile pe care clienții tăi le folosesc cu adevărat, stabilește prețurile fiecărei locații în moneda în care este decontată, lasă webhook-ul — nu redirecționarea — să decidă când o comandă este plătită, și testează cu chei reale înainte de a spune cuiva că pagina e deschisă. Restul este configurare.