Voucher in contanti e reti di rivenditore

1) Cosa è e quando applicare

I voucher in contanti e le reti eCash permettono di accettare il pagamento senza carte di credito o BAN. L'utente acquista un voucher prepagato (PIN) o riceve un codice a barre/QR (pay-at-store) e paga l'ordine nel punto off-line del partner (chiosco, supermercato, ASS, ufficio postale) o presso la banca/ATM. I soldi vengono inviati alla Merchant tramite PSP/provider attraverso i binari bancari; Charjback no, i rischi di frode sono minimi.

• Prodotti digitali/giochi, contenuti, abbonamenti a basso/medio assegno.
• Regioni ad alta quota di contanti o a bassa densità di carte.
• Un pubblico che preferisce la privacy o il pagamento anticipato.

2) Tipologia di utensili eCash

1. Voucher PIN (codici prepagati):

Esempi: Paysafecard, Neosurf, Flexepin.
UX: immissione di un PIN a 16/10 cifre sul modulo host o pagamento dal portafoglio (myPaysafe/myNeosurf).
Caratteristiche: prelievi parziali, combinazione di PIN multipli, il residuo viene mantenuto.

2. Codice a barre/QR «Paga in negozio» (cash payment barcode):

Esempi: paysafecash, reti locali (OXXO Pay - MX, RapiPago/PagoFácil - AR, Efecty/Baloto - CO, PayPoint/Payzone - UK, ePay/Paylink - EU, ecc.).
Il Merchant genera barcode/QR, il cliente paga in contanti sulla cassa del fornitore di invia una conferma.
Caratteristiche: l'assegno è valido per il tempo limitato (expiry) e l'importo è fisso.

3. Reference/Slip per ATM/online banking (fattura-accessori):

Esempi: References multibanco - PT, Konbini - JP.
UX: viene visualizzato codice/addebito + importo, pagamento in ATM/banca online/negozio partner.
Caratteristiche: minimo frodo, controllo rigoroso.

3) Membri dell'ecosistema

Provider/diagramma (eCash/voucher): rilascia PIN/Barcode, gestisce i cataloghi del rivenditore, KYC/AML, antifrode, fornisce API/widget.
PSP/Equyer: connette merchant, biglietteria host/SDK, states, hook web, registri e calcoli.
Ritail/biglietteria: ricezione contanti/lettura codice a barre, sincronizzazione con il provider.
Banca/clearing: calcolo e versamento del Merchant.
Merchant: avvia il pagamento/fattura, elabora gli stati, i rimborsi e la recon.

4) Flussi di pagamento

4. 1 voucher PIN (Hosted/Redirect)

1. Checkout seleziona un (ad esempio Paysafecard/Neosurf).
2. Redirect/Hosted modulo provider PIN/accesso al portafoglio conferma (SCA/comportamento).
3. Ritorno al merchant: 'success/pending/failed/canceled/expired'.
4. Il credito effettivo è relativo ai registri giornalieri (T + 1/T + 2).

4. 2 Codice a barre/QR «pagare al negozio»

1. Merchant crea fattura: importo + barcode/QR + expiry.
2. Il cliente va al punto vendita e paga in contanti la cassa → conferma l'operazione al provider.
3. Il provider invia al Merchant un successo online, quindi un prestito nei registri (T + 0/T + 1).

4. 3 Reference/Slip (ATM/online-banking/conbini)

1. Generazione dell'arbitro (entity/reference/amount) + scadenza.
2. Pagamento in ATM/banca online/negozio partner.
3. Lo statò paid "in linea e il successivo settement nei registri.

5) Stati e calcoli

States online: "created "/" pending "/" success" paid "/" failed "/" canceled "/" expired ".
Settement: solitamente T + 0/T + 2 giorni bancari (contratto/canale).
In logica aziendale condividete la conferma online e il credito effettivo.

6) Limiti, KYC e rischio

• Per-trasmissione, 24h/7d, limite per PIN per pagamento/giorno.
• Per i nuovi destinatari/merchant - soglie/estrazione ridotte.
• Geo-regole (paese voucher vs località client/merchant), velocity, segnali device.
• Charjback non c'è; display - per il provider ODR/PSP.
• La raccomandazione è di mantenere i limiti per paese/rete/CUS e non aggiungere le somme.

7) Rimborsi e prelievi parziali

Refund = nuova operazione di credito (in portafoglio eCash/bonifico bancario, secondo le regole del provider).
Partial refunds sono generalmente supportati.
Per i voucher PIN sono spesso disponibili prelievi parziali e combinazione PIN; per fatture barcode - l'importo è fisso.

