Swish Suède : paiements mobiles

1) Qu'est-ce que Swish

Swish est le système national suédois de paiement mobile A2A (opérateur Getswish AB) avec transferts instantanés 24/7. L'utilisateur confirme les transactions via BankID (SCA). Les scénarios P2P (par téléphone), les P2M d'affaires (en ligne et hors ligne), les donats et les paiements sont pris en charge.

• Adressez-vous par numéro de téléphone (ou numéro merchant/QR), sans IBAN dans UX.
• Crédité instantanée sur le compte bancaire du destinataire ; finalité du virement bancaire.
• Faible frottement : App2App/QR, confirmation dans BankID.
• Couverture bancaire étendue et grande popularité dans le commerce de détail/en ligne.

2) Rôles et produits

Getswish (schéma) - règles, catalogues et marque.
Banques participantes - émettent/connectent Swish, appliquent des limites et des antifrods.
PSP/acquéreurs - connectent les merchants (Swish Handel/Swish Företag), fournissent API/SDK, rapports, settlement.

• Swish P2P - traductions entre particuliers.
• Swish Företag - Acceptez les paiements hors ligne (vitrine/POS).
• Swish Handel (Swish for e-commerce) - chekout en ligne (QR/App2App/Link).
• Swish Donations - numéros courts/alias pour les dons.
• Swish Payouts/Disbursements - paiements massifs (par l'intermédiaire de la banque/PSP).

3) Flux de paiement

3. 1 P2P (push)

1. L'expéditeur sélectionne le contact par téléphone → entre le montant/message.
2. Confirme dans BankID (Face/Touch/code).
3. Le destinataire voit instantanément le crédit sur le compte et la notification dans l'application.

3. 2 P2M: e-commerce (Swish Handel)

• App2App/Deeplink : sur chekout, nous ouvrons l'application Swish/BankID → confirmation → retour au merchant.
• QR per-order : QR dynamique est généré (somme, orderId, merchant reference) ; le client scanne la caméra Swish → confirme auprès de BankID.

3. 3 POS/hors ligne (Företag)

QR dynamique à la caisse ou numéro Swish statique (somme manuelle).
Confirmation auprès de BankID ; le chèque est au merchant et dans l'application du client.

3. 4 Request-to-Rau/Factures

Merchant envoie un lien de paiement/demande (par email/SMS/messager) ; le client confirme auprès de BankID.

3. 5 Paiements (Payouts)

L'entreprise envoie un mandat au client au numéro de téléphone par l'intermédiaire de la banque/PSP ; l'antifrode et les limites de départ sont appliquées.

4) Statuts et temporisations

États types : 'initiated' → 'pending' → 'success '/' failed '/' canceled '/' expired'.
L'application/BankID peut être retardée pour le checkout Web → gardez les délais et le statut (polling + webhooks).
Settlement pour le merchant - crédit bancaire en temps réel/au créneau d'exploitation le plus proche en fonction de la banque/PSP (faites un recon journalier pour les rapports de toute façon).

5) Limites et politiques de risque

• Per-transaction, per-day/24h; parfois weekly/monthly.
• Nouveau destinataire/nouveau merchant - seuils réduits/vitesse d'obturation.
• Limites de canal : P2P, e-commerce (App2App/QR), POS, payouts.
• Velocity/device/géo-règles et risque-scoring côté banque.

6) Économie et commissions

Le coût du merchant est généralement inférieur à la carte MDR classique, mais les conditions dépendent de la banque/PSP (fix/faible pourcentage, frais QR/SDK/rapports).
Fixez les coûts du support « pending/expired », des disputes, de la récupération et de la surveillance des SLA.

7) Retours et disputes (ODR)

Chargeback n'est pas comme dans les cartes. Retour - opération de crédit séparée du merchant au client (pris en charge par les fonds partiels).
Les délais sont bancaires (généralement T + 0/T + 1).
Disputes - selon les procédures de la banque/PSP : stockez les logs de commande, la preuve de la prestation du service/de la livraison, la conformité des détails du client.

8) Sécurité et conformité

SCA via BankID, device binding, vérification SIM/device par la banque.
Minimisation des PII : ne stocker que les attributs nécessaires (téléphone/référents), chiffrer les PII ; accès - selon le principe du moindre privilège.
Webhooks : HMAC/nonce, protection contre le replay, timing et déduplication des événements.
Répondre aux exigences PSD2/GDPR et locales de Finansinspektionen.

9) Intégration du merchant

Options

1. Hosted/Embedded de PSP - démarrage rapide, App2App/QR de la boîte, statuts et erreurs.
2. Server-to-Server + App2App/QR est votre propre UX, QR dynamique per-order, traitement profond des erreurs/répétitions.
3. Pay-by-Link/Invoice - envoyer une référence/demande ; commode pour les services et B2B.

• API : 'createPayment', 'refund', 'requestToPay' (si disponible chez PSP), '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', latence avant inscription.

10) Rapprochement et établissement de rapports

Loger : 'paymentId/transactionId' fournisseur, 'orderId', canal (App2App/QR/Link/POS), numéro de destinataire, statut, montant/devise, timestamp, UTR.
De PSP/banque : registres d'inscription/de retour/de correction, mises à jour tardives des statuts.
Activez les alertes par dissynchrones et anomalies (doubles débits, pending).

11) Modèles UX

Mobile-first : Auto-proposition de App2App ; sur le bureau, un QR dynamique majeur avec un minuteur.
Erreurs transparentes : limite, échec de BankID, délai ; une répétition sécurisée et une alternative (carte/SEPA/A2A d'un autre fournisseur).
Reçu : montant, temps, 'transactionId', canal, UTR, contacts de sapport.
Temporisateur d'action pour QR/requêtes et script de récupération après expiration.

12) Récurrence et mandats

Basic Swish - one-off avec SCA. Pour les abonnements, un lien est appliqué : premier paiement Swish → e-mandate/Autogiro/Open-Banking PIS pour d'autres débits (limite/fréquence/notifications, écran de gestion de mandat).

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, KYC étendu et hold's possibles.
Prévoyez des rails alternatifs (cartes, SEPA, autres PIS) et un routage intelligent par risque/banque/canal.

14) Architecture « Swish 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/POS/Link), fraction « pending→expired », temps avant le settlement/retour.

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

1. Branchez votre PSP/banque avec Swish Handel/Företag ; accepter les tarifs/SLA et les canaux (App2App/QR/POS/Link).
2. Implémentez 'createPayment' + QR/App2App 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. Inclure 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, 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 P2P, e-commerce (App2App/QR), POS, payouts.
Velocity/risque : l'antifrod de la banque peut légèrement rejeter/ralentir les opérations.

Résumé

Pour en ligne - App2App + QR dynamique, pour offline - QR/POS (Företag), pour les traductions - P2P vers le téléphone.
Partagez la confirmation en ligne et le crédit final dans la logique d'entreprise ; construisez autour de webhooks + recon et refunds partiels.
Ne fixez pas les montants : maintenez les limites configues sur les banques/canaux avec une actualisation régulière.
Pour les abonnements, le premier mandat Swish → avec une gestion et des notifications transparentes.