airdbHONG KONG
Talk to us
Menu

Payments for trade.
Payments for agents.

From Hong Kong to a connected global economy. Exploring digital renminbi payment technology for cross-border trade — and programmable payments for the next generation of AI agents.

Explore the capabilitiesDiscuss an integration

In development. Capabilities shown are proposed; this site does not process payments.

One intent. A controlled payment flow.
22.3193° N114.1694° E
01HONG KONG02GLOBAL TRADE03AGENT ECONOMY
  1. 01Payment intent
  2. 02Authorization policy
  3. 03Payment orchestration
  4. 04Channel integration
  5. 05Receipt & reconciliation

Illustrative architecture · no live settlement

Trade & commerceSoftware & servicesMachine-to-machineAIRDB.HK / PROGRAMMABLE PAYMENTS

01 / PAYMENT SCENARIOS

Built around the way value moves.

01

Cross-border trade

Connect purchase orders, supplier payments and reconciliation in one traceable workflow. Digital renminbi channel integration is a proposed direction.

Orders → payments → reconciliation

02

Agent-authorized payments

Give an agent a defined budget and an approved purpose. Automate payments within policy, with human approval when a request exceeds its mandate.

Authorize → evaluate → execute

03

x402 & pay-per-request

Explore HTTP-native payment negotiation for APIs, data and digital services. Make payment part of the request-and-response flow.

Request → 402 → payment → response

04

Small payments. Frequent value.

Support the design of usage-based payments for inference, compute and content. Explore per-call charging and aggregated billing where appropriate.

API calls · compute · digital content

02 / CONTROL BY DESIGN

Autonomy starts with clear boundaries.

Passwordless means automatic payment after authorization — with explicit limits, a defined lifetime and a way to revoke access.

Budget & limits
Per-payment limits, cumulative budgets and validity periods.
Approved recipients
Restrict who can be paid and for which services.
Human approval
Route exceptions for review before a payment proceeds.
Traceable events
Connect payment intent, policy decisions and receipts in an audit trail.

03 / OPEN PAYMENT PROTOCOLS

An HTTP request.
A payment conversation.

x402 uses HTTP 402 to request payment before a service returns a resource. It is a protocol layer; the payment asset, network and settlement channel are separate choices.

  1. 01

    Request

    An agent requests a paid resource.

  2. 02

    Quote

    The service returns HTTP 402 and payment requirements.

  3. 03

    Authorize

    The client checks policy and submits payment authorization.

  4. 04

    Deliver

    Payment is verified; the service returns the resource.

SIMULATED EXCHANGEHTTP / 402
# 01 / request a resource
GET /example/compute

# 02 / service requests payment
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <requirements>

# 03 / retry with authorization
GET /example/compute
PAYMENT-SIGNATURE: <authorization>

# 04 / verified payment, resource delivered
HTTP/1.1 200 OK
PAYMENT-RESPONSE: <result>

x402 is currently primarily used for stablecoin payments. This illustration does not establish native e-CNY support or a live AirDB integration.

Read the x402 specification ↗

04 / FROM CONCEPT TO INTEGRATION

A clear view of what comes next.

  1. Now

    Product exploration

    Define trade and Agent payment scenarios, authorization rules and developer experience.

  2. Planned

    Developer sandbox

    Test identities, simulated balances, payment events and API examples. No real funds.

  3. Exploring

    Channel & protocol integration

    Evaluate digital renminbi channels and x402 compatibility with eligible partners and available interfaces.

Build the next payment conversation.

Working on cross-border trade, an AI agent or a paid API? Tell us about your use case.

Talk to us ↗