定位:扫码付是DeCard 托管独有的消费能力。本页归入「交易管理」组。
扫码即付,扣的还是同一个余额
扫码付让持卡人在支持二维码收款的商户处,用扫码(而非刷实体卡 / Tap)完成消费。与刷卡授权一样,扣款最终落在用户的独立账户余额上——可用余额减少、总额减少(下文以 DCS 内部惯用简称free(可用)/ total(总额)指代;API 层面 free 对应 availableBalance、冻结余额为 frozenBalance,参见 账户与资产模型),与刷卡走的是同一套。区别只在于「发起方式」:扫码付不经过卡网络的刷卡授权报文,而是 DCS 收单侧解码二维码、下单、再由您引导持卡人确认付款。
扫码付由 5 个接口组成,前缀统一为 /qrpay/v1/:支付主流程 decode → create → confirm,查询用 order-list / order-detail。
前置条件
- 用户已在 DeCard 托管下完成注册并通过 KYC,拥有
externalUserId(见 注册用户)。 - 用户已开卡,且 独立账户有足额可用余额
free(充值见 用户余额)。 - 调用方需带全站统一鉴权头(见 鉴权指南);下文示例省略鉴权头,仅示业务体。
全站响应结构统一为
CommonRet:{ code, message, messageDetail{message,title,type,icon,action,linkTitle,linkUrl}, data },无 success 布尔字段;成功时 code = SYS_SUCCESS。下文每个接口的响应样例均套用此结构。支付主流程
1. 解析二维码
POST /qrpay/v1/decode —— 解析二维码并返回订单预览(金额、商户、汇率、费用和限额),供应用展示给持卡人确认。
请求
响应(data)
2. 创建扫码订单
POST /qrpay/v1/create —— 在解码确认金额后下单,锁定订单。相比 decode 多传 currency 与 amount(用户输入金额的场景,如商户码不带金额)。
请求
响应(data)
字段与 decode 的 data 基本一致(orderId / acqCurrency / acqAmount / payCurrency / payAmount / merchantName / expiryTime / qrCodeType / promoInfo / sdkActionType / sdkActionPayload / rateInfo / usdAmount / feeAmount / feeCurrency / acqOrderNo / orderType),不含 needCashier / cashierSession / 限额类字段。请以返回的 orderId 进入下一步确认。
3. 确认支付
POST /qrpay/v1/confirm —— 对已下单的 orderId 确认支付。此步真正从用户独立账户扣款(可用余额 free 不足将失败)。
请求
响应(data)
confirm 返回成功仅代表受理;若返回 redirectUrl(收银台 / 二次验证场景),需引导持卡人完成跳转。最终状态以 order-detail 的 transList 或 Webhook 为准。扣款引起的余额变动会经 BALANCE_CHANGE Webhook 通知——见 Webhook 与 WebSocket 实时通知。查询订单
4. 查询订单列表
GET /qrpay/v1/order-list —— 游标分页查询用户的扫码付订单列表。
data 为数组,每项字段:
游标分页:取本页最后一条的orderId作为下一次请求的cursorOrderId;返回空数组表示已到末页。
5. 查询订单详情
GET /qrpay/v1/order-detail —— 查询单笔订单详情,含订单状态与底层交易流水列表 transList。
data 字段(除 decode/create 共有的金额 / 商户 / 汇率 / 费用字段外,额外有):
一笔订单的底层流水可能不止一条(如先
PAY 后 REFUND_PART)。transType 与 transStatus 枚举:
transList[].transId 按接口定义为 integer;「20」表示最大数字位数,不是字符串长度。
错误处理
- 非成功时
code ≠ SYS_SUCCESS,message/messageDetail给出可读信息——以data业务结果与code判定,勿仅看 HTTP 200。 - 常见失败原因:用户独立账户
free余额不足(confirm阶段)、订单过期(超expiryTime)、二维码非法 / 不支持(decode阶段)、金额超出minAmount/maxAmount/maxSingleAmount/当日剩余额度remainingAmount。 confirm返回受理后仍可能异步失败,最终以order-detail的transList[].transStatus或 Webhook 为准。- 完整错误码字典请向 DCS 团队索取。
与独立账户余额模型的关系
扫码付与刷卡消费共享同一套用户独立账户:扣款发生在confirm,最终落在用户 独立账户(free 可用余额)。(free / total 并非本接口直接返回,这些余额字段来自账户模型接口——如 /user-asset/v1/balance 等,其中 free 对应 API 字段 availableBalance、冻结余额对应 frozenBalance,详见 用户余额 与 账户与资产模型。)因此发起扫码付前,请确保用户账户已通过充值备足余额。
下一步
- 账户与资产模型(
free/freeze/total):账户与资产模型 - 查询 / 调整用户余额:用户余额
- 接收支付结果 / 余额变动通知:Webhook 与 WebSocket 实时通知
- 鉴权头与白名单:鉴权指南

