sumsub-integrate-travel-rule

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Sumsub — Travel Rule integration

Sumsub — Travel Rule 集成

Travel Rule is an exchange of participant data between two VASPs about one transfer. Sumsub is the hub: you talk to Sumsub, Sumsub talks to the counterparty over whichever protocol you both speak.

The integration is small. What makes it fail in production is that most integrations build one half of it — they start exchanges but never finalise them, or they answer the first question and not the second, and nothing in the API complains. This recipe is organised around those omissions.

Travel Rule 是两个VASP之间针对单笔转账进行的参与者数据交换。Sumsub 作为枢纽：您与Sumsub交互，Sumsub通过双方支持的协议与交易对手沟通。

集成本身并不复杂，但在生产环境中失败的原因往往是大多数集成只完成了一半——启动了交易流程却从未完成，或者只回复了第一个问题而忽略了第二个，而API不会对此发出任何报错。本指南围绕这些容易遗漏的点展开。

⚠️ Sandbox tokens only

⚠️ 仅使用Sandbox令牌

Do not accept or use a production App Token here. Travel Rule acts on real transfers and real counterparty VASPs, and a test exchange sent to a live counterparty puts a real request in a real compliance queue. Insist on a sandbox pair from https://cockpit.sumsub.com/checkus/home?sbx=true — Connect Sumsub to your AI agent -> Build & configure -> Generate token. Token + secret are revealed once; copy both before closing the dialog.

Deeper auth mechanics:

sumsub-api-auth

请勿在此处接受或使用生产环境的App Token。Travel Rule作用于真实转账和真实交易对手VASP，向真实交易对手发送测试交易请求会将真实请求放入对方的合规队列。请务必从 https://cockpit.sumsub.com/checkus/home?sbx=true 获取Sandbox令牌对——Connect Sumsub to your AI agent -> Build & configure -> Generate token。令牌和密钥仅会显示一次；请在关闭对话框前复制两者。

更详细的认证机制：

sumsub-api-auth

。

The three flows

三种流程

Everything starts with one question: who creates the exchange, and has the transfer already settled on-chain?

                          who creates the exchange?
                  ┌────────────────────┬────────────────────┐
                  │        you         │   the counterparty │
   ┌──────────────┼────────────────────┼────────────────────┤
   │ not settled  │  ① before          │                    │
   │ yet          │    settlement      │   ③ you answer     │
   ├──────────────┼────────────────────┤     their request  │
   │ already      │  ② after           │                    │
   │ settled      │    settlement      │                    │
   └──────────────┴────────────────────┴────────────────────┘

	① before settlement	② after settlement	③ answering
Typical case	Your user is withdrawing	A deposit arrived with no data	Anything involving your user
`info.paymentTxnId`	empty	required	set by them
Blocking	yes — the withdrawal waits	no — funds already moved	their transfer waits on you
End state	`finished` after you link the hash	`finished` , automatically	`finished` , automatically

📘 Do not key your integration off
info.direction
. It says which way the money moves for the account you are looking at, and it is flipped between the two sides of the same exchange. Who created the exchange is the distinction that changes your code; direction is not.

⚠️ Flow ③ is not optional. Every VASP that starts exchanges also receives them, and an unanswered request means your user's transfer is delayed or refused by the counterparty's rules. Integrations that ship only ①/② are the single biggest source of Travel Rule failures.

一切都始于一个问题：谁发起交易，且转账是否已在链上完成结算？

                          who creates the exchange?
                  ┌────────────────────┬────────────────────┐
                  │        you         │   the counterparty │
   ┌──────────────┼────────────────────┼────────────────────┤
   │ not settled  │  ① before          │                    │
   │ yet          │    settlement      │   ③ you answer     │
   ├──────────────┼────────────────────┤     their request  │
   │ already      │  ② after           │                    │
   │ settled      │    settlement      │                    │
   └──────────────┴────────────────────┴────────────────────┘

	① 结算前	② 结算后	③ 响应请求
