E-wallets - Panoramica e confronto

1) Cos'è e-wallet e perché merchant

• Maggiore conversione grazie a App2App/One-tap, riconoscimento locale e dati salvati.
• Basso frodo (SCA, device bining, risk screen provider).
• Flessibilità delle fonti: carta, A2A (bonifico bancario/open banking), cash-voucher, saldo mobile.
• Geografia avanzata e accesso a pubblici senza carta di credito.

2) Classificazione portafogli

1. Stored-value (bilanci)

L'utente memorizza il denaro nel portafoglio. Fitzy: top up, edicola interna, P2P, pagamenti dal saldo. Esempi: Skrill/Neteller, myPaysafe/myNeosurf, portafogli EMI locali.
Pro: ripetizioni/restituzioni veloci, pubblico off-card. Meno: livelli KYC, limiti per top up/output.

2. Pass-through / Pay-by-bank / Bank-linked

Il denaro viene prelevato direttamente dal conto bancario/alla carta tramite conferma in applicazione (spesso senza deposito di saldo). Esempi: MB WAY, Swish, Vipps, TWINT, Bizum.
I vantaggi sono il basso frod e MDR, i prestiti immediati. Contro - limiti per le banche, mancanza di classica chargeback.

3. Ibridi

Portafoglio + carta/carta virtuale/routing (ad esempio wallet → card rails), o super applicazioni con fatture, QR, P2P, pay-by-link.

3) Fonti di strumenti e flussi

Top-up: mappa (CNP/3DS), A2A (SCT/SEPA Instant, RTP), cash voucher, punti agenzia.
Pay-in (merchante): App2App/Deep Link, QR per-order, hosted page, toccata da COF/Network tokens (per portafogli a cartucce).
P2P al telefono/aliasu, all'interno del portafoglio/schema.
Cash-out: trasferimento bancario (SCT/ACH/RTP), sulla carta (OCT/Push-to-Card), sulla rete offline, meno su voucher.

4) pattern UX che influenzano la conversione

App2App/Deeplink con rimborso alla cassa e pre-completamento dell'importo/mandato.
QR dinamico per-order (dectop/offline), timer di vita, aggiornamento automatico dello stato.
One-tap/One-click dopo il riferimento primario (se consentito).
Errori chiari e recovery: limite, timeout, guasto SCA; ripetizione sicura + suggerire un metodo alternativo.

5) Limiti, livelli KYC e rischio

Per-trasmissione/24h/7d/monthly, soglie separate per nuovi destinatari/merchant.
Livelli KYC (anonimo/semplificato/completo): determinano i massimi per top up/spese/output.
Velocity/device/geo-regole, sanzioni, limiti di età.
High-risk verticale (comprese le iGaming): limiti rigidi, colli, monitoraggio avanzato.

6) Restituzioni, display e finalità

Chargeback: stored-value spesso non ha charjback classico; I portafogli sui binari di cartuccia hanno regole di carta.
Refunds: di solito prestare una transazione separata (full/partial) al portafoglio/conto cliente.
Finalità A2A: pagamenti finali dopo la conferma; Utilizzare le procedure ODR del provider.

7) Economia: commissioni e costi nascosti

MDR/fee generalmente sotto le schede CNP; dipende da geo, traffico, categoria MCC.
Doping: host/SDK, elaborazione dì pending/expired ', zapport/ODR, recon, manutenzione dei mandati/sottoscrizioni, AML/KYC Check-Up.

8) Stati e calcoli

• `created → pending → success | failed | canceled | expired`
• Settement: T + 0/T + 2 nei registri del provider/PSP. In logica aziendale condividete la conferma online e il credito effettivo.

9) Matrice di criteri comparata

Tipo: stored-value/pass-through/ibrido

Risorse: scheda/A2A/ eCash/bilancia mobile

Canali UX: App2App/QR/Hosted/Pay-by-Link

P2P/Payouts: c'è/no, limiti e scadenze

Refund/Chargeback: Se c'è una chargeback; partial refunds

Conversione: priorità mobile, One-tap

Commissione: riferimento contro le schede CNP

Rischio: frode, finalità, requisiti regolatori

Geo-copertura/marchio locale: riconoscibilità del pubblico target

10) Integrazione: opzioni e backend minimo

1. Hosted/Embedded da PSP/portafoglio - partenza rapida, minimizzazione del PII.

2. Server-to-Server + App2App/QR - UX custome, pagina personalizzata per la selezione del portafoglio.

3. Pay-by-Link/Invoice è utile per pagamenti/raccolte in ritardo.

• API: `createPayment`, `refund`, `webhook`, `queryStatus`, `reconcile`.
• Idampotenza ('orderId' + chiave), retrai esponenziali, dedotto degli eventi, DLQ.
• Webhooks: HMAC/nonce, protezione contro replay, convalida rigorosa redict-URI.
• Recon: daily auto-recon + full-recon periodico; memorizzare UTR/fine. L'arbitraggio.
• Cataloghi: provider/paesi/limiti/CUS/codici di errore; Metriche SLA attraverso i canali.
• Osservabilità: conversione (per portafogli/canali), «pending→success/expired», latitanza a settlement/ritorno.

