Incassare online: cosa succede tra il tocco del cliente e il denaro sul tuo conto

Un cliente tocca Paga sulla tua pagina d’ordine e vede una spunta verde. Dietro quella spunta quattro o cinque cose dovevano andare a buon fine, e una di esse decide se il denaro è davvero tuo o se hai soltanto il permesso di prenderlo. Quasi tutte le discussioni con un fornitore di pagamenti nascono perché un ristorante ha creduto che fossero la stessa cosa.

Il gateway prende prima il consenso, poi il denaro

Ogni circuito di carte divide un pagamento in due momenti:

1. Autorizzazione — la banca emittente conferma che il denaro esiste e lo accantona.
2. Cattura — l’esercente dice «prendilo ora», e il denaro si muove.

Alcuni gateway uniscono i due passaggi per te. Altri no, e ti consegnano un ordine approvato, coperto e del tutto non incassato finché non lo richiedi. PayPal funziona nel secondo modo: un cliente che approva sulla pagina PayPal ha acconsentito a pagarti, e nulla ha lasciato il suo conto finché non avviene la cattura. Stripe Checkout, configurato nel modo consueto, fa entrambe le cose per te.

Questo conta per una ragione molto pratica. Se il tuo sistema segna un ordine come pagato appena il cliente viene riportato indietro, prima o poi servirai cibo a fronte di autorizzazioni mai catturate — e lo scoprirai a fine mese, dalla banca, non dalla cassa.

La regola è dunque semplice e va imposta a qualunque fornitore: una vendita è pagata quando il denaro si è mosso, non quando il cliente è tornato.

Quattro binari, e a cosa serve onestamente ciascuno

Fawry è l’eccezione utile: non accetta affatto carte. Emette un codice, il cliente lo paga in un chiosco o in farmacia, e la conferma ti arriva dopo. In un mercato dove gran parte delle persone non possiede una carta, non è un ripiego — è la strada principale.

Contanti e POS sul bancone restano altri due binari, senza alcun gateway. Vengono registrati in cassa e riconciliati col cassetto a fine turno.

È la valuta a scegliere il gateway, non la preferenza

È la parte che sorprende, quindi diciamola chiaramente: un fornitore regola in un elenco fisso di valute, e se la tua non c’è nessuna configurazione risolve.

Paymob e Fawry regolano in sterline egiziane. Sono la risposta giusta al Cairo e irrilevanti a Madrid. Stripe arriva quasi ovunque. PayPal raggiunge gran parte del mondo ma non accetta affatto la sterlina egiziana, né il riyal né il dirham — quindi un ristorante egiziano che prezza in EGP non può mettere PayPal dietro la cassa, per quanto lo desideri.

Un buon sistema te lo dice in fase di configurazione, non al primo ordine fallito. A un ristorante che prezza in euro non andrebbero proprio proposti i binari egiziani; a uno che prezza in sterline non andrebbe consentito in sordina di configurare un fornitore che rifiuterà la prima transazione.

Se operi in più paesi, prezza ogni sede nella sua valuta e lascia che ciascuna porti il proprio fornitore. Il che ci porta all’errore successivo.

Le chiavi di una filiale non sono quelle della sede

Le credenziali di un fornitore appartengono a un conto esercente, e un conto esercente regola su un conto bancario, in una valuta.

Perciò, quando un gruppo ha una filiale in un altro paese, quella filiale non può ereditare le credenziali della sede — non per scelta di policy, ma per aritmetica. Quelle chiavi manderebbero i suoi clienti a un processore incapace di incassare il suo denaro.

L’assetto sensato: una filiale che prezza nella stessa valuta eredita le impostazioni e non richiede configurazione separata. Una che prezza in un’altra mantiene credenziali, indirizzo di richiamo e regolamento propri. Chiedi a qualunque fornitore come lo gestisce prima di aprire il secondo paese, non dopo.

Il webhook è la conferma

Quando un cliente finisce di pagare accadono due cose indipendenti:

• il suo browser viene reindirizzato alla tua pagina, e
• il fornitore invia al tuo server una notifica firmata con quanto è successo.

Solo la seconda è affidabile. Un reindirizzamento può essere interrotto da una connessione caduta, una scheda chiusa, una batteria scarica o un cliente che ha semplicemente premuto indietro — e in tutti questi casi il denaro può benissimo essersi mosso. Peggio: un reindirizzamento è un URL, e un URL si può digitare.

La notifica firmata — il webhook — è il fornitore che dice al tuo server, da server a server e con una firma che verifichi, che il pagamento è andato a buon fine. È questo l’evento che deve segnare l’ordine come pagato, liberare la comanda in cucina e comparire nell’incasso del giorno.

Due conseguenze pratiche:

• Il tuo indirizzo di richiamo deve essere raggiungibile da Internet. Un webhook è una richiesta in entrata. Non funziona verso un portatile sul WiFi di un bar, ed è per questo che un test superato sulla macchina di uno sviluppatore può fallire in produzione.
• Il fornitore invierà lo stesso evento due volte. Le reti perdono conferme e ogni fornitore serio riprova. Tenerne conto è ciò che evita che un ordine venga registrato come due pagamenti.

I rimborsi tornano indietro sullo stesso binario

Un rimborso non è un bonifico di ritorno — è l’istruzione al binario originale di annullare un addebito preciso. Significa che puoi rimborsare solo tramite il fornitore che ha incassato, e in genere ti serve il riferimento della cattura, non quello dell’ordine.

Ne discendono due cose. Primo, rimborso in contanti e rimborso da gateway sono operazioni diverse e devono apparire diverse nei report, perché uno svuota un cassetto e l’altro corregge un regolamento bancario. Secondo, un rimborso parziale va legato all’addebito che annulla, altrimenti la riconciliazione non chiuderà mai.

Cosa fa davvero perdere l’ordine

In pratica il pagamento online fallisce per ragioni noiose, non esotiche:

• L’importo è giusto e la valuta no. Il fornitore rifiuta e il cliente vede un errore inspiegabile.
• L’URL di ritorno è un link applicativo, non un indirizzo web. Alcuni fornitori accettano solo normali indirizzi https e rifiutano il resto — l’ordine non viene nemmeno creato.
• Nessuno ha configurato il webhook. I pagamenti riescono, i clienti vengono addebitati, e nel ristorante nessuno lo sa. È il guasto più comune, ed è silenzioso.
• Le chiavi di test non sono mai state sostituite. Tutto funziona benissimo e non arriva un euro.

Nessuno di questi è un problema ingegnoso. Sono problemi da lista di controllo, ed è proprio per questo che dovrebbero stare su una lista — e per questo un test di connessione che chiami davvero il fornitore, invece di limitarsi a salvare le chiavi, si guadagna il suo posto nella schermata delle impostazioni.

In breve

Offri i binari che i tuoi clienti usano davvero, prezza ogni sede nella valuta in cui viene regolata, lascia che sia il webhook — non il reindirizzamento — a decidere quando un ordine è pagato, e collauda con chiavi reali prima di dire a qualcuno che la pagina è aperta. Il resto è configurazione.