Trustly: pagamenti bancari diretti

1) Cos'è Trustly

Trustly è un provider A2A (account-to-account) di pagamenti e pagamenti che collega i merchant alle banche paganti tramite redict/App2App. L'acquirente conferma il trasferimento presso la propria banca (SCA su PSD2), il Merchant riceve immediatamente la conferma online e l'addebito di fondi arriva attraverso i rapporti/calcoli del provider.

• Costo basso rispetto alle MDR cartucce.
• Ampia geografia in Europa (Nordics, DACH, Benelux, UK, Southern EU, ecc.) + banche locali.
• Pay-ins e Payouts (inclusi gli instant payouts per le banche supportate).
• Soluzioni specializzate per i (ad esempio, Pay N Play: «deposito account creato/verificato»).

2) Linea di prodotti e script

Pay-in (pagamento in banca): Redirect/App2App alla banca pagatrice del SCA per il successo/rifiuto online per il successivo prestito.
Payouts: trasferimento al conto utente; per una serie di banche - istantaneamente (altrimenti T + 1/T + 2).
Pay N Play (iGaming) - Combina il deposito con l'onboard: i segnali KYC vengono recuperati dai dati bancari (nome, BAN/BIC, ecc.), crea un account di gioco senza registrazione separata, può essere Fast Withdraw di nuovo sullo stesso conto.
Account Info/Check (opzionale): conferma della proprietà del conto, verifica del nome/BAN per anti-mule/ODR.

3) Flussi di pagamento: Redirect e App2App

3. 1 Classic redirect

1. Checkout Merchant seleziona la banca (directory/ricerca).
2. Readyrett alla pagina della banca o alla schermata → SCA.
3. Ritorna al sito merchant con stato (success/pending/failed/canceled/expired).
4. In attesa di webhook/report di iscrizione.

3. 2 App2App (mobile)

Aprire un'applicazione bancaria tramite deeplink/intent per confermare il ritorno.
Oltre la conversione e meno pagamenti abbandonati; assicuratevi di tenere fallback su readyrett web.

3. 3 Payouts

Iniziate il pagamento tramite API con l'addebito ordine/vincita; Ottieni lo stato di elaborazione online e il risultato di webhook/registro.
Mantenere Idempotense e la carta di stato dei pagamenti è critico (fino a ripetizioni/rimborsi).

4) Limiti e politiche di rischio

• Per-trasmissione e per-day/week-end limiti di banca pagatore.
• Nuovi destinatari/merchant - soglie ridotte e/o estrazione.
• Regole di canale/velocity, geo/segnali di device, anti-muli.
• Per payouts - singole quote/controlli di soglia (in particolare instant).

5) Stati e calcoli: successo online vs credito effettivo

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Settement: accredito effettivo per rapporti/registri Trustly (spesso T + 1/T + 2 giorni bancari; per alcune destinazioni/pagamenti - instant).
Per i servizi critici, utilizzare il modello «condizionale prima del credito» (ad esempio, attivazione di un prodotto digitale dopo la conferma del settement).

6) Restituzioni e display

Marceback non è presente nelle mappe. Rimborso - Nuovo prestito tramite provider al pagatore.
Partial refunds supportati.
I tempi di rimborso sono bancari (solitamente T + 1/T + 2).
Display - Attraverso i processi ODR del provider e la banca dei pagatori: preparare i fogli dell'ordine, confermare la consegna/fornitura del servizio, comunicare con il payout↔pay -in.

7) Commissioni ed economia

Normalmente fix/bassa percentuale per transazione + tariffe per le funzioni di piattaforma (hosted checkout, report, ODR, payouts/instant).
Pianificare i costi per il supporto di pending/expiries, ODR e recon.

8) Accoppiamento e reporting

Memorizzare il provider «paymentId/transactionId», «orderId», la banca-issuer, le etichette temporali, l'UTR/l'analisi bancaria dei report finiti.
Collegare webhooks al cambio di stato; avvia il daily auto-recon e il full-recon periodico (movimento di iscrizioni/rimborsi/correzioni).
Per payouts, registri separati e mappatura con i bilanci di gioco originali.

9) Pratiche UX

