GH GambleHub

MB WAY Portogallo: portafoglio e P2P

1) Cos'è MB WAY e dove vive nell'ecosistema

MB WAY - portafoglio mobile portoghese sui binari del gruppo SIBS/Multibanco, che unisce carte e conti bancari dell'utente per pagamenti istantanei P2P, acquisti online e offline (QR/NFC, cash-out nei bancomat senza carta). La conferma è nell'applicazione MB WAY/banca (SCA: PIN/biometria). Le commissioni per il Merchant sono generalmente inferiori alle classiche MDR cartucce grazie all'elaborazione locale.

Proprietà chiave:
  • L'associazione di carte/conti (debit/credit) all'applicazione → il pagamento con una sola conferma.
  • P2P «al telefono»: traduce il contatto al numero 24/7.
  • Checkout online con conferma push senza immissione di carte.
  • QR/NFC in presa e MB WAY Cash-out in ATM (cardless).
  • Metadati ricchi e integrazione stabile attraverso SIBS Gateway/PSP.

2) Membri e ruoli

SIBS/Multibanco (schema/processing): regole, routing, cataloghi di banche/merchant.
Banca/emittente carta: KYC, limiti, antifrode, prelievo/iscrizione.
PSP/Equyer (SIBS Gateway, ecc.) - Connessione merchant, SDK/API, report, calcoli.
Merchant: avvia un pagamento/richiesta, riceve gli stati e controlla.
Pagatore: conferma le transazioni in MB WAY/Bank.

3) Modalità e script personalizzati

3. 1 P2P «per telefono»

Il mittente seleziona il contatto dalla rubrica telefonica, inserisce l'importo e lo conferma nell'applicazione.
Il destinatario riceve un pass/notifica, il denaro viene depositato su un conto/carta collegato.

3. 2 Checkout online (e-commerce, in-app)

Nella cassetta del Merchant, l'utente immette il numero di telefono MB WAY o scansione QR.
L'applicazione invia una richiesta push. L'utente conferma che il Merchant ottiene lo stato online.
Le applicazioni mobili includono App2App/deeplink con MB WAY.

3. 3 POS/offline

QR dinamico per-order su cassa (importo + orderId) o pagamento NFC tramite applicazione.
La conferma è in penna, la ricevuta è nel Merchant e nell'app.

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

L'utente genera il codice/conferma nell'applicazione → preleva contanti senza carta di plastica.

3. 5 Split Bill / Request Money

Richiedi denaro ai contatti (collezioni), invia automaticamente le somme tra i partecipanti.

4) Stato delle operazioni

«iniziated» «pending» (in attesa della conferma/risposta di rete) «success »/« failed »/« canceled »/« expired».
Per le fatture/Richiest Money, le singole'richiested '/' expired '.

5) Limiti e politica di rischio

I limiti sono definiti dalla banca/emittente e possono variare per canale e profilo:
  • Per-trasmissione, per-day/24h, a volte week/monthly.
  • Nuovo destinatario/merchant - soglia ridotta, estrazione o conferma.
  • Limiti di canale: P2P, e-commerce, POS/QR/NFC, ATM (cash-out).
  • Velocity e regole device: antifrode sul lato banca/schema.
💡 Pratica: Non usare i numeri. Manuale dei limiti per banche/canali, aggiornare; in UX mostra il motivo del rifiuto («limite di banca/canale») e delle alternative (dividere l'assegno, altro metodo).

6) Commissioni ed economia

Per MB MB WAY di solito è meno costoso di carte classiche, ma le condizioni dipendono da PSP/tariffa.
Dop. costi: hosted/SDK, report, ODR/supporto, elaborazione «pending/expired», recon.

7) Restituzioni e display

Marceback, come nelle mappe, non si applica ai flussi A2A: restituzione - nuova operazione di credito (full/partial).
Se il pagamento è stato effettuato con una carta tornizzata all'interno di MB WAY, vengono applicate le procedure di carta (secondo le regole dell'Equairing).
ODR/reclamo - tramite PSP/banca; preparare i fogli d'ordine, confermare la fornitura del servizio/consegna.

8) Sicurezza e conformità

