MB WAY Portugal : portefeuille et P2P

1) Qu'est-ce que MB WAY et où il vit dans l'écosystème

MB WAY est un portefeuille mobile portugais sur les rails du groupe SIBS/Multibanco qui combine les cartes et les comptes bancaires de l'utilisateur pour les paiements instantanés P2P, les achats en ligne et hors ligne (QR/NFC, cash-out dans les guichets automatiques sans carte). Confirmation - dans l'annexe MB WAY/Bank (SCA : PIN/biométrie). Les commissions pour le merchant sont généralement inférieures au MDR classique par le traitement local.

• Lier les cartes/comptes (debit/credit) à l'application → payer avec une seule confirmation.
• P2P « au téléphone » : traduction au contact par numéro, 24/7.
• Checkout en ligne avec confirmation push sans entrée de carte.
• QR/NFC en vente au détail et MB WAY Cash-out en ATM (cardless).
• Riche en métadonnées et intégration stable via SIBS Gateway/PSP.

2) Participants et rôles

SIBS/Multibanco (régime/traitement) : règles, itinéraires, catalogues banques/merchants.
Banque/émetteur de carte : KYC, limites, antifrod, débit/crédit.
PSP/acquéreur (SIBS Gateway et al.) : connexion au merchant, SDK/API, rapports, calculs.
Merchant : initie le paiement/demande, reçoit les statuts et maintient un rapprochement.
Payeur : confirme les transactions dans l'application MB WAY/banque.

3) Modes et scripts personnalisés

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

L'expéditeur sélectionne le contact dans l'annuaire téléphonique → entre le montant → confirme dans l'application.
Le destinataire reçoit une push/notification, l'argent est crédité sur un compte/carte lié.

3. 2 Tchekout en ligne (e-commerce, in-app)

Sur la caisse du merchant, l'utilisateur entre le numéro de téléphone MB WAY ou scanne QR.
L'application envoie une requête push → l'utilisateur confirme → le merchant obtient le statut en ligne.
Dans les applications mobiles - App2App/deeplink avec l'ouverture automatique MB WAY.

3. 3 POS/hors ligne

QR dynamique per-order à la caisse (somme + orderId) ou paiement NFC via l'application.
Confirmation - pushem, reçu - au merchant et dans l'application.

3. 4 Cash-out в ATM (MB WAY Lift)

L'utilisateur génère le code/confirme dans l'application → retire l'argent sans carte en plastique.

3. 5 Split Bill / Request Money

Demande d'argent aux contacts (collectes), séparant automatiquement les montants entre les participants.

4) État des opérations

'initiated' → 'pending' (en attente de confirmation/réponse réseau) → 'success '/' failed '/' canceled '/' expired'.
Pour les factures/Request Money, un 'request' séparé/' expired '.

5) Limites et politiques de risque

• Per-transaction, per-day/24h, parfois weekly/monthly.
• Nouveau destinataire/merchant - seuils réduits, vitesse d'obturation ou confirmation.
• Limites de canal : P2P, e-commerce, POS/QR/NFC, ATM (cash-out).
• Velocity et règles device : antifrod sur le côté banque/circuit.

6) Commissions et économie

Pour le merchant MB WAY est généralement moins cher que les cartes classiques, mais les conditions dépendent du PSP/tarif.
Dop. coûts : hébergement/SDK, rapports, ODR/support, traitement 'pending/expired', recon.

7) Retours et disputes

Chargeback comme dans les cartes ne s'applique pas aux flux A2A : le retour est une nouvelle opération de crédit (full/partial).
Si le paiement a été effectué sur une carte tokénisée à l'intérieur de MB WAY, les procédures de carte sont appliquées (selon les règles d'acquisition).
ODR/plaintes - par l'intermédiaire de PSP/banque ; préparer les logs de commande, preuve de prestation de service/livraison.

8) Sécurité et conformité

SCA (PIN/Face/Touch) dans l'application, binding de périphérique, vérification SIM/périphérique.
Minimisation PII, cryptage Web, HMAC/nonce, protection contre le replay.
Conformité avec les exigences PSD2/GDPR et locales de la Banque du Portugal.

9) Intégration du merchant

Options

1. Hosted/Embedded (SIBS/PSP) - démarrage rapide, push/QR sortie de l'emballage.
2. Server-to-Server + App2App/QR est votre propre UX, gestion profonde des erreurs, dynamique QR per-order.
3. Pay-by-Link/Request Money - compte sur le lien dans les messagers/email/SMS.

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

10) Rapprochement et établissement de rapports

Loger : 'paymentId/transactionId', 'orderId', canal (P2P/QR/App2App/NFC), banque du payeur, statut, montant/devise, timestamp, UTR/référence bancaire.
Par PSP : registres financiers par inscription/retour/correction, mises à jour tardives des statuts.

11) Modèles UX

Mobile-first : pour mobile - App2App ; pour le desktop, le QR dynamique.
Erreurs claires : limites, délais, refus de SCA ; bouton de répétition sécurisée.
Reçu : montant, temps, 'transactionId', canal, UTR, contacts de sapport.
Fallback : offre des alternatives (carte/SEPA/autre méthode) à « expired/failed ».

12) Récurrence et mandats

MB WAY de base est un-off avec SCA. Pour les abonnements, utilisez le lien : premier paiement → e-mandate/SEPA DD/Open-Banking mandat ; conserver la limite/fréquence/notifications, écran de gestion de mandat.

13) Vertical à risque élevé (y compris iGaming)

L'accessibilité/les limites dépendent de la politique des PSP/banques 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, PIS open banking) et un routage intelligent selon les risques.

14) Architecture « MB WAY 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 (QR/App2App/P2P/NFC), « pending→success/expired », latence jusqu'à settlement.

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

1. Signez un contrat avec PSP/SIBS, sélectionnez les canaux (App2App/QR/P2P/ATM-cashout si nécessaire).
2. Implémentez 'createPayment '/' requestMoney', QR dynamique, écrans d'erreur/limites.
3. Connectez webhooks, idempotence, retraits et dedup.
4. Configurez recon (daily + full), stockage UTR/fin-références.
5. Inclure les procédures partial/full refunds et ODR dans le saphport.
6. Lancez les dashboards SLA et les alertes de conversion/latence.
7. Effectuez des tests e2e avec les banques/appareils principaux, POS/ATM (le cas échéant).

Carte de référence par limite

Per-txn/24h/7d : stocker dans un configh, vérifier avant le démarrage.
Nouveaux destinataires/merchants : seuils réduits/vitesse d'obturation.
Canaux : limites séparées pour P2P, e-commerce, POS (QR/NFC), ATM.
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 le commerce de détail - QR/NFC, pour les traductions simples - P2P par numéro.
Partagez la confirmation en ligne et le crédit final dans la logique, construisez autour de webhooks + recon et refunds partiels.
Ne « couchez » pas les montants : gardez les limites configues par les banques/canaux et mettez à jour régulièrement.
Pour les abonnements, le premier MB WAY → un mandat avec une gestion et des notifications transparentes.