GH GambleHub

Multibanco Portugal : bons et refs

1) Contexte et positionnement Multibanco

Multibanco (MB) est l'infrastructure nationale de paiement du Portugal, gérée par SIBS, qui regroupe les guichets automatiques, les banques en ligne et les services de paiement locaux. Pour le commerce électronique/comptes, deux des outils les plus utiles :
  • MB References (Pagamento de Serviços/Compras) : détails de paiement du type Entidade + Referencia + Valor pour le paiement des factures dans ATM ou homebanking.
  • MB Voucher/MB Cash at ATM : scénario « bon » - l'acheteur reçoit un code/instruction et paie dans ATM ou dans une banque en ligne ; le merchant reçoit une confirmation en ligne de PSP et un crédit bancaire subséquent.

Caractéristiques : frod très bas, finalité comme un virement bancaire (pas de charjback), commodité pour les utilisateurs habitués à payer via ATM/homebanking.

2) Termes et format des détails

Entidade (Entity/Service Code) est le code du destinataire dans le système SIBS (généralement 5 chiffres).
Referência (Reference) : Identificateur de compte/commande unique à 9 chiffres.
Valor (Amount) est le montant à payer (fixe) ou « ouvert » (si configuré pour PSP/merchant).

💡 Pratique : pour l'e-commerce, utilisez un Valor fixe et une durée de validité (expiré) - ce qui facilite le rapprochement et réduit les erreurs.

3) Membres

SIBS/Multibanco (circuit/pull) - routage et compensation des paiements MB.
Banque du payeur - fournit ATM/homebanking, applique des limites/antifrod.
PSP/Acquirer - émet des références/bons via API/panneau, webhooks et registres, effectue des calculs.
Merchant - génère un compte (Entity/Reference/Amount), obtient des statuts/crédits, effectue des retours.

4) Flux et canaux

4. 1 MB Références (factures via ATM/homebanking)

1. Merchant/PSP crée Entidade + Referencia + Valor + Expiry et les affiche sur checkout (et/ou envoie par e-mail/SMS).
2. Le client paie à ATM ou à sa banque en ligne → confirme la transaction.
3. Le PSP transmet au merchant le statut en ligne (paid/pending/expired, etc.), puis le mouvement dans les registres finaux (settlement).

Options :
  • Référence dynamique per-order (recommandé).
  • Référence statique (pour les donats/portefeuilles) - conduit plus souvent à un rapprochement complexe, utilisez soigneusement.

4. 2 MB Voucher (cash at ATM / pay-code)

Le merchant via PSP génère un « quasi-bon »/code de paiement (en fait, une référence courte).
Le client va à ATM ou homebanking et paie par code → PSP rapporte le succès en ligne.
Souvent utilisé dans les scénarios de risque élevé/cash et pour les clients sans carte.

4. 3 Paiement par MB WAY pour la facture MB

Dans certains PSP, un flow est disponible : le client paie le MB-Reference émis via le MB WAY (portefeuille). Cela accélère la confirmation et augmente la conversion sur mobile.

5) Statuts et calculs

Statuts en ligne (les PSP peuvent avoir un nom différent) :
  • `created` → `pending` → `paid` / `expired` / `canceled` / `failed`.

Settlement : crédit bancaire T + 0/T + 1 (dépendant des guichets bancaires/PSP). Même avec une confirmation instantanée en ligne dans la comptabilité, comptez sur les registres quotidiens.

Paiements partiels : par défaut, les paiements sont interdits (pour Valor fixe). La « somme ouverte » permet des parties, mais cela complique le rapprochement - n'incluez que consciemment.

6) Limites et politiques de risque

Il n'y a pas de plafond « schéma » unique - les paramètres de la banque du payeur et de la PSP sont en vigueur :
  • Per-transaction / per-day/24h; parfois weekly/monthly.
  • Des seuils plus stricts pour les nouveaux bénéficiaires/merchants.
  • Différences de canal : ATM vs homebanking ; certaines banques ont des fenêtres/seuils différents.
  • Velocity/device/géo-signaux côté banque/PSP.
💡 Pratique : ne hardcodez pas les montants. Entrez le guide des limites par banque/canal, mettez-le à jour, et dans l'IU, montrez la raison explicite du refus (« limite banque/canal »).

7) Économie et commissions

Le coût de réception est inférieur à la carte MDR typique ; conditions - votre PSP.
Tenez compte des frais de facturation, de traitement 'expired/pending', de sapport et de recon.

8) Retours et disputes

Chargeback (comme dans les cartes) est absent.
Le retour est effectué comme une nouvelle opération de crédit (généralement SEPA Credit Transfer) sur l'IBAN du client ou via le portefeuille MB WAY (si convenu).
Soutenir les partenaires partiels dans le bureau du bec ; gardez le ligament 'refund↔original référence'.

9) Sécurité et conformité

