Trustly : paiements bancaires directs

1) Qu'est-ce que Trustly

Trustly est un fournisseur A2A (account-to-account) de paiements et de paiements qui relie les merchants aux banques des payeurs par l'intermédiaire de redirect/App2App. L'acheteur confirme le transfert dans sa banque (SCA PSD2), le merchant reçoit instantanément la confirmation en ligne, et le crédit vient par le biais des rapports/calculs du fournisseur.

• Faible coût par rapport aux MDR de cartes.
• Géographie étendue en Europe (Nordics, DACH, Benelux, UK, Southern EU, etc.) + banques locales.
• Pay-ins et Payouts (y compris les payouts instantanés pour les banques soutenues).
• Solutions spécialisées pour iGaming (par exemple, Pay N Play : « dépôt → compte créé/vérifié »).

2) Gamme de produits et scénarios

Pay-in (paiement bancaire) : redirect/App2App à la banque du payeur → SCA → succès/refus en ligne → crédit ultérieur.
Payouts (paiements) : virement sur le compte de l'utilisateur ; pour un certain nombre de banques - instantanément (sinon T + 1/T + 2).
Pay N Play (iGaming) : combine le dépôt avec l'onbording : les signaux KYC sont extraits des données bancaires (nom, IBAN/BIC, etc.), un compte de jeu est créé sans inscription séparée, Fast Withdraw est possible sur le même compte.
Compte Info/Check (en option) : preuve de possession du compte, vérification du nom/IBAN pour anti-mule/ODR.

3) Flux de paiement : Redirect et App2App

3. 1 Classic redirect

1. Checkout merchant → la sélection de la banque (répertoire/recherche).
2. Redirect vers la page de la banque ou l'écran hébergé → SCA.
3. Retour sur le site du merchant avec statut (success/pending/failed/canceled/expired).
4. En attente du webhook/rapport d'inscription (settlement).

3. 2 App2App (mobile)

Ouverture de l'application bancaire via deeplink/intent → confirmation → retour.
Plus de conversion et moins de paiements abandonnés ; assurez-vous de garder fallback sur le web redirect.

3. 3 Payouts

Initiez le paiement via l'API avec le référent commande/gain ; obtenir le statut en ligne « accepté au traitement » et le total par webhook/registre.
Maintenir l'idempotence et la carte des états de paiement est critique (jusqu'aux répétitions/retours).

4) Limites et politiques de risque

• Par transaction et par jour/semaine limites à la banque du payeur.
• Nouveaux destinataires/merchants - seuils réduits et/ou vitesse d'obturation.
• Règles de canal/velocity, signaux géo/device, anti-mules.
• Pour les payouts, des quotas/des contrôles de seuil distincts (en particulier instantanés).

5) Statuts et calculs : succès en ligne vs crédit réel

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement : inscription effective sur les registres Trustly (souvent T + 1/T + 2 jours bancaires ; pour certaines destinations/paiements - instant).
Pour les services critiques, appliquez le modèle « exécution conditionnelle avant crédit » (par exemple, activation d'un article numérique après confirmation du settlement).

6) Retours et disputes

Chargeback n'est pas comme dans les cartes. Retour - nouvelle opération de crédit par l'intermédiaire du fournisseur au payeur.
Les fonds partiels sont pris en charge.
Les délais de retour sont bancaires (généralement T + 1/T + 2).
Disputes - par le biais des processus ODR du fournisseur et de la banque du payeur : préparez les logs de commande, la confirmation de livraison/prestation de service, les communications payout↔pay -in.

7) Commissions et économie

Habituellement, fix/faible pourcentage par transaction + frais pour les fonctions de plateforme (hosted checkout, reporting, ODR, payouts/instant).
Planifiez les dépenses de support pending/expiries, ODR et recon.

8) Rapprochement et établissement de rapports (reconnaissance)

Stockez 'paymentId/transactionId' du fournisseur, 'orderId', banque-issuer, horodatages, UTR/référence bancaire à partir des rapports finaux.
Connectez les webhooks pour changer d'état ; lancez daily auto-recon et périodique full-recon (mouvement sur les inscriptions/retours/corrections).
Pour les payouts, des registres distincts et des correspondances avec les soldes de paiement/de jeu d'origine.

9) Pratiques UX