典型场景	用户发起提现	存款已到账但无相关数据	涉及您用户的任何场景
`info.paymentTxnId`	留空	必填	由对方设置
是否阻塞	是——提现需等待	否——资金已转移	对方的转账需等待您的响应
最终状态	关联哈希后变为 `finished`	自动变为 `finished`	自动变为 `finished`

📘 请勿根据
info.direction
来设计集成逻辑。它表示您所查看账户的资金流向，而同一交易的双方看到的流向是相反的。真正决定代码逻辑的是谁发起了交易，而非资金流向。

⚠️ 流程③并非可选。每个发起交易的VASP也会收到请求，未回复的请求会导致您用户的转账被延迟或被交易对手的规则拒绝。仅实现流程①/②是Travel Rule集成失败的最主要原因。

Stage 0 — Preconditions

阶段0 — 前置条件

Check these before writing any code; each produces a confusing failure later.

Travel Rule entitlement on the tenant — verify with
```
sumsub-check-permissions
```
.
Your organisation is linked to a VASP. Without it, nothing starts and the error reads
```
Your organization is not yet linked to a VASP. Please contact your Customer Success Manager
```
. That is not a permissions problem and not retryable — relay it and stop. Linking is done by a Customer Success Manager, not over the API.
A Travel Rule rule bundle is installed and active. The bundle decides what each exchange outcome means for the transaction's review answer — the platform has no default opinion. See
```
sumsub-create-kyt-rules
```
.
Travel Rule settings are configured: confirmation timeout, ownership validation mode, participant data settings.

Webhooks are subscribed and reaching you — see

sumsub-manage-webhooks

. The events that matter here:

applicantKytTxnCreated

applicantKytTxnApproved

applicantKytTxnRejected

applicantKytOnHold

applicantKytTxnAwaitingUser

applicantKytTxnDataChanged

The Wallet Address Book has your addresses — both the ones you receive on and the ones you send from. See
```
sumsub-manage-wallet-address-book
```
.

在编写任何代码前请检查以下事项，否则后续会出现难以排查的问题。

租户拥有Travel Rule权限——通过
```
sumsub-check-permissions
```
验证。
您的组织已关联到VASP。若无关联，交易无法启动，错误信息为
```
Your organization is not yet linked to a VASP. Please contact your Customer Success Manager
```
。这并非权限问题且无法重试，请直接告知用户并终止流程。关联操作需由客户成功经理完成，无法通过API进行。
已安装并激活Travel Rule规则包。规则包决定了每个交易结果对交易审核结论的影响——平台无默认规则。请查看
```
sumsub-create-kyt-rules
```
。
已配置Travel Rule设置：确认超时时间、所有权验证模式、参与者数据设置。

已订阅Webhook且能正常接收——请查看

sumsub-manage-webhooks

。此处关键事件包括：

applicantKytTxnCreated

、

applicantKytTxnApproved

、

applicantKytTxnRejected

、

applicantKytOnHold

、

applicantKytTxnAwaitingUser

、

applicantKytTxnDataChanged

。

钱包地址簿已包含您的地址——包括接收和转出地址。请查看
```
sumsub-manage-wallet-address-book
```
。

Stage 1 — Identify the counterparty VASP

阶段1 — 识别交易对手VASP

This single step moves the success rate more than anything else in the integration, and it is the one most often skipped.

这一步对集成成功率的影响最大，但也是最常被跳过的步骤。

Option A — let the user pick (recommended)

选项A — 让用户选择（推荐）

Add a destination selector to the withdrawal screen and pass the chosen id as

counterparty.institutionInfo.internalId

. Attribution is then skipped entirely and the request goes straight to the counterparty.

bash

undefined

在提现页面添加目的地选择器，并将用户选择的ID作为

counterparty.institutionInfo.internalId

传入。这样可以直接跳过归属步骤，请求将直接发送给交易对手。

