MBウェイポルトガル：財布とP2P

1） MB WAYとは何ですか、そしてそれは生態系のどこに住んでいますか

MB WAYは、SIBS/Multibancoグループのレール上のポルトガルのモバイルウォレットで、即時P2P決済、オンライン購入、オフライン（QR/NFC、カードなしのATMでのキャッシュアウト）のためのユーザーのカードと銀行口座を組み合わせています。確認-MB WAY/bankアプリケーション（SCA： PIN/バイオメトリクス）で。商人のための手数料は、通常、ローカル処理のために古典的なカードMDRよりも低いです。

• カード/アカウント（デビット/クレジット）をアプリにリンクする→1つの確認で支払い。
• P2P「電話に」：番号で連絡先に転送、24/7。
• カードを入力せずにプッシュ確認でオンラインチェック。
• 小売ではQR/NFC、 ATMではMB WAYキャッシュアウト（cardless）。
• SIBS Gateway/PSPによる豊富なメタデータと安定した統合。

2）メンバーと役割

SIBS/Multibanco（スキーム/処理）：ルール、ルーティング、銀行/商人のカタログ。
銀行/カード発行者：KYC、リミット、不正防止、デビット/クレジット。
PSP/acquirer （SIBSゲートウェイなど）：マーチャント接続、SDK/API、レポート、計算。
商人：支払/照会を始め、状態を得、和解を維持します。
Payer： MB WAY/Bankアプリケーションで取引を確認します。

3）モードとユーザーシナリオ

3.1 P2P「電話ごと」

送信者は電話帳から連絡先を選択します→金額を入力→アプリケーションで確認します。
受信者はプッシュ/通知を受け取り、お金はリンクされたアカウント/カードに入金されます。

3.2 Eコマース、アプリ内

商人のチェックアウトで、ユーザーはMB WAY電話番号を入力するか、QRをスキャンします。
アプリケーションは、プッシュリクエスト→ユーザーが確認→商人がオンラインステータスを受け取ります。
モバイルアプリケーションでは、MB WAYを自己開放してApp2App/deeplinkします。

3.3 POS/オフライン

チェックアウト時（amount+orderId）またはアプリケーションを介したNFC支払い時に注文ごとに動的QR。
確認-プッシュ、領収書-商人とアプリケーションで。

3.4 キャッシュアウトATM （MBウェイリフト）

ユーザーは、アプリケーションでコード/確認を生成します→プラスチックカードなしで現金を引き出す。

3.5分割請求書/請求金

連絡先（コレクション）、参加者間の金額の自動分割にお金を要求します。

4）取引状況

'initiated'→'pending'→'success'/'failed'/'cancelled'/'expired'。
請求書/要求マネー-別々の'requested'/'expired'。

5）制限とリスクポリシー

• トランザクションごと、1日あたり/24時間、時には毎週/毎月。
• 新しい受信機/商人-しきい値、シャッタースピード、または追加の確認を減らしました。
• チャネル制限：P2P、電子商取引、POS/QR/NFC、 ATM（キャッシュアウト）。
• 速度とデバイスルール：銀行/スキーム側の不正防止。

6）コミッションと経済

商人のために、MB WAYは通常古典的なカードより安いですが、条件はPSP/関税に依存します。
追加費用：ホスト/SDK、レポート、ODR/サポート、処理'保留/期限切れ'、recon。

7）返品および紛争

カードのようなチャージバックはA2Aフローには適用されません：return-新しいクレジットトランザクション（完全/部分）。
MB WAY内でトークン化されたカードで支払いを行った場合、カードの手続きが適用されます（取得ルールに従って）。
ODR/苦情-PSP/bank；注文ログの準備、サービス/配送の確認。

8）安全性とコンプライアンス

アプリケーション内のSCA （PIN/Face/Touch）、デバイスバインディング、SIM/デバイスチェック。
PII最小化、Webフック暗号化、HMAC/nonce、リプレイ保護。
ポルトガル銀行のPSD2/GDPRおよび現地の要件の遵守。

