iDEAL荷蘭：A2A付款

1） iDEAL的上下文和定位

iDEAL是荷蘭的國家非現金A2A付款（帳戶到帳戶）計劃。買方通過互聯網銀行/發行銀行的移動應用程序直接從其銀行帳戶支付購買費用。該線程建立在issuer-redirect（重定向到銀行）或通過deeplink/App2App打開銀行應用程序上。結算速度快，買家傭金低於卡MDR，最終是銀行信用轉移。

• 通過發行銀行（ING，Rabobank，ABN AMRO等）進行互操作性。
• SCA/PSD2合規性-銀行確認（PIN/生物識別法）。
• 即時授權（在線狀態成功）和通過收款人/收款人銀行的最終貸款。
• 用於核對的豐富元數據（purchaseId/orderId,說明,參考）。

2）參與者的角色

iDEAL（電路）-規則，認證，路由到發行銀行。
Issuer（付款人銀行）-客戶身份驗證、付款確認、狀態。
Acquirer/CPSP（付款服務提供商）-商號連接、API/SDK、報告和計算。
Merchant-啟動付款,獲取狀態/資金,維護退款和對賬。

3）付款流選項

3.1 Issuer-redirect (classic)

1.Checkout merchant →從Issuer Directory中選擇銀行。
2.Redirect或App2App銀行→ SCA →確認。
3.帶有「transactionId」和狀態（成功/失敗/canceled/open/expired）的商品返回。

3.2 App2App / Embedded

在移動設備上，商人通過deeplink/intent打開銀行應用程序（優於UX，摩擦更少）。
Embedded/Hosted：提供商提供現成的銀行列表小部件、重新引導管理、錯誤處理。

3.3 iDEAL QR（離線/在線）

動態QR每順序，內置和參考值；買家用相機掃描銀行應用程序並確認付款。
靜態QR（很少用於商人；P2P/donats的更多）-用戶手動輸入金額。

3.4 Recurring/mandates

「第一筆付款+e-mandate」模型：在iDEAL下首次註銷，帶有明確的SCA →創建電子授權（通常導致SEPA Direct Debit在商定的限制/期內進行以下註銷）。適合訂閱。

4）銀行的限制和政策

• 轉運操作（最多一次操作）。
• 每天/24 h和每周（交易金額和/或數量）。
• 新的受益人/新商人-可以降低閾值和/或快門速度。
• 通道/風險規則（移動vs臺式機,velocity, geo/devis）。

練習：不要硬編碼數字-保留銀行的限制目錄，並向用戶顯示一個可以理解的錯誤「超過銀行的限制」，並帶有替代方案（粉碎，其他方法，稍後重復）。

5）委員會與經濟

• 提供商費用（gateway、widget、hosted checkout）,
• ODR退款/運營成本，
• 支持和調查事件。

6）狀態、取消、退款

交易狀態：「成功」，「開放」（等待），「失敗」，「取消」，「暴露」。
在確認前取消-由客戶（在銀行）或taymout （expired）取消。
像地圖中的Charjbacks是沒有的。退款是商人向付款人（退款）的新貸款交易，部分退款是可能的。
退款期限取決於PSP/銀行；通常T+0/T+1通過銀行轉賬。

7）安全性和合規性

發行銀行的SCA+設備約束和銀行一側的反欺詐政策。
某些發行商的Name/IBAN顯示降低了誤導風險。
PSD2/GDPR：PII最小化，Web Hook保護（HMAC），審核日誌。

8）核對和報告

保留「transactionId」 （iDEAL）、「purchaseId」/「orderId」、時間、issuer、最終狀態、UTR/銀行參考來自 PSP報告。
配置每日自動記錄和定期完整記錄（周轉對賬、退貨、調整）。
在PSP報告中：原始訂單參數、狀態、後期更新（例如「open → success/expired」）、退款移動。

9） UX模式

Directory → Bank pick：按受歡迎程度/最新選擇對銀行進行預填充和排序。
移動第一：自動提供App2App，fallback-Web redirect。
Retry/Recovery：如果失敗,請顯示簡單的重復和替代方法。
Idempotency： 'orderId'+用於安全重復的冪等鍵。
支票：指定金額、日期/時間、「transactionId」、參考、通道（QR/App2App/Redirect）。

10）通過電子授權進行遞歸註銷

腳本「iDEAL首次付款→未來註銷的任務」（通常通過SEPA Direct Debit）。
任務規定了per debit限制，頻率，取消權。
界面包括任務管理屏幕（pause/cancel/update）和註銷前的通知。

11） iDEAL和iGaming/高風險類別

在某些垂直領域，iDEAL 的可用性僅限於風險政策和當地法律下的銀行/PSP。
對於iGaming：收緊檢查、降低限制、強制性的本地合規性和透明的ODR/Refund-flow。
規劃替代軌道（卡、SEPA、開放銀行A2A）和流量分割。

12） Merchant集成： 選項

1.Hosted/Embedded iDEAL Checkout от PSP

快速啟動,自動更新銀行、狀態和錯誤列表。

2.Server-to-Server+Reduct

靈活的UX控制： 銀行自己的選擇頁面,QR生成,深入集成到收銀機.

3.iDEAL QR

對於POS/離線：動態QR對數和標簽，更適合對賬和防損。

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• 按「orderId」分列的Idementity和Dedupe表。
• 帶有HMAC簽名的Webhooks，指數轉發，降解時的子彈輪詢。
• 目錄：銀行/限制/錯誤代碼；按發行人劃分的SLA度量。

13）「iDEAL Gateway」建築方案"

API層：用於結帳的REST+與PSP/iDEAL API集成。
事件隊列：活動狀態→ 計費/CRM/分析師。
觀察力：通過銀行/渠道轉換的指標（Redirect/App2App/QR），「open→expired」份額，平均潛伏期到成功。
安全性：保管庫中的秘密，PSP的IP allowlist，redirect-URL保護，反復制令牌。
數據：付款/退貨登記冊，ODR日誌，任務地圖。

14）入門清單檢驗

1.選擇帶有iDEAL的PSP/收購程序 （Host/Embedded/App2App/QR）。
2.實現「createPayment」+重新分配/Arr2Arr（銀行選擇屏幕）。
3.啟用Web hooks、等效性、定時和狀態重播。
4.按不同步配置recon （daily+full）、卸載和alerta。
5.支持Sapport中的partial/full refunds和ODR法規。
6.添加UX-fallback（替代方法，重播），帶有「transactionId」的支票。
7.在主罐上測試App2App/QR （iOS/Audrid/desktop）。
8.準備銀行限制手冊和事件狀態頁面。

按限制劃分的地標卡

Per-txn/24h/7d：存儲在config中；在重新引導啟動之前進行驗證。
新受益人/受益人：降低起始限制和/或延遲。
頻道：在移動App2App上，限制/限制策略可能與Web不同。
任務：在任務規定範圍內確定限制/周期（遞減註銷）。

總結

依靠轉換App2App/Embedded和離線動態QR。
不要錯過硬金額：對銀行進行限額和行為規則。
該過程圍繞webhooks+recon，明確狀態和部分回贈構建。
對於訂閱-首次支付iDEAL →電子授權；透明地管理限制和通知。