SCA (PIN/Face/Touch) nell'applicazione, device binding, verifica SIM/dispositivo.
Riduzioni PII, crittografia del web hook, HMAC/nonce, protezione contro replay.
Conformità con PSD2/GDPR e requisiti locali della Banca del Portogallo.

9) Integrazione del merchant

Opzioni

1. Hosted/Embedded (SIBS/PSP) - partenza rapida, push/QR dalla scatola.
2. Server-to-Server + App2App/QR - Personale UX, elaborazione profonda degli errori, QR dinamico per-order.
3. Pay-by-Link/Richiest Money - Conto sul link di messaggistica/email/SMS.

Componenti di backend obbligatori:
  • API: `createPayment`, `requestMoney`, `refund`, `webhook`, `reconcile`.
  • Idampotenza (orderId + chiave), retrai esponenziali, deducibilità degli eventi.
  • Recon: daily auto-recon + full-recon periodico; memorizzazione delle istruzioni UTR/fine.
  • Dashboard SLA, conversione, pending→success/expired, tempo di iscrizione.

10) Accoppiamento e reporting

Logica «paymentId/transactionId», «orderId», canale (P2P/QR/App2App/NFC), banca pagante, stato, somma/valuta, timestamp, UTR/link bancario.
Da PSP: registri finiti per iscrizioni/rimborsi/correzioni, aggiornamenti di stato avanzati.

11) pattern UX

Mobile-first: per mobile - App2App; QR dinamico per il desctop.
Errori chiari: limiti, timeout, guasto SCA; Pulsante ripetizione sicura.
Ricevuta: importo, ora, transactionId, canale, UTR, contatti di zapport.
Fallback offre alternative (scheda/SEPA/altro metodo) a «expired/failed».

12) Recurrent e mandati

MB WAY base - one-off con SCA. Le sottoscrizioni utilizzano il primo pagamento e-mandate/SEPA DD/Open-Banking mandato; memorizzare il limite, la frequenza/notifica, la schermata di gestione del mandato.

13) High-risk verticale (compreso il iGaming)

Disponibilità/limiti dipendono dalla politica PSP/banche e dal diritto locale.
Aspettate le soglie ridotte, il KYC rinforzato, le possibili hold's.
Pianificare binari alternativi (mappe, SEPA, open banking PIS) e smart-routing per il rischio.

14) Architettura «MB WAY Gateway»

Uno strato API (REST/GraphQL) per la cassa e il becofice.
Le code di eventi sono States-Ivent-Billing/CRM/Analista.
Sicurezza: vault per i segreti, IP-allowlist PSP, convalida rigorosa redict-URI, token anti-replay.
Osservabilità: conversione via canale (QR/App2App/P2P/NFC), «pending→success/expired», latitanza a settlement.

15) Assegno foglio di output

1. Firmare con PSP/SIBS, selezionare i canali (App2App/QR/P2P/ATM-cashout se necessario).
2. Implementare «createPayment »/« requestMoney», QR dinamico, schermate di errore/limiti.
3. Collegare webhooks, idampotenza, retrai e deadup.
4. Configura il recon (daily + full), memorizza le istruzioni UTR/fine.
5. Attivare le procedure partial/full refunds e ODR nello zappino.
6. Avvia i dashboard SLA e gli alert di conversione/latenza.
7. Eseguire test e2e con le principali banche/dispositivi, POS/ATM (se rilevante).


Scheda di riferimento dei limiti

💡 Le soglie reali vengono definite da banche/PSP e differite attraverso i canali.

Per-txn/24h/7d - Memorizza in un configure, controlla prima dell'avvio.
Nuovi destinatari/merchant: soglie/estrazione ridotte.
Canali: limiti separati per P2P, e-commerce, POS (QR/NFC), ATM.
Velocity/Risk - L'antifrode della banca può respingere e rallentare le operazioni.


Curriculum

Per la rete, App2App + QR dinamico, QR/NFC per la presa, P2P per la traduzione semplice.
Condividi la conferma online e il credito finale in una logica, costruisci intorno a webhooks + recon e partial refunds.
Non incanalare gli importi: mantenere i limiti di configura per banche/canali e aggiornare regolarmente.
Per le sottoscrizioni, il primo MB WAY → un mandato con controllo trasparente e notifiche.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.