bash

undefined

search the directory as the user types

用户输入时搜索目录

GET /resources/vasps/-?q=binance&limit=20


- Search on `q` — people know brand names, not legal entities.
- If they pick a group rather than one of its regional entities, that is fine:
  Sumsub resolves the group down to the entities underneath it that can
  actually receive the request. Do not force a choice between subsidiaries.
- Hidden VASPs are excluded by default; test VASPs only exist in Sandbox, so
  no production filtering is needed.

Single VASP by id: `GET /resources/api/vasps/{id}/one`.

GET /resources/vasps/-?q=binance&limit=20


- 使用`q`参数搜索——用户更了解品牌名称而非法律实体。
- 如果用户选择的是集团而非区域实体，无需担心：Sumsub会自动将集团解析为实际能接收请求的下属实体。无需强制用户在子公司间做出选择。
- 默认隐藏VASP会被排除；测试VASP仅存在于Sandbox，因此生产环境无需额外过滤。

通过ID获取单个VASP：`GET /resources/api/vasps/{id}/one`。

Option B — send only the address

选项B — 仅发送地址

Sumsub attributes it against the wallet address databases, then asks the Travel Rule protocols, then falls back to blockchain analytics providers. This is the right fallback when the user cannot name their destination, but a significant share of addresses cannot be attributed at all.

The two are not exclusive: offer the picker, allow proceeding without it.

Sumsub会先在钱包地址数据库中进行归属匹配，再通过Travel Rule协议查询，最后回退到区块链分析提供商。当用户无法说出目的地名称时，这是合适的备选方案，但仍有大量地址无法完成归属。

两种选项并非互斥：既提供选择器，也允许用户不选择直接继续。

Stage 2 — Submit the transfer

阶段2 — 提交转账

Build and post the transaction with

sumsub-create-transaction

using

type: travelRule

. Only two fields distinguish the flows:

	before settlement	after settlement
`info.paymentTxnId`	omit	the on-chain hash
`counterparty.institutionInfo.internalId`	VASP id from Stage 1, when known	same

📘 In flow ② check first that an exchange does not already exist for this transfer — a duplicate puts two requests in the counterparty's queue. Query

GET /resources/kyt/txns/query/-

walking the deduplication ladder — hash, then address + asset, then amount + time window — and create the exchange only when nothing comes back. Endpoint syntax, the ladder and helper scripts:

references/find-transactions.md

🚧 Sending a hash in flow ① turns it into an after-settlement exchange — the counterparty is asked to authorise a transfer that already happened. Omitting it in flow ② does the reverse. This one field decides the semantics.

使用

sumsub-create-transaction

构建并提交交易，设置

type: travelRule

。仅以下两个字段区分不同流程：

	结算前	结算后
`info.paymentTxnId`	省略	链上哈希值
`counterparty.institutionInfo.internalId`	阶段1获取的VASP ID（已知时）	相同值

📘 在流程②中，需先检查该转账是否已存在对应的交易——重复请求会在交易对手队列中生成两条请求。通过

GET /resources/kyt/txns/query/-

按去重优先级查询——哈希值、地址+资产、金额+时间窗口——仅当无结果时才创建交易。端点语法、去重优先级和辅助脚本请查看：

references/find-transactions.md

。

🚧 在流程①中传入哈希值会将其转换为结算后交易——交易对手会被要求授权已完成的转账。在流程②中省略哈希值则会产生相反效果。这一个字段决定了交易的语义。

Currencies and chains

货币与链

Two currency facts change Travel Rule behaviour, not just precision.

A symbol is not an asset.

USDT

and

USDC

each name more than a dozen different assets in Sumsub's catalogue, and over a thousand symbols exist on more than one chain. Send

currencyCode

without

cryptoParams.cryptoChain

for one of those and the lookup matches nothing at all, so the asset is unresolved and no conversion happens.

