MB WAY Portugal: Brieftasche und P2P

1) Was ist MB WAY und wo lebt es im Ökosystem?

MB WAY ist eine portugiesische mobile Geldbörse auf den Schienen der SIBS/Multibanco-Gruppe, die Karten und Bankkonten des Benutzers für sofortige P2P-Zahlungen, Online-Einkäufe und Offline-Zahlungen (QR/NFC, Cash-out an Geldautomaten ohne Karte) kombiniert. Die Bestätigung erfolgt in der MB WAY/Bank App (SCA: PIN/Biometrie). Die Provisionen für den Händler liegen durch die lokale Bearbeitung meist unter dem klassischen Kartenkartenmdr.

• Verknüpfung von Karten/Konten (Debit/Credit) mit der App → Zahlung mit einer Bestätigung.
• P2P „am Telefon“: Transfer zum Kontakt per Nummer, 24/7.
• Online-Check-out mit Push-Bestätigung ohne Karteneingabe.
• QR/NFC im Handel und MB WAY Cash-out im ATM (cardless).
• Reichhaltige Metadaten und stabile Integration über SIBS Gateway/PSP.

2) Teilnehmer und Rollen

SIBS/Multibanco (Schema/Verarbeitung): Regeln, Routing, Bank-/Merchant-Kataloge.
Bank/Kartenaussteller: KYC, Limits, Betrugsbekämpfung, Abbuchung/Gutschrift.
PSP/Acquirer (SIBS Gateway usw.): Merchant-Verbindung, SDK/API, Berichte, Berechnungen.
Merchant: initiiert eine Zahlung/Anfrage, erhält Status und führt einen Abgleich durch.
Zahler: bestätigt Transaktionen in der MB WAY/Bank-App.

3) Modi und benutzerdefinierte Skripte

3. 1 P2P „pro Telefon“

Der Absender wählt den Kontakt aus dem Telefonbuch aus → gibt den Betrag ein → bestätigt ihn in der App.
Der Empfänger erhält einen Push/Benachrichtigung, das Geld wird dem gebundenen Konto/der Karte gutgeschrieben.

3. 2 Online-Check-out (E-Commerce, In-App)

An der Kasse des Händlers gibt der Nutzer die MB WAY Telefonnummer ein oder scannt den QR.
Die App sendet eine Push-Anfrage → der Benutzer bestätigt → der Merchant den Online-Status erhält.
In mobilen Anwendungen - App2App/deeplink mit automatischer Öffnung MB WAY.

3. 3 POS/offline

Dynamisches QR per Bestellung an der Kasse (Betrag + Bestellnummer) oder NFC-Zahlung per App.
Bestätigung - Pusch, Quittung - beim Händler und in der App.

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

Der Nutzer generiert einen Code/Bestätigung in der App → hebt Bargeld ohne Plastikkarte ab.

3. 5 Split Bill / Request Money

Geldanforderung an Kontakte (Kollekte), automatische Aufteilung der Beträge zwischen den Teilnehmern.

4) Status der Operationen

„initiated“ → „pending“ → „success “/„ failed “/„ canceled “/„ expired“.
Für Rechnungen/Request Money - separate' requested '/' expired'.

5) Grenzwerte und Risikopolitik

• Per-Transaktion, per-day/24h, manchmal wöchentlich/monatlich.
• Neuer Empfänger/Merchant - reduzierte Schwellenwerte, Verschlusszeit oder zusätzliche Bestätigung.
• Kanalgrenzen: P2P, E-Commerce, POS/QR/NFC, ATM (Cash-out).
• Velocity und Device-Regeln: Betrugsbekämpfung auf der Bank-/Schemaseite.

6) Kommissionen und Wirtschaft

Für einen Händler ist MB WAY in der Regel billiger als klassische Karten, aber die Bedingungen hängen vom PSP/Tarif ab.
Dop. Kosten: hosted/SDK, Berichte, ODR/Support, Verarbeitung 'pending/expired', recon.

7) Retouren und Dispute

Das Chargeback wie in den Karten gilt nicht für A2A-Streams: Return ist eine neue Kredittransaktion (full/partial).
Wenn die Zahlung mit einer tokenisierten Karte innerhalb von MB WAY erfolgte, gelten die Kartenverfahren (gemäß den Acquiring-Regeln).
ODR/Beschwerden - über PSP/Bank; Vorbereitung der Bestellprotokolle, Bestätigung der Leistungserbringung/Lieferung.

8) Sicherheit und Compliance

SCA (PIN/Face/Touch) in der App, Gerätebindung, SIM/Geräteprüfung.
PII-Minimierung, Verschlüsselung von Web-Hooks, HMAC/Nonce, Replay-Schutz.
Einhaltung der PSD2/GDPR und lokalen Anforderungen der Bank von Portugal.

