如何从 issuer 的 authorization response 获取 Auth Expiration Date？

2026-10-24支付阿杰

明确结论

通常无法从 issuer 返回的 authorization response 中获得可靠的 auth expiration date。

标准授权响应一般只包含授权结果、authorization code、响应码，以及后续 capture/settlement 所需的交易标识，并没有统一且必须返回的授权到期时间字段。即使 payment gateway 或 processor 提供了 expires_at、authorization_valid_until 等字段，通常也是服务商根据卡组织规则计算出的业务期限，不一定来自 issuer，也不能说明持卡人账户上的资金冻结必然持续到该时间。

为什么没有统一的到期时间

授权的有效时长可能受多种因素影响，包括：

card network 的规则；
issuer 的资金冻结策略；
credit card、debit card 等卡片类型；
电商、酒店、租车等交易场景；
MCC 和交易类型；
processor/acquirer 的 capture 时限；
周末、节假日和跨境处理流程；
授权是否被撤销、调整或重新发起。

还需要区分以下两个概念：

Capture/settlement 的允许期限
processor 或 card network 允许商户在多长时间内使用原授权进行 capture。
持卡人账户上的 authorization hold 持续时间
issuer 何时释放被冻结的额度。

这两个期限并不完全一致。processor 仍允许提交 capture 时，issuer 可能已经释放 hold；同样，hold 尚未释放，也不代表延迟提交的 capture 一定符合处理规则。

因此，不能根据推算出的日期向客户承诺“授权在此之前必然有效”。

适合 7 到 14 天交付周期的处理方式

1. 查询 processor 的 delayed capture 规则

先确认当前 payment processor 是否支持在 7 到 14 天后 capture，并核实：

authorization 的 capture deadline；
超时 capture 是否会被拒绝；
是否会被标记为 late presentment；
是否可能产生更高的 processing fee 或 interchange downgrade；
是否支持 authorization extension、incremental authorization 或 reauthorization；
超时后是否必须创建新的 authorization。

判断时应以实际 processor/acquirer 的文档和合同为准，不能只看 issuer response。

2. 尽量在临近发货时授权

如果库存和业务流程允许，可以在 checkout 时保存 payment method，不要立即对全额进行长期授权。流程可以这样安排：

checkout 时完成 payment method tokenization；
必要时进行零金额或小金额验证，是否支持取决于 processor；
备货完成并准备发货时，创建正式 authorization；
发货前完成 capture；
如果支付失败，暂停发货并通知客户更新付款方式。

这样能明显降低授权在履约期间失效的风险。保存 payment method 时，应使用 processor 提供的 token，不要自行保存 PAN 或 CVV。CVV 通常不得在授权后存储。

3. 必须在 checkout 授权时，建立重新授权流程

如果业务要求在下单时确认客户有足够额度，应记录授权时间，以及 processor 返回的所有期限字段，并在临近 capture 时查询授权状态。超过内部设定的安全期限后，应重新进行 authorization，不要继续依赖旧授权。

重新授权成功后，还应按照 processor 的要求撤销旧授权，避免客户同时看到两笔资金冻结。

代码示例

下面是与具体支付服务商无关的伪代码。字段名称仅用于说明流程，不能直接视为某个真实 API 的参数。

async function authorizeOrder(order, paymentMethodToken) {
  const authorization = await processor.authorize({
    amount: order.totalAmount,
    currency: order.currency,
    payment_method: paymentMethodToken,
    capture: false,
    merchant_reference: order.id
  });

  await db.orders.update(order.id, {
    authorization_id: authorization.id,
    authorization_code: authorization.authorization_code,
    authorized_at: authorization.created_at,

    // 仅在 processor 明确返回并定义该字段时保存。
    capture_deadline: authorization.capture_deadline ?? null,

    payment_status: "authorized"
  });

  return authorization;
}

发货前不要只检查本地推算的日期，还应查询 processor 中的实际交易状态：

async function captureBeforeShipment(order) {
  const authorization = await processor.getAuthorization(
    order.authorization_id
  );

  if (authorization.status === "authorized" &&
      authorization.capture_allowed === true) {
    return processor.capture({
      authorization_id: authorization.id,
      amount: order.totalAmount
    });
  }

  const newAuthorization = await processor.authorize({
    amount: order.totalAmount,
    currency: order.currency,
    payment_method: order.paymentMethodToken,
    capture: false,
    merchant_reference: `${order.id}-reauth`
  });

  if (newAuthorization.status !== "authorized") {
    throw new Error("Payment authorization failed; shipment must be paused.");
  }

  if (authorization.reversal_allowed === true) {
    await processor.reverseAuthorization({
      authorization_id: authorization.id
    });
  }

  return processor.capture({
    authorization_id: newAuthorization.id,
    amount: order.totalAmount
  });
}

实际系统还需要做好幂等处理，避免网络重试导致重复 authorization 或重复 capture：

await processor.capture(
  {
    authorization_id: authorization.id,
    amount: order.totalAmount
  },
  {
    idempotency_key: `capture:${order.id}:${authorization.id}`
  }
);

capture_deadline、capture_allowed、reversal_allowed 和 idempotency_key 都是示意名称。实现时必须替换为所用 processor 的真实字段和接口。

注意事项

不要把 authorization code 当作授权仍然有效的证明。它只能说明授权请求在当时获得了批准。
不要自行认定所有授权都会在固定的 7 天、14 天或其他期限后失效。
gateway 返回的 expiration 字段不一定来自 issuer，需要确认该字段的准确含义和时区。
即使首次授权成功，后续 reauthorization 仍可能因额度变化、卡片冻结或风控而失败。
重新授权前后需要妥善处理旧授权的 reversal，避免重复冻结客户额度。
processor 和业务类型不同，对 capture 金额、部分 capture、多次 capture 及增量授权的支持也会不同。
授权超期后强行 settlement，可能导致交易被拒、费率降级或产生争议。
只有 capture 成功并得到 processor 的明确确认后，订单才能进入可发货状态。

对于 7 到 14 天的履约周期，不要等待 issuer 返回一个统一的到期日期。应以 processor 的 capture 规则为准，并建立“临近发货授权”或“到期前重新授权”的完整流程。