Thresholds are compared against
amountInDefaultCurrency
. If that field is absent, the Travel Rule threshold check is skipped entirely and the flow runs regardless of amount — the same for the unhosted-wallet threshold. The value is also frozen when the transaction is created, so a bad conversion needs a backfill, not a re-read. Send

amountInDefaultCurrency

and

defaultCurrencyCode

explicitly whenever you know them.

📘 The counterparty's protocol has its own asset vocabulary, and only a minority of catalogue entries carry a mapping for any given protocol. An exotic token with no mapping cannot be expressed in the outgoing message and the exchange ends at

notEnoughCounterpartyData

before delivery. Check vocabulary coverage before debugging the payload.

Resolving symbols, chains and aliases:

sumsub-resolve-currency

两个货币相关的事实会改变Travel Rule的行为，而非仅仅是精度问题。

符号不等于资产。

USDT

和

USDC

在Sumsub的目录中各对应十多种不同资产，且有上千种符号存在于多条链上。若仅发送

currencyCode

而不附带

cryptoParams.cryptoChain

，将无法匹配到任何资产，导致资产无法解析，也不会进行转换。

阈值与
amountInDefaultCurrency
进行比较。若该字段缺失，Travel Rule阈值检查会被完全跳过，流程会无视金额执行——非托管钱包阈值也是如此。该值在交易创建时会被冻结，因此错误的转换需要回填而非重新读取。只要您知道相关值，请显式发送

amountInDefaultCurrency

和

defaultCurrencyCode

。

📘 交易对手的协议有自己的资产词汇表，只有少数目录条目针对特定协议有映射关系。无映射关系的小众代币无法在 outgoing message中表达，交易将在送达前终止于

notEnoughCounterpartyData

状态。在调试负载前请先检查词汇表覆盖范围。

解析符号、链和别名：

sumsub-resolve-currency

。

Stage 3 — Read the outcome

阶段3 — 查看结果

Sumsub assigns a Travel Rule status, then your rules assign a review answer. They are different things and readers conflate them constantly: a transaction can be approved by your rules while its exchange sits at

expired

. Gate your withdrawal on the review answer, and record the exchange status for audit.

Read the transaction with

${CLAUDE_SKILL_DIR}/scripts/get_transaction.sh <txnId>

(a signed curl — use the scripts rather than hand-rolling HTTP so signing and encoding stay right). Immediately after submission the exchange either waits or is already final:

Outcome	Meaning
`awaitingCounterparty`	Delivered; waiting on their answer
`counterpartyVaspNotFound`	Nobody to ask — treated as an unhosted wallet. Usually the largest single outcome by volume; see `references/unhosted-wallets.md`
`counterpartyVaspNotReachable`	Identified, but no shared protocol
`notEnoughCounterpartyData`	Your payload failed protocol validation — not their decline
`notApplicable`	Your configuration skipped it

Full status list, transitions and which ones are final:

references/statuses.md

Sumsub会分配Travel Rule状态，然后您的规则会分配审核结论。二者是不同的概念，用户常将其混淆：交易可能被您的规则批准，但交易状态仍为

expired

。请根据审核结论控制提现流程，并记录交易状态用于审计。

使用

${CLAUDE_SKILL_DIR}/scripts/get_transaction.sh <txnId>

读取交易（签名后的curl请求——请使用脚本而非手动编写HTTP请求，以确保签名和编码正确）。提交后交易要么处于等待状态，要么已完成：

结果	含义
`awaitingCounterparty`	已送达；等待对方回复
`counterpartyVaspNotFound`	无请求对象——视为非托管钱包。通常是交易量最大的结果；请查看 `references/unhosted-wallets.md`
`counterpartyVaspNotReachable`	已识别，但无共享协议
`notEnoughCounterpartyData`	您的负载未通过协议验证——并非对方拒绝
`notApplicable`	您的配置跳过了该交易

完整状态列表、状态转换及最终状态：

references/statuses.md

。

