Skip to main content
创建收银台会话,锁定商品版本、定价和货币。这是一次性商品和订阅商品收银台流程的第一步。 典型流程为:
  1. 商户在服务端创建收银台会话
  2. checkoutUrl 返回给前端
  3. Customer 点击链接进入托管收银台页面
  4. Customer 填写账单信息、预览税费并完成订单
认证方式: API Key 或 Store Slug

请求体(API Key)

请求体(Store Slug)

Store Slug 认证不支持 priceSnapshotexpiresInSecondsmetadataorderMerchantExternalIdwithTrialincludePaymentMethodsexcludePaymentMethods。这些字段会被静默忽略,以防止客户端篡改价格和操纵会话。支付方式属于商户侧的商业决策(渠道费率、结算周期),浏览器不得收窄或放宽——Store Slug 创建的 session 一律开放该货币支持的全部方式。
ID 命名约定:同一组扁平双 key 名(checkout 端的 orderMerchantExternalId、退款工单端的 refundTicketMerchantExternalId)贯穿请求体、webhook 载荷以及承载这些值的每个 GraphQL 类型 — 在 checkout 创建时写入的值可在 OrderPaymentRefund 及 webhook 载荷中以相同的字段名读回。

价格快照对象

账单详情对象

传入 billingDetail 会把收银台与订单的账单国家挂钩:收银台只提供该国家所属市场的支付方式,买家无法切换市场。起作用的是订单最终的账单国家,而非你传入的值;账单国家不在我们覆盖的支付市场内时不产生限制。启用前请对照店铺开放的支付方式 —— 若挂钩后的市场不提供其中任何一种,该笔订单将无法支付。不传 billingDetail 则收银台不受限制,这是默认行为。

会话锁定

创建收银台会话时,以下值被锁定,在会话有效期内无法更改: productVersionIdproductNamepriceInfostoreNamebillingPeriodwithTrialthemebuyerEmailbillingDetail 邮箱规范化:所有邮箱字段(email / buyerEmail / contactEmail)在服务端会被规范化(trim().toLowerCase())后再用于存储、cache、下游调用。Foo@Bar.COMfoo@bar.com 视为同一账户。

请求示例

成功响应 (200)

响应字段

错误响应

重试策略:4xx 一律不要重试 — 修正请求后重发。5xx 指数退避重试(起步 5s,最多 3 次)。
payin_enableprod_enabled 是两个相互独立的条件:payin_enable 是平台侧控制的收款开关,prod_enabled 是生产环境审批(KYB)闸门。在 prod 环境下,任一条件单独不满足即返回 403。两者在 test 环境均不适用。
默认会话 TTL 为 45 分钟(2700 秒)。使用 API Key 认证时,可通过 expiresInSeconds 自定义。会话在创建时锁定商品版本和定价,因此价格变更不会影响已有会话。