TWINT Suisse : QR et in-app

1) Contexte et positionnement TWINT

TWINT est un système suisse de paiement mobile A2A et un portefeuille intégré aux banques du pays. L'utilisateur paie à partir de l'application TWINT/banque : en ligne - via in-app/App2App ou Deep Link, en ligne - via QR (standard « TWINT QR »). La confirmation est effectuée en annexe (SCA : PIN/biométrie), les fonds sont débités du compte/carte associé et crédités au merchant par un crédit bancaire.

• Une seule marque/QR pour en ligne et POS, une couverture utilisateur élevée.
• Confirmation instantanée en ligne pour UX et installation rapide (dans les guichets bancaires).
• P2P par numéro de téléphone/contact à l'intérieur de l'écosystème.
• Faible frod au détriment de SCA et binding device.

2) Participants et rôles

TWINT (schéma/pull) : règles, répertoires des participants, routage.
Banques participantes/émetteurs TWINT : KYC, limites et antifrood.
PSP/acquéreurs : connectez le merchant (en ligne/POS), fournissez des API/SDK, des harceleurs Web et des rapports.
Merchant : initie le paiement/demande, traite les statuts/retours, maintient un rapprochement.
Payeur : confirme les transactions dans l'application TWINT/banque.

3) Canaux et scripts personnalisés

3. 1 E-commerce: in-app / Deep Link / App2App

Sur checkout, le merchant crée un intent de paiement → donne Deep Link/bouton « Payer TWINT ».
L'application TWINT s'ouvre (App2App) et l'utilisateur confirme → retour à la caisse.
Un QR dynamique per-order est affiché pour le desktop ; le client scanne dans l'application et confirme.

3. 2 POS/hors ligne : TWINT QR

QR dynamique sur l'écran de la caisse/terminal : somme, orderId, métadonnées.
L'utilisateur scanne → confirme dans l'application → le merchant obtient le statut en ligne.
Le QR statique (la somme est saisie manuellement) est applicable pour les donats/petits détail, mais pire dans le rapprochement.

3. 3 P2P « par téléphone »

Transferts entre physiciens par numéro de téléphone/contact avec confirmation push et crédit instantané au destinataire.

3. 4 Request-to-Pay / Pay-by-Link

Merchant lance une demande de paiement (montant/destination/durée) → le client confirme dans l'application → le paiement passe par le flou A2A habituel.

4) Statuts et temporisations

États types : 'initiated' → 'pending' → 'success '/' failed '/' canceled '/' expired'.
Pour QR/Desktop, tenez compte du délai de confirmation (montrez la minuterie).
Settlement : crédit bancaire T + 0/T + 1 en fonction de la fenêtre de règlement/PSP ; le recon journalier est quand même obligatoire pour la déclaration.

5) Limites et politiques de risque

• Per-transaction, per-day/24h, parfois weekly/monthly.
• Nouveau destinataire/merchant - seuils réduits et/ou vitesse d'obturation.
• Limites de canal : e-commerce (Deep Link/QR), POS, P2P, Request-to-Pay.
• Velocity/device/géo-règles sont appliquées par les banques et le schéma.

6) Économie et commissions

Pour le merchant TWINT est généralement moins cher que le MDR de carte typique ; les conditions varient chez les PSP (fix/faible %).
Fixez les coûts d'intégration/SDK, de traitement 'pending/expired', de support/ODR et de rapprochement.

7) Retours et disputes

Chargeback (comme dans les cartes) est absent. Retour - nouvelle opération de crédit du merchant au payeur ; les fonds partiels sont pris en charge.
Les délais de remboursement sont bancaires (généralement T + 0/T + 1).
Disputes/plaintes - sur les procédures PSP/banque ; gardez les logs de commande, la preuve de service/livraison, le lien de refund↔order.

8) Sécurité et conformité

SCA dans l'application TWINT/Bank (PIN/biométrie), device binding.
Antifrod chez la banque/PSP : velocity, nouveaux bénéficiaires, risque-scoring.
PII-minimisation et cryptage, HMAC/nonce sur le Web, protection contre le replay, journal d'audit.
Respecter les exigences locales en matière de services de paiement et les normes de protection des données comparables au RGPD.