Stage 4 — Finalise, or cancel

阶段4 — 完成或取消

Only flow ① needs code here. Flows ② and ③ reach

finished

on their own.

bash

undefined

仅流程①需要编写代码。流程②和③会自动进入

finished

状态。

bash

undefined

after you broadcast

广播后执行

${CLAUDE_SKILL_DIR}/scripts/finalize_txn.sh <txnId> <on-chain hash>

→ PATCH /resources/kyt/txns/{id}/data/info { "paymentTxnId": "<on-chain hash>" }

if the user abandoned the withdrawal instead

如果用户放弃提现

${CLAUDE_SKILL_DIR}/scripts/cancel_txn.sh <txnId>

→ POST /resources/api/tr/{id}/cancel


🚧 **This is the most-skipped call in the whole integration.** Without it the
exchange stops at `completed`, the counterparty can never reconcile the data
they hold against anything on-chain, and neither side has a complete record
for audit. Send the hash as soon as you broadcast.

Cancelling matters too: an abandoned exchange left open occupies the
counterparty's queue until it expires and records you as unresponsive.


🚧 **这是整个集成中最常被遗漏的调用**。若无此步骤，交易将停留在`completed`状态，交易对手永远无法将其持有的数据与链上记录进行对账，双方都无法获得完整的审计记录。请在广播后立即发送哈希值。

取消操作也很重要：未关闭的废弃交易会占用交易对手的队列直至过期，并记录您为未响应状态。

Stage 5 — Answer incoming requests

阶段5 — 响应传入请求

A request arrives as

applicantKytTxnCreated

on a transaction where your user is
data.applicant
and the wallet to confirm is

data.applicant.paymentMethod.accountId

. Fetch it with

${CLAUDE_SKILL_DIR}/scripts/get_transaction.sh <txnId>

Answering is two responses, in order. The transaction tells you which it still needs:

Flag	`true`	`false`
`needMasking`	send response one	already answered — skip
`travelRuleInfo.needApplicantOwnershipConfirmation`	send response two	already answered — skip

bash

undefined

请求会以

applicantKytTxnCreated

事件形式到达，对应的交易中您的用户是
data.applicant
，需要确认的钱包是

data.applicant.paymentMethod.accountId

。使用

${CLAUDE_SKILL_DIR}/scripts/get_transaction.sh <txnId>

获取交易详情。

响应需分两步，按顺序执行。交易信息会告知您仍需执行哪些步骤：

标志	`true`	`false`
`needMasking`	发送第一步响应	已回复——跳过
`travelRuleInfo.needApplicantOwnershipConfirmation`	发送第二步响应	已回复——跳过

bash

undefined

response one — is this wallet ours?

第一步响应——此钱包是否属于我们？

${CLAUDE_SKILL_DIR}/scripts/confirm_ownership.sh <txnId> confirmed # or unconfirmed

${CLAUDE_SKILL_DIR}/scripts/confirm_ownership.sh <txnId> confirmed # 或unconfirmed

→ POST /resources/kyt/txns/{id}/ownership/confirmed

response two — whose is it?

第二步响应——钱包属于谁？

${CLAUDE_SKILL_DIR}/scripts/attach_applicant.sh <txnId> <applicantId>

→ POST /resources/kyt/txns/{id}/travelRuleOwnership { "applicantId": "..." }

an { "applicantParticipant": { ... } } body instead: attach_applicant.sh <txnId> - < body.json

若使用{ "applicantParticipant": { ... } }作为请求体：attach_applicant.sh <txnId> - < body.json


🚧 **Order is load-bearing, and getting it wrong fails silently.** Response two
on its own returns 200 — but while `needMasking` is `true` the exchange is
pinned at `onHold` no matter what data you send, the counterparty never
receives an answer, and the request expires. Confirming the address is also
what unmasks the counterparty's data, so until response one lands there is
nothing to reconcile against.