Directory of banks: ricerca rapida, ordinamento per popolarità/ultima scelta.
Mobile-first: offre App2App; in caso di guasto - fallback sul web.
Errori e ripetizioni: codici di causa chiari (limite, errore SCA, timeout), pulsante di ripetizione, metodi alternativi.
Idampotenza: 'orderId' + chiave di idempotenza per safe-retry.
Ricevuta: importo, ora, 'transactionId', banca, canale (App2App/Redirect), collegamento allo zapport.
Payout UX: ETA trasparente (instant/T + 1), stato tracking, notifiche.

10) Pay N Play (per iGaming)

Onboarding senza modulo di registrazione: l'utente seleziona la banca, conferma il deposito e il provider invia i dati bancari (nome/conto) al merchant - crea un account di gioco.
I segnali KYC dalla banca riducono l'attrito e accelerano il primo deposito.
Fast Withdraw - pagamenti sullo stesso conto confermato, spesso istantaneamente.
Sono necessari criteri rigorosi di gioco responsabile, limiti di deposito, registro dei mandati e OPR trasparente.

11) Complaence e sicurezza

PSD2/SCA, device binding e antifrode della banca emittente.
GDPR/PII: memorizza solo gli attributi necessari, cifra il PII, limita l'accesso.
Webhooks: firma HMAC/nonce, protezione contro replay, allowlist IP.
AML/sanzioni: monitoraggio delle transazioni, controllo del nome del conto (name match), segnali anti-mule.

12) Verticale ad alto rischio

La disponibilità e i limiti per determinate categorie (tra cui iGaming, cripto, ecc.) dipendono dal paese e dalle banche partner.
Restrizioni più stringenti, KYC esteso, possibili hold's e prove aggiuntive.
Tenete i binari alternativi (mappe, SEPA, open banking PIS da altri provider), routing sul profilo del cliente.

13) Integrazione merchant: opzioni

1. Hosted/Embedded dal provider

Partenza veloce, lista pronta banche, states, errori, webhooks.

2. Server-to-Server + Redirect/App2App

Più controllo: pagina di selezione della banca, elaborazione profonda degli errori, deeplink/QR personalizzati.

3. Fattura/Richiest-to-Pay

Collegamento di pagamento tramite email/SMS/messaggistica; Comodo per i servizi B2V/servizi.

• Эндпоинты: `createPayment`, `refund`, `createPayout`, `queryStatus`, `webhook`, `reconcile`.
• Idampotenza e dedupe per «orderId».
• Retrai di stato per esposizione, dead-letter per risposte instabili.
• Cataloghi: banche/paesi, limiti/codici di errore, SLA-metriche issuer's '.

14) Architettura «Trustly Gateway»

API strato (REST/GraphQL) per la cassa e i servizi di cassa.
Le code di eventi sono States-Ivent-Billing/CRM/Backend/Analisi.
Osservabilità: conversione in banca/canale, «pending→success/expired», latitanza media a settlement, quota di instant payouts.
Sicurezza: vault per i segreti, IP-allowlist, convalida rigorosa redict-URI, token anti-replay.

15) Assegno foglio di output

1. Selezionare geografia/banche e collegare il canale Trustly a PSP.
2. Implementare «createPayment» + selezionare una banca + redict/App2App con fallback.
3. Collegare webhooks, timeout e ripetizioni dello stato.
4. Configura il recon (daily + full), memorizza le istruzioni UTR/fine.
5. Attivare partial/full refunds, registri ODR, procedure di zapport.
6. Per iGaming: avvia Pay N Play, limiti di deposito, Fast Withdraw, tracking del gioco responsabile.
7. Creare un monitoraggio SLA su banche/canali e alert sugli incidenti.
8. Testate le banche mobili (iOS/Android) e i principali isuer's per paese.

Scheda di riferimento

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settement pay-in: più frequente T + 1/T + 2; payouts - instant dove è disponibile, altrimenti T + 1/T + 2.
Limiti: per-txn/day/week presso issuer'a; nuovi destinatari - soglie ridotte.
Recurrent: tramite e-mandate/SEPA DD/Open Banking (primo A2A mandato).

Riepilogo

Puntate su App2App/Embedded per la conversione e instant payouts per la conservazione.
Condividi la conferma online e il credito effettivo nella logica aziendale.
Non fissare gli importi: conservare i limiti per banca/paese/canale.
Per iGaming, utilizzare Pay N Play con KYC trasparente, limiti e pagamenti rapidi.