Skip to main content
Completing an order is a stateful chain: every ID returned by one step must be passed verbatim to the next, never fabricated or mixed across chains. This page threads the whole chain together using MCP tools; the full field table for each tool lives in the corresponding tool reference.
Every example below is an MCP tool call: a tool name plus JSON arguments. Apart from the binding tools, each business tool carries a consent_grant_id argument (user consent, cg_ prefix). The Agent identity is carried at the connection layer via the Authorization: Bearer clw_... header — see the “Authentication” section below.

​
Overview

The order flow threads these MCP tools in a fixed order: prepare the delivery address first (search_addresses → select_address), then search_shops to pick a shop, get_shop_menu to pick items, then quote_cart to price, preview_order to get the ordering tokens, and create_order to place the order. Fixing the address first means you search shops that deliver there, and every downstream tool has the delivery coordinates. Cross-step IDs are issued by the gateway and passed back verbatim.
Passwordless signing is a one-time, account-level prerequisite (see “Passwordless payment signing” below) — it is not part of any single order’s chain and is not tied to a specific order. Don’t treat it as the last step of ordering.
How IDs flow through the chain:
All amount fields are in cents (integers), not yuan. For example, payable_price: 1500 means ¥15.00.

​
The Full Chain

​
Passwordless payment signing (account-level, one-time)

Passwordless signing lets the user authorize passwordless payment: sign once, and subsequent passwordless-payment orders charge automatically. It is an account-level, one-time prerequisite — not tied to any single order, and not done per order — which is why it sits apart from the ordering chain above. Before you need passwordless payment, check whether the user has signed with get_sign_status; if not, initiate signing:
Returns an action: when action_type is open_h5, send the user to action.action_url (the H5 signing page) to complete signing, after which the browser returns to return_url; when it is none, the user is already signed. Then poll the result with get_sign_status.
Full fields: Initiate Passwordless Signing · Check Signing Status.

​
Query an order and payment result

After ordering, use get_order_status to actively query the order’s current status and details:
If you passed callback_url to create_order, every status change on the order POSTs a callback (the payment-outcome one carries event=order_payment), so you don’t have to keep polling. The two paths: The callback body has 6 keys: event, order_id, ispay, status, status_text, consent_grant_id. The ispay enum: success (entered the paid flow), closed (cancelled or closed), timeout (~15-minute polling window elapsed still unpaid), unknown (consent revoked/rotated or the order reference became invalid).
Full fields: Get Order; the status / callback ispay enums: Create Order.

​
Authentication

Every tool call requires two-layer authentication:
  • Agent identity (API Key): carried when connecting to MCP via the Authorization: Bearer clw_... header, on every request. Generated when you create an Agent in the console https://console.hicaspian.com/agents.
  • User consent grant (identifies the authorized user, cg_ prefix): passed as each business tool’s consent_grant_id argument (not a header). The binding tools request_user_bind / verify_user_bind are the exception — they are how you obtain consent, so they take no consent_grant_id.
See Authentication. Errors are returned in the uniform shape {"error": {"code", "message"}}; see Error Handling.