📘 No waiting between them. Both calls return the updated transaction, so there
is nothing to re-read and no webhook to wait for.

If you see your transactions sitting at `onHold`, you are sending response one
and not response two.


🚧 **顺序至关重要，错误的顺序会导致静默失败**。仅发送第二步响应会返回200，但只要`needMasking`为`true`，交易就会被固定在`onHold`状态，无论您发送什么数据，交易对手都不会收到回复，请求最终会过期。确认地址也是解锁交易对手数据的操作，因此在第一步响应完成前，无法进行对账。

📘 无需在两步之间等待。两个调用都会返回更新后的交易信息，因此无需重新读取或等待Webhook。

如果您发现交易停留在`onHold`状态，说明您只发送了第一步响应而未发送第二步。

How long you have

响应时限

Seconds, not minutes. The counterparty picks the confirmation timeout in their own settings, and the shortest value on offer is currently 10 seconds — the whole round trip, including webhook delivery and both calls, not your thinking time. It is not shown on the transaction and varies by counterparty, so design for the shortest rather than the typical.

Some protocols do not wait at all: the counterparty's system asks and expects the answer inside the same request, so whatever Sumsub can determine from your stored configuration at that instant is the answer. There is no window and no opportunity to answer by hand.

🚧 That is why automation is not an optimisation here. A manual process cannot cover the traffic, and you cannot tell in advance which kind of request is arriving.

以秒计，而非分钟。交易对手会在自己的设置中选择确认超时时间，目前最短的可选值为10秒——这是整个往返流程的时间，包括Webhook送达和两次调用，而非您的思考时间。该时限不会显示在交易信息中且因交易对手而异，因此请按最短时限设计流程。

有些协议根本不会等待：交易对手的系统会在同一请求中发出询问并期望立即得到回复，因此Sumsub在该瞬间从您的存储配置中获取到的信息就是回复。没有时间窗口，也没有手动回复的机会。

🚧 这就是为什么自动化并非可选优化。手动流程无法处理流量，且您无法提前预知即将到来的请求类型。

Automating both responses

自动化两步响应

Automation does not replace the two responses — it pre-answers them, so requests arrive with the flags already

false

Register this	Pre-answers
Address in the Wallet Address Book	response one
Address as an applicant payment method	both

Neither works unless the ownership validation mode allows reuse — one setting, chosen in the dashboard. See Confirmation ownership mode and

sumsub-manage-wallet-address-book

自动化并非替代两步响应，而是预先完成回复，使请求到达时标志已为

false

。

注册以下内容	预先完成的响应
钱包地址簿中的地址	第一步响应
作为申请人支付方式的地址	两步响应

只有当所有权验证模式允许重复使用时，上述方法才有效——该设置在控制台中选择。请查看Confirmation ownership mode和

sumsub-manage-wallet-address-book

。

Stage 6 — Test it in Sandbox

阶段6 — 在Sandbox中测试

Sandbox provides a test VASP that answers like a real counterparty. Work outward from the success case so that when something breaks you know which change caused it, and rehearse the finalisation step specifically — it is the one integrations omit in production.

Procedure, trigger values and what is not reproducible in Sandbox:

references/sandbox-testing.md

Sandbox提供了一个测试VASP，其行为与真实交易对手一致。从成功场景开始向外扩展，这样当出现问题时您可以知道是哪项更改导致的，并专门演练完成步骤——这是生产环境中集成常遗漏的步骤。

测试流程、触发值及Sandbox中无法复现的内容：

references/sandbox-testing.md

。

Go-live checklist

上线检查清单

另请参阅

```
references/statuses.md
```
— every status, what moves it, which are final.
```
references/sandbox-testing.md
```
— Sandbox procedure and trigger values.

examples/withdrawal-before-settlement.json

examples/deposit-after-settlement.json

— transaction specs for

sumsub-create-transaction