9）マーチャントの統合

［オプション］

1.ホスト/エンベデッド（SIBS/PSP）-高速起動、プッシュ/QRをオフにします。
2.Server-to-Server+App2App/QR-ネイティブUX、ディープエラー処理、順序ごとの動的QR。
3.Pay-by-Link/Request Money-インスタントメッセンジャー/メール/SMSのリンクによるアカウント。

• API： 'createPayment'、 'requestMoney'、 'refund'、 'webhook'、 'reconcile'。
• Idempotence （orderId+key）、指数関数リトレイ、イベントのデッドアップ。
• Recon：毎日のオートリコン+定期的なフルリコン；UTR/fin参照のストレージ。
• SLAダッシュボード：変換、'保留中→成功/期限切れ'、登録までの時間。

10）和解と報告

ログ：'paymentId/transactionId'、 'orderId'、チャネル（P2P/QR/App2App/NFC）、 payer銀行、ステータス、金額/通貨、タイムスタンプ、UTR/銀行リンク。
PSPから：登録/返品/修正のための財務レジスタ、遅延ステータスの更新。

11） UXパターン

モバイルファースト：モバイル用-App2App；デスクトップ用-動的QR。
エラーのクリア：制限、タイムアウト、SCA障害；Secure Repeatボタン。
領収書：金額、時間、'transactionId'、チャネル、UTR、サポート連絡先。
Fallback： 'expired/failed'のときに代替案（map/SEPA/otherメソッド）を提案します。

12）再発およびマンデート

基本的なMB WAYはSCAとのワンオフです。サブスクリプションの場合は、バンドルを使用してください。最初の支払い→e-mandition/SEPA DD/Open-Bankingマンデート；ストア制限/頻度/通知、チケット管理画面。

13）高リスク垂直（iGamingを含む）

可用性/制限は、PSP/銀行ポリシーと現地の法律に依存します。
削減しきい値、強化されたKYC、可能な保持を期待します。
リスクのために代替レール（カード、SEPA、オープンバンキングPIS）とスマートルーティングを計画します。

14）アーキテクチャ「MB WAYゲートウェイ」

キャッシュレジスタとバックホー用のAPIレイヤー（REST/GraphQL）。
イベントキュー：ステータスイベント→課金/CRM/分析。
セキュリティ：秘密の保管庫、IP-allowlist PSP、厳格なリダイレクトURI検証、アンチリプレイトークン。
観測可能性：チャネル変換（QR/App2App/P2P/NFC）、'保留中→成功/期限切れ'、決済へのレイテンシ。

15）出力チェックリスト

1.PSP/SIBS契約に署名し、チャンネルを選択します（必要に応じてApp2App/QR/P2P/ATM-cashout）。
2.'createPayment'/'requestMoney'、動的QR、エラー/制限画面を実装します。
3.Webhook、 idempotency、 retrai、 dedupを接続します。
4.recon（毎日+フル）、UTR/fin参照ストレージを設定します。
5.サポートで部分払い戻しとODR手続きを有効にします。
6.SLAダッシュボードと変換/レイテンシーアラートを実行します。
7.メインバンク/デバイス、POS/ATM（該当する場合）でe2eテストを実行します。

リミットリファレンスカード

Per-txn/24h/7d： configに保存し、起動前に確認します。
新しい受信者/商人：しきい値/シャッター速度の低下。
チャネル：P2P、電子商取引、POS （QR/NFC）、 ATMのための別の限界。
速度/リスク：銀行のアンチフラウドは、操作を緩やかに偏向/遅くすることができます。

履歴書のサマリー

オンライン-App2App+動的QR、小売り-QR/NFC、簡単な転送-P2P番号で。
別のオンライン確認とロジックの最終クレジット、webhooks+reconと部分的な払い戻しの周りに構築。
量を"ひもで締めないで下さい：銀行/チャネルによって限界構成を保ち、規則的に更新して下さい。
サブスクリプションの場合、最初のMB WAYバンドル→透明な管理と通知を持つチケット。