accepts

PAYMENT-REQUIRED

WWW-Authenticate: Payment

intent="charge"

"session"

User-facing terminology — IMPORTANT

Rule 1 — Always call it "OKX Agent Payments Protocol", and always render it bolded. Use the exact English term OKX Agent Payments Protocol in user-visible messages regardless of the user's language, and always wrap it in markdown bold (

**OKX Agent Payments Protocol**

) so the user sees it emphasized. Keep it as a fixed English noun phrase even inside otherwise-Chinese sentences. Reserve protocol literals and internal identifiers for CLI invocations, HTTP headers, JSON payloads, and code — never speak them to the user.

Rule 2 — Do not narrate internal protocol detection. The dispatch logic (which header was detected, which reference is being loaded, which scheme/intent was selected, TEE vs local-key path) is internal — keep it internal. The user only needs to see: (a) what is being paid, (b) what they need to confirm, (c) the result.

Rule 3 — Externally-defined protocol literals stay byte-for-byte exact. The JSON field

x402Version

, the HTTP headers

X-PAYMENT

/

PAYMENT-SIGNATURE

/

PAYMENT-REQUIRED

/

WWW-Authenticate: Payment

, and the reference URL

https://x402.org

MUST appear verbatim wherever the protocol/server requires them — these are externally defined and changing them breaks interop. CLI subcommand names (

onchainos payment pay

/

pay-local

/

charge

/

session ...

/

a2a-pay ...

) are this CLI's own surface and may evolve; refer to them by their current name in CLI invocations and code, but never speak them to the user (Rule 2).

Example

(中)

准备通过 **OKX Agent Payments Protocol** 完成本次支付，下面是扣款明细，请确认……

(EN)

Preparing a payment via the **OKX Agent Payments Protocol**. Here are the charge details — please confirm before I proceed…

Progress narration counts as user-visible — Rules 1-3 still apply.

Long-running flows (decode → confirm → wallet check → sign → header assembly → replay) tempt status updates. Every

"正在…"

/

"I'm now…"

line is user-facing. Step labels in this SKILL.md (

Step A3-Accepts

,

Step A3-WWW-Authenticate

) and reference files (

exact

/

aggr_deferred

schemes,

charge

/

session

intents) are internal — do NOT echo them in narration.

❌ Don't say	✅ Say
"正在处理 accepts -based 流程" / "Processing the accepts -based path"	"正在通过 OKX Agent Payments Protocol 处理本次支付" / "Processing the payment via the OKX Agent Payments Protocol"
"CLI 自动选择 exact 方案" / "CLI selected the exact scheme" / "走 aggr_deferred 路径"	"签名完成" / "Signing done"
"组装 PAYMENT-SIGNATURE / X-PAYMENT 头" / "Assembling the PAYMENT-SIGNATURE header"	"正在重放请求" / "Replaying the request"
"检测到 WWW-Authenticate: Payment / PAYMENT-REQUIRED 协议" / "Detected the channel-based protocol"	(silent — go straight to the confirmation prompt)
"加载 references/exact.md " / "Loading the exact playbook"	(silent — internal routing)
"进入 session 模式 / charge 模式" / "Entering session intent"	"支付通道已开" / "Channel opened" — describe the user-visible effect, not the internal mode
"TEE 路径 / 本地 key 路径" / "Using TEE signing path"	(silent — signing path is internal)

Read

../okx-agentic-wallet/_shared/preflight.md

before any

onchainos

command. EVM only — CAIP-2

eip155:<chainId>

(run

onchainos wallet chains

for the list).

Priority 1: response.headers['WWW-Authenticate']
  starts with "Payment "        → continue at Step A3-WWW-Authenticate
Priority 2: response.headers['PAYMENT-REQUIRED']
  base64-encoded JSON           → continue at Step A3-Accepts (v2)
Priority 3: response body JSON has "x402Version"
                                → continue at Step A3-Accepts (v1)
Otherwise                       → not a supported payment protocol, stop

WWW-Authenticate: Payment

PAYMENT-REQUIRED

x402Version

The server offers two payment options via the OKX Agent Payments Protocol:

1. One-shot purchase, or streaming session (multi-request) (recommended)
2. One-shot purchase

Which would you like to use?

WWW-Authenticate: Payment

PAYMENT-REQUIRED

x402Version

onchainos wallet status

accepts

PAYMENT-REQUIRED

x402Version

This resource requires payment via the OKX Agent Payments Protocol:

• Network:

  <chain name>

  (

  <option.network>

  )
• Token:

  <token symbol>

  (

  <option.asset>

  )
• Amount:

  <human-readable amount>

  (from

  option.amount

  for v2, or

  option.maxAmountRequired

  for v1; convert from minimal units using token decimals)
• Pay to:

  <option.payTo>

Proceed with payment? (yes / no)

WWW-Authenticate: Payment

This resource requires payment via the OKX Agent Payments Protocol:

• Payment type:

  <one-shot purchase (charge) | streaming session (multi-request)>

• Network:

  <chain name>

  (

  eip155:<chainId>

  )
• Token:

  <symbol>

  (

  <currency address>

  )
• Amount per request:

  <human-readable>

  (atomic:

  <amount>

  )
• Pay to:

  <recipient>

• Who pays gas:

  <server (transaction mode) | you broadcast it yourself (hash mode)>

• Split recipients (one-shot only, if present):

  <N other parties also receive a share>

• Suggested prepaid balance (session only, if present):

  <human-readable>

Proceed with payment? (yes / no)

• User confirms → Step A5.
• User declines → stop. No payment, no wallet check.

onchainos wallet status

• Logged in → Step A6.
• Not logged in (

  accepts

  -based path) → ask the user to choose between (1) wallet login (TEE signing) or (2) local private key (

  onchainos payment pay-local

  ,

  exact

  scheme only). Don't read files or check env vars until the user picks.
• Not logged in (

  WWW-Authenticate: Payment

  path) → ask the user to log in via email OTP or AK. TEE-only — no local-key fallback for this path (only the

  accepts

  -based path has one).

create

pay

onchainos wallet status

• Logged in → proceed (load the reference and follow it).
• Not logged in → ask the user to log in via

  onchainos wallet login

  or

  onchainos wallet login <email>

  . Do NOT sign without a live session.

1. body.reason

   (mppx, OKX TS Session)

2. body.detail

   (RFC 9457 ProblemDetails)

3. body.message

4. body.msg

   (OKX SA API)

5. body.error

6. body.title

   (RFC 9457 short title — fallback only)
7. fallthrough — format the whole body and add the HTTP status

❌ Seller rejected:

<reason text>

(code

<code if present>

, HTTP

<status>

)