```
examples/answer-incoming-request.js
```
— webhook handler implementing Stage 5 with the flags and ordering.
```
references/unhosted-wallets.md
```
— the unhosted-wallet path:
```
POST /resources/tr/sdk/init
```
, reading the ownership check, manual verification; sequence details in
```
references/unhosted-wallet-flow.md
```
.
```
references/find-transactions.md
```
— searching transactions and the dedupe ladder; operator and encoding details in
```
references/query-syntax.md
```
.

sumsub-resolve-currency

— which

currencyCode

cryptoChain

to send, and why

amountInDefaultCurrency

matters here.

Sumsub docs: Travel Rule data exchange flows, Travel Rule settings, Wallet Address Book, Unhosted wallet verification.

```
references/statuses.md
```
— 所有状态、状态转换条件及最终状态。
```
references/sandbox-testing.md
```
— Sandbox测试流程及触发值。

examples/withdrawal-before-settlement.json

examples/deposit-after-settlement.json

—

sumsub-create-transaction

的交易示例。

```
examples/answer-incoming-request.js
```
— 实现阶段5的Webhook处理程序，包含标志检查和顺序控制。
```
references/unhosted-wallets.md
```
— 非托管钱包流程：
```
POST /resources/tr/sdk/init
```
、所有权检查读取、手动验证；详细流程请查看
```
references/unhosted-wallet-flow.md
```
。
```
references/find-transactions.md
```
— 交易搜索和去重优先级；操作符和编码细节请查看
```
references/query-syntax.md
```
。

sumsub-resolve-currency

— 应发送哪些

currencyCode

cryptoChain

，以及

amountInDefaultCurrency

为何重要。

Sumsub文档：Travel Rule data exchange flows, Travel Rule settings, Wallet Address Book, Unhosted wallet verification。

sumsub-integrate-travel-rule

Original

Translation

Sumsub — Travel Rule integration

Sumsub — Travel Rule 集成

⚠️ Sandbox tokens only

⚠️ 仅使用Sandbox令牌

The three flows

三种流程

Stage 0 — Preconditions

阶段0 — 前置条件

Stage 1 — Identify the counterparty VASP

阶段1 — 识别交易对手VASP

Option A — let the user pick (recommended)

选项A — 让用户选择（推荐）

search the directory as the user types

用户输入时搜索目录

Option B — send only the address

选项B — 仅发送地址

Stage 2 — Submit the transfer

阶段2 — 提交转账

Currencies and chains

货币与链

Stage 3 — Read the outcome

阶段3 — 查看结果

Stage 4 — Finalise, or cancel

阶段4 — 完成或取消

after you broadcast

广播后执行

→ PATCH /resources/kyt/txns/{id}/data/info { "paymentTxnId": "<on-chain hash>" }

→ PATCH /resources/kyt/txns/{id}/data/info { "paymentTxnId": "<on-chain hash>" }

if the user abandoned the withdrawal instead

如果用户放弃提现

→ POST /resources/api/tr/{id}/cancel

→ POST /resources/api/tr/{id}/cancel

Stage 5 — Answer incoming requests

阶段5 — 响应传入请求

response one — is this wallet ours?

第一步响应——此钱包是否属于我们？

→ POST /resources/kyt/txns/{id}/ownership/confirmed

→ POST /resources/kyt/txns/{id}/ownership/confirmed

response two — whose is it?

第二步响应——钱包属于谁？

→ POST /resources/kyt/txns/{id}/travelRuleOwnership { "applicantId": "..." }

→ POST /resources/kyt/txns/{id}/travelRuleOwnership { "applicantId": "..." }

an { "applicantParticipant": { ... } } body instead: attach_applicant.sh <txnId> - < body.json

若使用{ "applicantParticipant": { ... } }作为请求体：attach_applicant.sh <txnId> - < body.json

How long you have

响应时限

Automating both responses

自动化两步响应

Stage 6 — Test it in Sandbox

阶段6 — 在Sandbox中测试

Go-live checklist

上线检查清单

See also

另请参阅