9) Merchant-Integration

Varianten

1. Hosted/Embedded (SIBS/PSP) - Schnellstart, Push/QR aus der Box.
2. Server-to-Server + App2App/QR - eigene UX, tiefe Fehlerbehandlung, dynamisches QR per-order.
3. Pay-by-Link/Geld anfordern - Konto über einen Link in Messenger/E-Mail/SMS.

• API: `createPayment`, `requestMoney`, `refund`, `webhook`, `reconcile`.
• Idempotenz (orderId + key), exponentielle Retrays, Dedup von Ereignissen.
• Recon: täglicher Auto-Recon + periodischer Full-Recon; Speicherung von UTR/fin-Referenzen.
• SLA Dashboards: Conversion, 'pending→success/expired', Zeit bis zur Einschreibung.

10) Abstimmung und Berichterstattung

Loggen: 'paymentId/transactionId', 'orderId', Channel (P2P/QR/App2App/NFC), Zahlerbank, Status, Betrag/Währung, Timestamp, UTR/Banking Link.
Von PSP: Fin-Register für Einschreibungen/Retouren/Korrekturen, späte Statusaktualisierungen.

11) UX-Muster

Mobile-first: für Mobile - App2App; für Desktop - Dynamic QR.
Klare Fehler: Limits, Timeouts, SCA-Ausfall; Taste für sichere Wiederholung.
Quittung: Betrag, Zeit, 'transactionId', Kanal, UTR, Saport Kontakte.
Fallback: Vorschlag von Alternativen (Karte/SEPA/andere Methode) bei 'expired/failed'.

12) Recurrent und Mandate

Basis MB WAY - Ein-Aus mit SCA. Für Abonnements verwenden Sie ein Bündel: die erste Zahlung → e-mandate/SEPA DD/Open-Banking-Mandat; Speichern Sie Limit/Häufigkeit/Benachrichtigungen, Mandatsverwaltung Bildschirm.

13) Hochrisikovertikale (einschließlich iGaming)

Die Verfügbarkeit/Grenzen hängen von den Richtlinien der PSP/Banken und dem lokalen Recht ab.
Erwarten Sie reduzierte Schwellen, verstärkt durch KYC, mögliche Halter.
Planen Sie alternative Schienen (Karten, SEPA, Open-Banking-PIS) und Smart-Routing für das Risiko.

14) Architektur „MB WAY Gateway“

API-Layer (REST/GraphQL) für Kasse und Backophis.
Ereigniswarteschlangen: Status-Events → Abrechnung/CRM/Analysen.
Sicherheit: Tresor für Geheimnisse, IP-allowlist PSP, strikte Validierung von redirect-URIs, Anti-Replay-Token.
Observability: Konvertierung über Kanäle (QR/App2App/P2P/NFC), 'pending→success/expired', Latenz bis zur Einstellung.

15) Checkliste Ausgabe in prod

1. Unterzeichnen Sie einen Vertrag mit PSP/SIBS, wählen Sie Kanäle (App2App/QR/P2P/ATM-cashout wenn nötig).
2. Implementieren Sie' createPayment '/' requestMoney', dynamische QR, Fehler/Limits Bildschirme.
3. Verbinden Sie Webhooks, Idempotenz, Retrays und Dedup.
4. Richten Sie Recon (täglich + voll) ein, speichern Sie UTR/Fin-Referenzen.
5. Aktivieren Sie partielle/vollständige Refund- und ODR-Prozeduren in Sapport.
6. Führen Sie SLA-Dashboards und Konversions-/Latenzalarme aus.
7. Führen Sie e2e-Tests mit den wichtigsten Banken/Geräten, POS/ATM (falls relevant) durch.

Landmark-Karte nach Limits

Per-txn/24h/7d: in config aufbewahren, vor dem Start prüfen.
Neue Empfänger/Händler: reduzierte Schwellen/Verschlusszeiten.
Kanäle: separate Limits für P2P, E-Commerce, POS (QR/NFC), ATM.
Velocity/Risiko: Die Betrugsbekämpfung der Bank kann Transaktionen sanft ablehnen/verlangsamen.

Zusammenfassung

Für Online - App2App + Dynamic QR, für Retail - QR/NFC, für einfache Transfers - P2P per Nummer.
Trennen Sie die Online-Bestätigung und die endgültige Gutschrift in der Logik, bauen Sie um webhooks + recon und partial refunds.
Nicht „Miese“ Summen: Halten Sie configy Grenzen auf Banken/Kanäle und regelmäßig aktualisieren.
Für Abonnements - Bündel erste MB WAY → Mandat mit transparenter Verwaltung und Benachrichtigungen.