Répertoire des banques : recherche rapide, triage par popularité/dernière sélection.
Mobile-first : offrir des App2App ; en cas d'échec - fallback sur le web.
Erreurs et répétitions : codes de cause clairs (limite, échec SCA, délai), bouton de répétition, méthodes alternatives.
Idempotence : 'orderId' + clé d'idempotence pour safe-retry.
Reçu : montant, heure, 'transactionId', banque, canal (App2App/Redirect), référence de sapport.
Payout UX : ETA transparent (instant/T + 1), statut de suivi, notifications.

10) Pay N Play (pour iGaming)

Onbording sans formulaire d'inscription : l'utilisateur choisit la banque, confirme le dépôt, et le fournisseur donne au merchant les données bancaires vérifiées (nom/compte) - un compte de jeu est créé.
Les signaux KYC de la banque réduisent la friction et accélèrent le premier dépôt.
Fast Withdraw : paiements sur le même compte confirmé, souvent instantanément.
Des politiques strictes de jeu responsable, des limites de dépôt, un journal des mandats et un ODR transparent sont nécessaires.

11) Conformité et sécurité

PSD2/SCA, device binding et antifrod de la banque émettrice.
Minimisation GDPR/PII : ne stocker que les attributs nécessaires, chiffrer les PII, limiter l'accès.
Webhooks : Signatures HMAC/nonce, protection contre le replay, IP allowlist.
AML/sanctions : surveillance des transactions, vérification du nom du compte (name match), signaux anti-mule.

12) Verticales à haut risque

L'accessibilité et les limites pour certaines catégories (y compris iGaming, crypto, etc.) dépendent du pays et des banques partenaires.
Attendez-vous : limites renforcées, KYC élargi, hold's possibles et des preuves supplémentaires.
Gardez les rails alternatifs (cartes, SEPA, open banking PIS d'autres fournisseurs), le routage par profil client.

13) Intégration du merchant : options

1. Hébergé/Embarqué par le fournisseur

Démarrage rapide, liste prête des banques, statuts, erreurs, webhooks.

2. Server-to-Server + Redirect/App2App

Plus de contrôle : propre page de sélection de banque, gestion profonde des erreurs, propre deeplink/QR.

3. Facturation/Request-to-Pay

Lien de paiement par email/SMS/messager ; Pratique pour B2V/services.

• Эндпоинты: `createPayment`, `refund`, `createPayout`, `queryStatus`, `webhook`, `reconcile`.
• Idempotence et dedupe par 'orderId'.
• Retraits des statuts par exposant, dead-letter aux réponses instables.
• Catalogues : banques/pays, limites/codes d'erreur, métriques SLA par issuer'am.

14) Architecture « Trustly Gateway »

Couche API (REST/GraphQL) pour la caisse et les services de caissier.
Files d'attente d'événements : États-participants → facturation/CRM/backend/analytique de jeu.
Observability : conversion par banques/canaux, 'pending→success/expired', latence moyenne jusqu'à settlement, proportion de paiements instantanés.
Sécurité : vault pour les secrets, IP-allowlist, validation stricte de redirect-URI, jetons anti-replay.

15) Chèque-liste de sortie dans la prod

1. Sélectionnez géographies/banques et connectez le canal Trustly à PSP.
2. Implémentez 'createPayment' + sélection banque + redirect/App2App avec fallback.
3. Connectez les webhooks, les délais et les répétitions d'obtention des statuts.
4. Configurez recon (daily + full), stockage UTR/fin-références.
5. Inclure les fonds partiels/complets, les revues ODR, les procédures de sappport.
6. Pour iGaming - Lancez Pay N Play, limites de dépôt, Fast Withdraw, tracking jeu responsable.
7. Construisez la surveillance des SLA par les banques/canaux et les alertes d'incident.
8. Testez les banques mobiles (iOS/Android) et les principaux issuer's par pays.

Carte de repères

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement pay-in : plus souvent T + 1/T + 2 ; payouts - instant où disponible, sinon T + 1/T + 2.
Limites : per-txn/day/week chez issuer'a ; les nouveaux bénéficiaires sont des seuils réduits.
Recurrent : via e-mandate/SEPA DD/Open Banking (premier A2A → mandat).

Résumé

Pariez sur le App2App/Embedded pour la conversion et les paiements instantanés pour la rétention.
Partagez la confirmation en ligne et le crédit réel dans la logique d'entreprise.
Ne fixez pas les montants : maintenez les limites par banque/pays/canal.
Pour iGaming, utilisez Pay N Play avec KYC transparent, limites et paiements rapides.