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。