Trustly：直接銀行付款

1）什麼是Trustly

Trustly是付款和付款的A2A（帳戶到帳戶）提供商，通過redirect/App2App將付款人與付款人的銀行聯系起來。買方確認其銀行（根據PSD2的SCA）的轉賬，商家立即收到在線確認，並通過提供商的報告/結算獲得資金。

• 相對於卡MDR低成本。
• 歐洲（Nordics，DACH，Benelux，UK，Southern EU等）的廣泛地理區域+本地銀行。
• Payouts和Payouts（包括支持銀行的instant payouts）。
• 專門的iGaming解決方案（例如Pay N Play：「已創建/驗證→帳戶存款」）。

2）產品線和腳本

付費（從銀行付款）：redirect/App2App付款人→ SCA →在線成功/拒絕→後續貸款。
付款：轉入用戶帳戶；對於許多銀行-瞬間（否則為T+1/T+2）。
Pay N Play （iGaming）：將存款與onbording結合起來：從銀行數據（名稱、IBAN/BIC等）中提取KYC信號,創建一個沒有單獨註冊的遊戲帳戶,Fast Withdraw可以返回同一帳戶。
Account Info/Check（可選）：帳戶所有權確認,anti-mule/ODR 名稱驗證/IBAN。

3）付款流： Redirect和App2App

3.1 Classic redirect

1.商人的檢查→銀行選擇（目錄/搜索）。
2.重新編輯到銀行頁面或SCA →托管屏幕。
3.返回到具有狀態的商人站點（成功/pending/failed/canceled/expired）。
4.等待webhook/招生報告（定位）。

3.2 App2App（移動）

通過deeplink/intent打開銀行應用程序→確認→退款。
轉換以上，放棄的付款減少；請務必在Web上進行倒退。

3.3 Payouts

通過具有訂單/獲勝參考的API啟動付款；獲得「已接受處理」的在線狀態和webhook/註冊表總數。
保持相等性和支付狀態圖是至關重要的（直至重復/回滾）。

4）限制和風險政策

• 付款人銀行的周轉和周轉限制。
• 新收件人/收件人-降低閾值和/或快門速度。
• 頻道/velocity規則，地理/數據信號，抗mu。
• 對於payouts-單獨的配額/閾值檢查（尤其是instant）。

5）狀態和計算： 在線成功vs實際信用

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.

定位：Trustly報告/註冊表中的實際存款（通常為T+1/T+2銀行日；對於某些目的地/付款-instant）。
對於關鍵服務，應用「信用前條件執行」模型（例如，在確認定居點後激活數字商品）。

6）退貨和付款

卡中沒有充電包。退款-通過提供商向付款人進行新的貸款操作。
支持Partial refunds。
退貨截止日期是銀行（通常為T+1/T+2）。
Disputs-通過提供商的ODR流程和付款人的銀行：準備訂單日誌、服務/交付確認、payout↔pay-in通信。

7）委員會與經濟

通常是虛假/低交易百分比+平臺功能（主機檢查，報告，ODR，payouts/instant）的費用。
計劃pending/expiries、ODR和recon支持費用。

8）核對和報告（重組）

保存「paymentId/transactionId」提供商、「orderId」、bank-issuer、時間戳、UTR/fin報告中的銀行參考。
將webhooks連接到狀態更改；運行每日自動計數和定期全計數（入賬/退款/更正）。
對於payouts-單獨的註冊表和與原始支付/遊戲余額的匹配。

9） UX實踐

銀行目錄：快速搜索,按人氣/最新選擇排序。
移動第一：提供App2App；失敗時-在Web上失敗。
錯誤和重復：明確的原因代碼（限制、SCA故障、定時）,重復按鈕,替代方法。
等效性：'orderId'+安全回歸的等效性關鍵。
收據：金額，時間，「transactionId」，銀行，頻道（App2App/Redirect），指向劄幌的鏈接。
Payout UX：透明ETA（instant/T+1），跟蹤狀態，通知。

10） Pay N Play（適用於iGaming）

沒有註冊表的Onbording：用戶選擇銀行，確認存款，提供商將經過驗證的銀行數據（姓名/帳戶）發送給商人-創建一個遊戲帳戶。
銀行的KYC信號減少了摩擦並加快了首次存款。
Fast Withdraw：向同一確認賬戶付款，往往是瞬間。
需要嚴格的負責任遊戲政策，存款限制，任務日誌和透明的ODR。

11）合規與安全

PSD2/SCA，設備約束和發行銀行的反欺詐。
GDPR/PII最小化：僅存儲必要的屬性,加密PII,限制訪問。
Webhooks： HMAC 簽名/nonce, replay保護,allowlist IP。
AML/制裁：交易監控，帳戶名稱驗證（名稱匹配），反mule信號。

12）高風險縱向

某些類別（包括iGaming，crypto等）的可用性和限制取決於國家和合作夥伴銀行。
預計：收緊限制，擴展的KYC，可能的保留和補充證據。
保持備用導軌（卡、SEPA、來自其他提供商的開放銀行PIS）,通過客戶配置文件進行路由。

13） Merchant集成： 選項

1.Hosted/Embedded by提供商

快速啟動,現成的銀行列表,狀態,錯誤,webhooks。

2.Server-to-Server + Redirect/App2App

更多控制：銀行自己的選擇頁面,深度錯誤處理,自己的deeplink/QR。

3.發票/要求付款

通過電子郵件/SMS/Messenger引用付款鏈接；便於使用B2V/服務。

• Эндпоинты: `createPayment`, `refund`, `createPayout`, `queryStatus`, `webhook`, `reconcile`.
• 在「orderId」上具有相等性和遞減性。
• 指數狀態的復述，不穩定的響應的死信。
• 目錄：銀行/國家/地區，限制/錯誤代碼，issuer'am的SLA度量。

14） 「Trustly Gateway」架構"

用於收銀員和收銀員服務的API層（REST/GraphQL）。
事件隊列：活動狀態→ 計費/CRM/遊戲後端/分析師。
觀察力：通過銀行/渠道的轉換，「pending→success/expired」，平均潛伏期到定居點，instant payouts的份額。
Security：用於保管秘密、IP allowlist、嚴格的redirect-URI驗證、防重置令牌。

15）入門清單的清單

1.選擇地理位置/銀行並從PSP連接Trustly通道。
2.實現「createPayment」+選擇bank+redirect/App2App fallback。
3.連接webhooks、taymout和狀態獲取重播。
4.配置recon （daily+full）、UTR/fin參考存儲。
5.包括partial/full refunds、ODR日誌、劄幌程序。
6.對於iGaming-運行Pay N Play、存款限制、Fast Withdraw、跟蹤負責任的遊戲。
7.通過銀行/渠道對SLA進行監控，並通過事件對Alerta進行監控。
8.按國家/地區測試移動銀行（iOS/Android）和主要issuer's。

地標卡

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.

定期付費：更常見T+1/T+2；payouts-instant可用,否則為T+1/T+2。
限制：issuer'a的per-txn/天/周；新收件人-降低閾值。
遞歸：通過e-mandate/SEPA DD/開放銀行（第一個A2A →授權）。

總結

押註轉換App2App/Embedded和固定付款以保持。
在業務邏輯中共享在線確認和實際信用。
不要固定金額：通過銀行/國家/渠道管理限額。
對於iGaming,請使用帶透明的KYC、限額和快速付款的Pay N Play。