8) Economia e tariffe

La commissione per il merchant è generalmente inferiore a un MDR a cartello CNP, ma varia per geo/volume/categoria.
Doping: hosted/SDK, pubblicità punti vendita, zapport/ODR, elaborazione «expired/pending», recon.

9) pattern UX

Pagamento PIN: UI comprensibile per più PIN e indicatore di saldo; messaggi di errore: «non valido/utilizzato», «limite superato», «regione non supportata».
Barcode/QR: codice grande + timer di scadenza, pulsanti «stampa/invia a messenger/email».
Istruzioni di pagamento offline: 3-4 fasi con logo di rete; mappa dei punti/orari di apertura più vicini.
Stato ordine: «In attesa di pagamento» con aggiornamento automatico; «espired» è il pulsante «crea nuovo codice».
Ricevuta: importo, ora, 'paymentId', canale (PIN/Barcode/Reference), UTR/ref. dal registro, contatti dello Zapport.
Localizzazione: valuta/lingua/testi fiscali, marchi locali di rete.

10) Sicurezza e conformità

PI-minimizzazione: PIN/portafoglio vengono introdotti sul provider (Hosted/Widget).
Hook Web: HMAC/nonce, protezione contro replay, deduplicazione eventi, registro di controllo.
KYC/AML/GDPR: regole di età/limiti per i prepagati, sanzioni/geo-limitazioni.
Antifrode: limiti per dispositivo/sessione, cooling-off, step-up, monitoraggio PIN/Barcode ripetuti.

11) Integrazione e architettura

Opzioni di connessione

1. Hosted/Embedded da PSP/provider - avvio rapido, minimo responsabilità per i dati sensibili.
2. Server-to-Server + Hosted è un checkout personalizzato con controllo dello stato, senza PIN elaborato.
3. Pay-by-Link/Invoice - pagamenti di riferimento e zapport valige.

Backend minimo

API: `createPayment|createInvoice` (amount + expiry), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idampotenza ('orderId' + chiave), retrai esponenziali, DLQ, Deduplicazione Web Hook.
Directory: paesi/reti/limiti/livelli CUS, codici di errore, metriche SLA attraverso i canali.
Osservabilità: conversione (PIN vs Barcode/Reference), quota «pending→expired», timing medio prima del pagamento/settement, geo-anomalie.

12) Note geografiche (punti di riferimento)

Европа: Paysafecard, paysafecash, Neosurf, PayPoint/Payzone (UK), ePay/Paylink (EU), Multibanco (PT).
ЛатАм: OXXO Pay (MX), RapiPago/PagoFácil (AR), Efecty/Baloto (CO).
Asia: Konbini (JP) e reti locali (FamilyMart/Lawson/7-Eleven).

13) Assegno foglio di output

1. Seleziona il provider/PSP e le reti di destinazione (PIN/Barcode/Reference), accetta le tariffe/SLA/settement.
2. Implementare «createPayment'createInvoice» con expiry, pagine di istruzioni e script fallback.
3. Collegare webhooks (HMAC), idampotenza, retrai e deduplicazione degli eventi.
4. Impostare daily auto-recon + full-recon, conservare le istruzioni UTR/fine.
5. Attivare partial refunds, procedure ODR e messaggi chiari di guasti/limiti.
6. Avvia i dashboard SLA (conversione, «expired», tempo fino al pagamento/settment) e gli alert per le rassincroni.
7. Eseguire test e2e: PIN multipli, codice a barre scaduto, importo non valido, pagamento doppio, rimborso in parti.

Scheda di riferimento

Статусы: `created/pending/success|paid/failed/canceled/expired`.
Settement: di solito T + 0-T + 2 sui registri PSP/provider.
Chargeback: mancante; Il refund è un'operazione di credito separata.
Limiti/CUS - Dipende dal paese/rete/canale e dal profilo del cliente.
Recurrent: il primo mandato (SEPA/Open-Banking/Locale) per le successive cancellazioni.

Riepilogo

Strategia: eCash-mix (PIN + barcode/QR + reference) per raggiungere il pubblico in contanti e ridurre l'MDR.
Architettura intorno a webhooks + recon, idemoticità rigorosa e UX'pending/expired '.
Configli limiti/CUS e regole geo - fuori dal codice, con aggiornamenti regolari.
Le sottoscrizioni includono il primo mandato, la gestione trasparente e le notifiche per l'utente.