9) Intégration du merchant

Options

1. Hosted/Embedded de PSP - démarrage rapide, in-app/QR de l'emballage, les statuts et les erreurs.
2. Server-to-Server + Deep Link/QR - propre UX, dynamique QR per-order, traitement fin des erreurs.
3. Pay-by-Link/Request-to-Pay - Facturation par lien (email/SMS/messager).

• API: `createPayment`, `refund`, `requestToPay`, `webhook`, `reconcile`.
• Idempotence ('orderId' + clé), rétroactions exponentielles, déduplication d'événements.
• Recon : daily auto-recon + périodique full-recon ; conserver l'UTR/référence bancaire.
• SLA-dashboards : conversion, 'pending→success/expired', le temps avant l'inscription/retour.

10) Rapprochement et établissement de rapports

Loger : 'paymentId/transactionId' fournisseur, 'orderId', canal (App2App/QR/Link), banque du payeur, statut, montant/devise, timestamp, UTR.
Par PSP/banque : registres d'inscription/de retour/de correction, mises à jour tardives des statuts.
Configurez les alertes par dissynchrones et « pending ».

11) Pratiques UX

Mobile-first : sur mobile - in-app/App2App ; sur le bureau, un QR dynamique majeur avec un minuteur.
Récupération : avec 'timeout/expired', une répétition et une alternative sécurisées (carte/SEPA/autre A2A).
Reçu : montant, temps, 'transactionId', canal, UTR, contacts de sapport.
Mise en évidence des risques/limites : montrez à l'utilisateur qui a posé le seuil - banque ou canal.

12) Récurrence et mandats

Le TWINT de base est un-off avec SCA. Pour les abonnements, utilisez le lien : premier paiement TWINT → e-mandate/SEPA DD/Open-Banking pour les futurs débits (limite/fréquence/notifications).
Donnez à l'utilisateur un écran de gestion des mandats (pause/cancel/update) et une pré-notification avant de passer par profits et pertes.

13) Verticales à haut risque (y compris iGaming)

La disponibilité des canaux et les limites dépendent de la politique de la banque/PSP et du droit local.
Attendez-vous à des seuils réduits, des KYC renforcés, des hold's possibles.
Prévoyez des rails alternatifs (cartes, SEPA, autres PIS) et un routage intelligent par risque/canal/pot.

14) Architecture « TWINT Gateway »

Couche API (REST/GraphQL) pour la caisse et le backoffice.
Files d'attente d'événements : États-participants → facturation/CRM/analyse.
Sécurité : vault pour les secrets, IP-allowlist PSP, validation stricte de redirect-URI, jetons anti-replay.
Observability : conversion sur les canaux (App2App/QR/Link), fraction « pending→expired », temps avant le settlement/retour.

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

1. Connectez TWINT au PSP/banque ; sélectionnez les canaux (App2App/QR/Link).
2. Implémentez 'createPayment '/' requestToPay', QR dynamique, écrans d'erreur/limites.
3. Connectez webhooks, idempotence, retraits et dedup d'événements.
4. Configurez recon (daily + full), stockage UTR/fin-références.
5. Soutenez les procédures partial/full refunds et ODR.
6. Exécutez les SLA-dashboards et les alertes par conversion/latence/status suspendus.
7. Effectuez des tests e2e avec les banques/appareils principaux et le POS (le cas échéant).

Carte de référence par limite

Per-txn/24h/7d : stocker dans un configh et vérifier avant le démarrage.
Nouveaux récipiendaires/merchants : seuils réduits/vitesse d'obturation.
Canaux : limites séparées pour e-commerce (App2App/QR), POS, P2P, Request-to-Pay.
Velocity/risque : l'antifrod de la banque peut légèrement rejeter/ralentir les opérations.

Résumé

Pour en ligne - in-app/App2App + QR dynamique, pour le commerce de détail - TWINT QR, pour les traductions - P2P vers le téléphone.
Partagez la confirmation en ligne et le crédit final ; construisez autour de webhooks + recon et refunds partiels.
Ne fixez pas les montants : maintenez les limites configues sur les banques/canaux et mettez à jour régulièrement.
Pour les abonnements, le premier TWINT → un mandat avec une gestion et des notifications transparentes.