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.


Resume 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!

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.