iDEALオランダ：A2A決済
1） iDEALコンテキストとポジショニング
iDEALは、オランダの非キャッシュA 2A支払い（口座間）のための国家スキームです。買い手は、発行銀行のオンラインバンク/モバイルアプリケーションを介して銀行口座から直接購入のために支払います。ストリームは、発行者リダイレクト（銀行にリダイレクト）またはdeeplink/App2Appで銀行アプリケーションを開くときに構築されます。計算は速く、商人のための手数料はカードMDRよりも低く、最終的に銀行のクレジット転送のようなものです。
主な特徴：- 発行銀行（ING、 Rabobank、 ABN AMROなど）による相互運用性。
- SCA/PSD2対応-銀行での確認（PIN/生体認証）。
- 即時承認（オンラインでのステータスの成功）と取得者/受取人銀行を通じた最終的なローン。
- 和解のためのリッチメタデータ（purchaseId/orderId、説明、参照）。
2）参加者の役割
iDEAL（スキーム）-ルール、認証、発行銀行へのルーティング。
発行者-顧客認証、支払い確認、ステータス。
Acquirer/CPSP （Payment Service Provider）-マーチャント接続、API/SDK、レポートおよび計算。
マーチャント-支払いを開始し、ステータス/資金を受け取り、リターンと和解を維持します。
3）支払の流れの選択
3.1発行者リダイレクト（クラシック）
1.チェックアウト商人→発行者ディレクトリから銀行を選択します。
2.銀行→SCA→確認にリダイレクトまたはApp2Appします。
3.'transactionId'とステータス（成功/失敗/キャンセル/オープン/期限切れ）を持つマーチャントに戻ります。
3.2 App2App/埋め込まれる
モバイルデバイスでは、商人はdeeplink/intent（より良いUX、より少ない摩擦）によって銀行アプリケーションを開きます。
埋め込み/ホスティング：プロバイダは、銀行のリスト、リダイレクト管理、エラー処理の既製ウィジェットを提供します。
3.3 iDEAL QR（オフライン/オンライン）
埋め込まれた合計および参照が付いている順序ごとの動的QR；買い手は銀行アプリのカメラをスキャンし、支払いを確認します。
静的なQR（商人のためにまれ；more for P2P/donations）-金額はユーザーが手動で入力します。
3.4繰り返し/マンデート
「first payment+e-mandance」モデル：明示的なSCA→e-manditionの作成によるiDEALの最初の書き込み（通常、合意された制限/期間内の次の書き込みオフのためのSEPA Direct Debitにつながります）。購読に適しています。
4）銀行の限界と政策
iDEALには単一の「スーパースキーム」天井がありません。クライアントのプロファイルとインターネットバンクの設定に応じて、支払者の銀行限度額（発行者）が適用されます：- トランザクションごと（操作ごとの最大）。
- Per-day/24hと毎週（金額と/または取引数）。
- 新しい受益者/新規商人-しきい値の削減および/または暴露が可能です。
- チャネル/リスクルール（モバイルとデスクトップ、速度、地理/デバイス）。
練習：番号をハードコードしないでください-銀行によって制限のディレクトリを保持し、ユーザーが理解可能なエラーを表示します「銀行による制限を超えました」代替（分割、別の方法、後で繰り返します）。
5）コミッションと経済
商人は彼の買収者/PSPに修正/低利息を支払う。カートの意味で銀行間委員会はありません。コストは低くなりますが：- プロバイダ手数料（ゲートウェイ、ウィジェット、ホストされたチェックアウト）、
- 返品/ODRのコスト、
- インシデントのサポートと調査。
6）ステータス、キャンセル、返品
トランザクションのステータス：'success'、 'open' （waiting）、 'failed'、 'cancelled'、 'expired'。
確認の前にキャンセル-クライアントから（銀行で）または時間によって（期限切れ）。
カードのように充電器-いいえ。払い戻しは、商人から支払人への新しいクレジット取引（払い戻し）、部分的な払い戻しが可能です。
返品期間はPSP/銀行によって異なります。多くの場合、銀行振込でT+0/T+1。
7）安全性とコンプライアンス
銀行側の発行銀行+デバイスバインディングおよび不正防止ポリシーのSCA。
一部の発行者の名前/IBAN表示は、誤ったダイレクトのリスクを低減します。
PSD2/GDPR： PII最小化、Webフック保護（HMAC）、監査ログ。
8）和解と報告
「transactionId」 （iDEAL）、 「purchaseId」/「orderId」、時間、発行者、最終ステータス、PSPレポートのUTR/銀行参照を保存します。
毎日のオートリコンと定期的なフルリコン（ターンオーバーの調整、リターン、調整）を設定します。
PSPレポートでは、初期注文パラメータ、ステータス、遅延更新（例："open→success/expired'）、移動を返します。
9） UXパターン
ディレクトリ→銀行ピック：プリフィルと人気/最後の選択で銀行を並べ替えます。
モバイルファースト：自動的にApp2App、フォールバック-Webリダイレクトを提供します。
再試行/回復：失敗した場合は、単純な繰り返しと代替メソッドを表示します。
Idempotency： 'orderId'+安全な繰り返しのためのidempotencyキー。
チェック：amount、 date/time、 'transactionId'、 reference、 channel （QR/App2App/Redirect）を指定します。
10）電子チケットによる定期的な書き込み
シナリオ「iDEAL first payment→mandant for future write-ofs」（通常はSEPA Direct Debit経由）。
デビットごとの制限、頻度、キャンセル権はマンデートで固定されています。
インターフェイスでは、一時停止/キャンセル/更新画面と解除前の通知があります。
11） iDEALとiGaming/高リスクのカテゴリ
いくつかの分野でiDEALが利用可能なのは、リスクポリシーと現地法に関する銀行/PSPに限定されています。
iGamingの場合、次のことを期待します。締められたチェック、制限の削減、必須のローカルコンプライアンス、透明なODR/払い戻しフロー。
代替レール（カード、SEPA、 オープンバンキングA 2A）とトラフィックセグメンテーションを計画します。
12）マーチャント統合： オプション
1.ホスティング/組み込みiDEAL チェックアウトPSP
クイックスタート、銀行のリストの自動更新、ステータスとエラー。
2.Server-to-Server+リダイレクト
柔軟なUXコントロール：独自の銀行選択ページ、QR生成、レジへの深い統合。
3.iDEAL QR
POS/オフラインの場合：合計/マーク付きの注文ごとに動的QR、和解とアンチコストに優れています。
必要なバックエンドコンポーネント：- Эндпоинты： 'createPayment'、 'queryStatus'、 'refund'、 'webhook'、 'reconcile'。
- 'orderId'によるIdempotenceとdedupeテーブル。
- HMACシグネチャ、レトライ指数、劣化に関する弾丸ポーリングを備えたWebhook。
- カタログ：銀行/限界/エラーコード；発行者によるSLAメトリクス。
13）建築スキーム「iDEALゲートウェイ」
APIレイヤー：キャッシュデスク用のREST+PSP/iDEAL APIとの統合。
イベントキュー：ステータスイベント→課金/CRM/分析。
観測可能性：銀行/チャネルによる変換メトリック（リダイレクト/App2App/QR）、「オープン→期限切れ」の共有、成功への平均遅延。
セキュリティ：保管庫の秘密、PSPのIP-allowist、リダイレクトURL保護、アンチリプレイトークン。
データ：支払/リターンレジスタ、ODRログ、チケットカード。
14）出力チェックリスト
1.iDEAL （Hosted/Embedded/App2App/QR）でPSP/acquirerを選択します。
2.「createPayment」+リダイレクト/アプリ2アプリ、銀行選択画面を実装。
3.Webフック、idempotency、タイムアウト、ステータスリプレイを有効にします。
4.リコン（毎日+フル）、アップロード、および同期外のアラートを設定します。
5.サポートの部分的な/完全な払い戻しおよびODRの規則を支えて下さい。
6.UXフォールバック（代替メソッド、繰り返し）を追加し、'transactionId'でチェックします。
7.主要銀行（iOS/Android/デスクトップ）でApp2App/QRをテストします。
8.銀行によるリミットガイドとインシデントステータスページを用意します。
リミットリファレンスカード
Per-txn/24h/7d： configに保存します。リダイレクトを開始する前に確認してください。
新しい受益者/商人：開始制限および/または遅延を削減しました。
チャネル：モバイルApp2Appでは、制限/詐欺ポリシーがWebと異なる場合があります。
チケット-制限/頻度はチケットの条件（定期的なライトオフの場合）に設定されます。
概要
オフラインのための変換App2App/Embeddedと動的QRに賭けます。
硬い量をレースしないでください：銀行の限界と行動規則の構成を維持します。
プロセスはwebhooks+recon、明確な状態および部分的な払い戻しを中心に構築されます。
サブスクリプションの場合-最初の支払いiDEAL→e-mandant；制限と通知を透過的に管理します。