La preuve de paiement a lieu dans la banque du payeur (ATM/online-banking) → faible frod.
Minimisation GDPR/PII : ne stockez que les attributs nécessaires (Entity/Ref/Amount, masques client).
HMAC/nonce, protection contre le replay, dedup d'événement, journal d'audit.
Tenez compte des exigences de Banco de Portugal et des conditions contractuelles de SIBS/PSP.

10) Rapprochement et rapports (recon)

Loger pour chaque paiement :
  • « entity » (Entidade), « reference » (9-digit), « amount » (valor), « orderId », « status », « paidAt », « channel » (ATM/homebanking/MB WAY), « pspTxnID », référence bancaire/UTR des registres.
  • Quotidien : auto-recon par les registres PSP/SIBS (crédits/retours/corrections) + récurrents full-recon.
  • « Il y a un succès en ligne, pas d'entrée dans le registre », « double paiement d'un Ref », « montant erroné ».

11) modèles UX (que montrer à l'utilisateur)

Grands champs : Entidade/Referencia/Valor + dedline (expiry) et minuteur.
Copier les boutons pour chaque champ ; QR avec un ensemble de détails cousus (si prend en charge votre PSP).
Instructions « Comment payer en ATM/banque en ligne » avec 3-4 étapes.
Statut de la commande « En attente de paiement » et mise à jour en arrière-plan. Pour 'expired', « créer une nouvelle référence » en un clic.
Après confirmation : chèque avec 'entity', 'reference', 'paidAt', 'UTR'et les contacts du Sapport.

12) Intégration du merchant

Options

1. Hosted/Embedded chez PSP - démarrage rapide, auto-génération Références, webhooks et déchargement.
2. Server-to-Server est votre propre checkout/facture, référentiel dynamique per-order, date d'expiration personnalisée.
3. Pay-by-Link - envoyer un lien avec les détails par email/SMS/messagers.

Backend minimum obligatoire :
  • API: `createReference` (entity/ref/amount/expiry), `cancelReference`, `refund`, `webhook`, `reconcile`.
  • Idempotentialité (par 'orderId'), retraits exponentiels pour les statuts, dedupe des huks web entrants.
  • Catalogues : banques/limites, codes d'erreur, métriques SLA (ATM vs homebanking), carte d'expiration.

13) MB WAY et abonnements

Références/bons de base MB - un-off avec confirmation auprès de la banque.
Pour les débits récurrents, utilisez le lien : premier paiement → e-mandate/SEPA Direct Debit ou les mandats MB WAY (si disponibles dans le PSP), avec des limites et des notifications.

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

Multibanco est souvent appliqué, mais les conditions/limites dépendent des PSP/banques et du droit local.
Attendez-vous à des seuils réduits, KYC élargi et hold's possibles.
Prévoyez des rails alternatifs (cartes, MB WAY, SEPA, autres PIS) et un routage intelligent.

15) Architecture « Multibanco Gateway »

Couche API (REST/GraphQL) pour la caisse/le service de facturation.
Files d'attente d'événements : États-participants → facturation/CRM/analyse.
Sécurité : vault pour les secrets, IP-allowlist PSP, validation stricte callback-URL, anti-replay.
Observability : conversion 'created→paid', part 'expired', temps moyen avant paiement, ATM vs homebanking, SLA par web hooks/registres.

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

1. Branchez le PSP avec MB References/Voucher ; s'entendre sur le calendrier et le format des registres.
2. Implémentez 'createReference' (dynamique, avec expiry) et les pages d'instructions (ATM/homebanking).
3. Connectez webhooks, idempotence, retraits, dedup.
4. Configurez daily auto-recon + full-recon, stockage UTR et audit.
5. Inclure partial/full refunds (SEPA/MB WAY), règlements ODR.
6. Construisez des dashboards SLA et des alertes par 'expired', des dissynchrones, des erreurs de montants.
7. Lancez les tests e2e ATM/homebanking auprès des top banks, les timings Web et les cas extrêmes (ref expiré, double paiement).

Carte de repères

💡 Les seuils et les délais sont ceux de la banque/PSP ; ne les fixez pas rigidement dans le code.

Статусы: `created/pending/paid/expired/canceled/failed`.
Settlement : Plus souvent T + 0/T + 1.
Paiements partiels : pas par défaut (pour un montant fixe).
Retour : SEPA SCT/portefeuille MB WAY en tant que nouvelle opération de crédit.
Récurrence : via e-mandate/SEPA DD (premier paiement → mandat).

Résumé

Pour les factures/paiement différé, utilisez MB References avec dynamique ref et expiry ; pour l'audience cash/ATM - MB Voucher.
Construisez le processus autour des registres SIBS, du rapprochement clair et des déclarations gérables (SCT/MB WAY).
Gardez les limites configues sur les banques/canaux, surveillez 'expired' et les délais de confirmation.
Pour les abonnements - le premier MB mandat → (SEPA/MB WAY) avec gestion transparente et notifications.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Telegram
@Gamble_GC
Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.