GH GambleHub

MB WAY Portugal: purse and P2P

1) What is MB WAY and where does it live in the ecosystem

MB WAY is a Portuguese mobile wallet on the rails of the SIBS/Multibanco group, combining cards and bank accounts of the user for instant P2P payments, online purchases and offline (QR/NFC, cash-out at ATMs without a card). Confirmation - in the MB WAY/bank application (SCA: PIN/biometrics). Commissions for merchant are usually lower than the classic card MDR due to local processing.

Key properties:
  • Linking cards/accounts (debit/credit) to the application → payment in one confirmation.
  • P2P "to phone": transfer to contact by number, 24/7.
  • Online check with push confirmation without entering cards.
  • QR/NFC in retail and MB WAY Cash-out in ATM (cardless).
  • Rich metadata and stable integration through SIBS Gateway/PSP.

2) Members and roles

SIBS/Multibanco (scheme/processing): rules, routing, catalogs of banks/merchants.
Bank/card issuer: KYC, limits, anti-fraud, debit/credit.
PSP/acquirer (SIBS Gateway, etc.): merchant connection, SDK/API, reports, calculations.
Merchant: Initiates payment/inquiry, obtains statuses and maintains reconciliation.
Payer: Confirms transactions in the MB WAY/Bank application.

3) Modes and user scenarios

3. 1 P2P "per phone"

The sender selects a contact from the phone book → enters the amount → confirms in the application.
The recipient receives a push/notification, the money is credited to the linked account/card.

3. 2 E-commerce, in-app

At the merchant's checkout, the user enters the MB WAY phone number or scans the QR.
The application sends a push request → the user confirms → the merchant receives an online status.
In mobile applications - App2App/deeplink with self-opening MB WAY.

3. 3 POS/offline

Dynamic QR per-order at the checkout (amount + orderId) or NFC payment through the application.
Confirmation - push, receipt - at the merchant and in the application.

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

The user generates a code/confirms in the application → withdraws cash without a plastic card.

3. 5 Split Bill / Request Money

Request money to contacts (collections), automatic split of the amount between participants.

4) Transaction statuses

'initiated '→' pending '→' success '/' failed '/' cancelled '/' expired '.
For invoices/Request Money - separate 'requested '/' expired'.

5) Limits and risk policy

Limits are set by the bank/issuer and may differ by channel and profile:
  • Per-transaction, per-day/24h, sometimes weekly/monthly.
  • New receiver/merchant - reduced thresholds, shutter speed or additional confirmation.
  • Channel limits: P2P, e-commerce, POS/QR/NFC, ATM (cash-out).
  • Velocity and device rules: anti-fraud on the bank/scheme side.
💡 Practice: Don't hardcode numbers. Keep a directory of limits by banks/channels, update; in UX, show the reason for refusal ("bank/channel limit") and alternatives (split check, other method).

6) Commissions and Economics

For merchant, MB WAY is usually cheaper than classic cards, but conditions depend on PSP/tariff.
Add. costs: hosted/SDK, reports, ODR/support, processing 'pending/expired', recon.

7) Returns and disputes

Chargeback as in cards does not apply to A2A flows: return - a new credit transaction (full/partial).
If the payment was made with a tokenized card inside MB WAY, card procedures are applied (according to the acquiring rules).
ODR/complaints - via PSP/bank; prepare order logs, confirmation of service/delivery.

8) Safety and compliance

SCA (PIN/Face/Touch) in the application, device binding, SIM/device check.
PII minimization, web hook encryption, HMAC/nonce, replay protection.
Compliance with PSD2/GDPR and local requirements of the Bank of Portugal.

9) Merchant integration

Options

1. Hosted/Embedded (SIBS/PSP) - fast start, push/QR out of the box.
2. Server-to-Server + App2App/QR - native UX, deep error processing, dynamic QR per-order.
3. Pay-by-Link/Request Money - account by link in instant messengers/email/SMS.

Required backend components:
  • API: `createPayment`, `requestMoney`, `refund`, `webhook`, `reconcile`.
  • Idempotence (orderId + key), exponential retrays, event dedup.
  • Recon: daily auto-recon + periodic full-recon; storage of UTR/fin references.
  • SLA dashboards: conversion, 'pending→success/expired', time to enrollment.

10) Reconciliation and Reporting

Log: 'paymentId/transactionId', 'orderId', channel (P2P/QR/App2App/NFC), payer bank, status, amount/currency, timestamp, UTR/bank link.
From PSP: financial registers for enrollments/returns/corrections, late status updates.

11) UX patterns

Mobile-first: for mobile - App2App; for desktop - dynamic QR.
Clear errors: limits, timeouts, SCA failure; Secure Repeat button.
Receipt: amount, time, 'transactionId', channel, UTR, support contacts.
Fallback: suggest alternatives (map/SEPA/other method) when 'expired/failed'.

12) Recurrence and mandates

The basic MB WAY is one-off with SCA. For subscriptions, use a bundle: first payment → e-mandate/SEPA DD/Open-Banking mandate; store limit/frequency/notifications, ticket management screen.

13) High-risk verticals (including iGaming)

Availability/limits depend on PSP/bank policy and local law.
Expect reduced thresholds, enhanced KYC, possible holds.
Plan alternative rails (cards, SEPA, open-banking PIS) and smart-routing for risk.

14) Architecture "MB WAY Gateway"

API layer (REST/GraphQL) for cash register and backhoe.
Event queues: status events → billing/CRM/analytics.
Security: vault for secrets, IP-allowlist PSP, strict redirect-URI validation, anti-replay tokens.
Observability: channel conversion (QR/App2App/P2P/NFC), 'pending→success/expired', latency to settlement.

15) Output checklist

1. Sign PSP/SIBS contract, select channels (App2App/QR/P2P/ATM-cashout if necessary).
2. Implement 'createPayment '/' requestMoney', dynamic QR, error/limit screens.
3. Connect webhooks, idempotency, retrai and dedup.
4. Set up recon (daily + full), UTR/fin references storage.
5. Enable partial/full refunds and ODR procedures in the support.
6. Run SLA dashboards and conversion/latency alerts.
7. Perform e2e tests with main banks/devices, POS/ATM (if relevant).

Limit Reference Card

💡 Actual thresholds are set by banks/PSPs and differ by channel.

Per-txn/24h/7d: store in config, check before starting.
New recipients/merchants: reduced thresholds/shutter speeds.
Channels: separate limits for P2P, e-commerce, POS (QR/NFC), ATM.
Velocity/risk: Bank antifraud can gently deflect/slow down operations.

Summary

For online - App2App + dynamic QR, for retail - QR/NFC, for simple transfers - P2P by number.
Separate online confirmation and final credit in logic, build around webhooks + recon and partial refunds.
Do not "lace" the amounts: keep limit configs by bank/channel and update regularly.
For subscriptions, the first MB WAY bundle → a ticket with transparent management and notifications.

Contact

Get in Touch

Reach out with any questions or support needs.We are always ready to help!

Telegram
@Gamble_GC
Start Integration

Email is required. Telegram or WhatsApp — optional.

Your Name optional
Email optional
Subject optional
Message optional
Telegram optional
@
If you include Telegram — we will reply there as well, in addition to Email.
WhatsApp optional
Format: +country code and number (e.g., +380XXXXXXXXX).

By clicking this button, you agree to data processing.