11) Sottoscrizioni e mandati

• Primo pagamento del mandato (SEPA DD/Open Banking/portafoglio-mandato).
• Conserva il limite per-debit, la frequenza, la finestra di prelievo, la pre-notifica e la gestione UI (pausa/cancel/update).

12) Pratiche antifrode

Profilazione del dispositivo e comportamento, geo-segnali, velocity.
Step-up (autenticazione) in caso di anomalie.
Limiti per i nuovi beneficiari/pagamenti, cooling-off, esecuzione posticipata del servizio a settement.
Contenuto frod (chiavi digitali/skin) - Rilascio ritardato, verifica della cronologia dell'account.

13) Accoppiamento e reporting (maturità operativa)

• «paymentId/transactionId», «orderId», portafoglio/canale (App2App/QR/Hosted/Link), fonte di fondi (scheda/A2A/eCash), stato, somma/valuta, timestamps, UTR/link bancario, informazioni sui rimborsi.
• Dashboard SLA: conversione per portafogli, quota «expired», tempo prima dell'iscrizione e fino al rifund, rifiuto SCA/limiti.
• Alert di rassincroni, successo online senza iscrizione, doppi prelievi, pending.

14) iGaming e altre verticali sensibili

Verificare i criteri del provider e il diritto locale (disponibilità, limiti, colli).
Pianificare binari alternativi (mappe/A2A/eCash) e smart-routing per rischio/geo/portafoglio.
Preparazione di report avanzati (fonte di fondi, limiti del giocatore, velocità di pagamento, responsibile-gaming).

15) Mini-confronto per tipologia di profili

A. Portafogli locali-linked (MB WAY/Swish/Vipps/TWINT/Bizum-simili)

La conversione è alta (App2App/QR, marchio abituale).
Frod/conformeback: basso/mancante; refund come prestito separato.
Limiti: definiscono banche/schema; più duro per i nuovi beneficiari/pagamenti.
Utilizzo: pagamenti massicci, biglietti/servizi, politica PSP/banche.

B. Stored-value (Skrill/Neteller/myPaysafe/myNeosurf и др.)

La conversione è alta quando il database utente è attivo.
Il frodo è basso, ma richiede un KYC/AML rigoroso.
Pro: rapido partial refunds, ripetizioni istantanee, P2P.
Contro - Limiti per top up/output per livello KYC.

C. eCash/sorgenti voucher all'interno dei portafogli

Il pubblico senza carte/banche è critico per i geo con l'economia in contanti.
Finalità: alta; la restituzione è un prestito.
UX: è importante mostrare «dove acquistare i voucher» e il timer della fattura/codice a barre.

16) Assegno-foglio di output e-wallets in provetta

1. Market-fit: seleziona 2-4 portafogli per geo/pubblico; Apprezzate il marchio di riconoscimento.
2. Contratto/PSP: tariffe, SLA su webhooks/registri, scadenza settement, politica di rimborso.
3. Integrazione: 'createPayment' + App2App/QR/Hosted, schermate di errore/limiti, ripetizioni sicure.
4. Sicurezza: HMAC/nonce, allowlist IP, rigidi redict-URI, vault segreti.
5. Recon: daily + full, deposito UTR, alert di rassincroni.
6. Refunds/ODR: partial/full, riferimento al mandato originale, codice dello zappello.
7. CUS/limiti: confighi per provider/canale, UI cause di rifiuto e offerte alternative.
8. Osservabilità: dashboard di conversione/latenza/expired, tagli per dispositivi/banche/portafogli.
9. Test: e2e per le principali banche/portafogli, QR-top, rete/timeout debole, pending, rimborsi in parti.

Scheda di riferimento

Статусы: `created/pending/success/failed/canceled/expired` + webhooks.
Settement: T + 0-T + 2 per report fornitore/PSP.
Chargeback: non più frequente (tranne i binari di caratura); Il refund è un prestito separato.
Limiti/CUS - Livelli nel portafoglio + soglie di canale nelle banche/diagrammi.
Sottoscrizioni: «Primo pagamento del mandato» (SEPA/Open Banking/portafoglio-mandato).

Riepilogo

Costruisci una cassa intorno a un multi-cartellino con App2App/QR e una recovery-UX nitida, che aumenta la conversione e riduce il frodo.
Memorizzare i limiti/CUS/errori nella configurazione e non nel codice; aggiornare regolarmente i provider.
L'affidabilità operativa è fornita da webhooks + recon rigido, idipotenza e analisi «pending→success/expired».
Utilizzare i mandati per le sottoscrizioni. per high-risk mantenere binari alternativi e smart-routing per rischio e geografia.