如何将 Inline Checkout 与 Amazon Cart 集成？

2026-10-24支付老李

结论

Inline Checkout 不能直接嵌入或绑定到 Amazon Checkout Cart。它们是两套独立的结账流程。Amazon Checkout Cart 的购物车状态、结账页面和订单创建过程均由 Amazon 托管，通常不会向 Inline Checkout开放可复用的购物车接口。

如果还要使用 Amazon Fulfillment 履约，可以由商家网站管理购物车，通过 Inline Checkout 完成支付和订单确认，再由服务端将订单提交给相应的 Amazon 履约服务。支付结账和仓储履约需要分开处理，不能把两个 checkout 产品直接串联起来。

Amazon Checkout、Inline Checkout 和部分早期 Amazon Payments/Fulfillment 接口都是历史产品。能否继续使用，要看账号所在地区、已经开通的产品，以及 Amazon 是否仍为该账号保留相关接口。

为什么不能直接集成

Amazon Checkout Cart 不只是前端购物车组件，还负责传递商品信息、确认订单、收款和管理订单状态。Inline Checkout 也需要控制结账流程，因此两者无法顺畅衔接：

Inline Checkout 不能直接读取 Amazon Checkout Cart 中的商品和数量。
两套流程都会尝试创建订单并确定订单金额。
买家地址、税费、运费和促销信息可能由两边分别计算，导致结果不一致。
Amazon Checkout Cart 通常没有标准接口，可以把现有购物车会话转交给另一个 checkout 产品。

Amazon Fulfillment 只是一种履约方式，并不要求商家必须使用 Amazon Checkout Cart。只要账号和相关接口允许，商家创建的订单也能在支付成功后交给 Amazon 履约。

推荐的实现方式

1. 在商家网站维护购物车

商品 SKU、数量、价格和优惠信息应保存在商家自己的前端或服务端，不再由 Amazon Checkout Cart 保存购物车状态。

const cart = [
  {
    sku: "SKU-10001",
    name: "示例商品",
    quantity: 2,
    unitPrice: 29.90
  }
];

const total = cart.reduce(
  (sum, item) => sum + item.quantity * item.unitPrice,
  0
);

前端计算的金额只能用于展示。创建订单时，服务端必须重新读取可信的商品价格并计算最终金额，不能直接采用浏览器提交的总价。

2. 通过 Inline Checkout 完成结账

把商家购物车中的订单金额和必要信息传给 Inline Checkout，并使用账号实际开通产品所对应的官方 SDK 或 API。

不同地区和历史版本使用的接口名称差异较大，不能只凭 “Inline Checkout” 这个名称确定初始化函数和参数。应先在商家后台确认：

Inline Checkout 对应的正式产品名称；
当前账号可用的 SDK 或 API；
支持的币种和地区；
支付成功、取消和失败的回调机制；
服务端验证订单状态的方法。

示例中的商品总价不能直接作为可信的支付金额。通常应先由服务端创建本地订单，再生成结账所需的数据。

async function startCheckout(cart) {
  const response = await fetch("/api/orders", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      items: cart.map(({ sku, quantity }) => ({ sku, quantity }))
    })
  });

  if (!response.ok) {
    throw new Error("Unable to create order");
  }

  const checkoutData = await response.json();

  // 在这里调用账号实际支持的 Inline Checkout SDK。
  // 不应假设某个历史 SDK 的函数名仍然有效。
  return checkoutData;
}

3. 在服务端确认支付结果

浏览器跳转到成功页面，不代表支付已经完成。服务端应通过签名回调、通知事件或订单查询接口确认支付状态，确认无误后再进入履约流程。

app.post("/payment/callback", async (req, res) => {
  // 1. 验证回调签名或消息真实性
  // 2. 使用支付平台返回的订单标识查询最终状态
  // 3. 检查金额、币种和本地订单是否一致
  // 4. 采用幂等方式更新订单，避免重复履约

  res.sendStatus(200);
});

这段代码只用于说明服务端的处理结构，不代表 Amazon 某个具体产品的真实回调路径或参数名称。

4. 将已付款订单提交给 Amazon Fulfillment

确认支付后，服务端根据本地订单生成履约请求，通常需要包含：

商家订单号；
Amazon 可识别的库存 SKU；
每个 SKU 的发货数量；
收件人姓名和地址；
配送速度；
必要的税务或报关信息。

创建正式履约订单前，建议先检查库存并获取履约费用。具体使用哪套接口取决于账号类型。历史账号可能仍在使用旧版 Amazon Marketplace Web Service；较新的集成则通常需要查看 Selling Partner API 中适用于该业务的履约能力。旧接口的操作名称和参数不能直接套用到新接口。

整体流程如下：

商家购物车
    ↓
创建本地订单
    ↓
Inline Checkout
    ↓
服务端验证支付结果
    ↓
创建 Amazon 履约订单
    ↓
同步发货状态和物流信息

实现时的注意事项

不要重复创建订单

支付通知可能重复发送，网络超时也可能触发客户端重试。创建履约订单时，应使用稳定且唯一的商家订单号，并在数据库中记录履约请求的状态。

不要提前发货

只有服务端确认支付已经达到可履约状态，才能提交履约请求。前端成功回调、返回页面中的参数以及客户端保存的状态，都不能单独作为发货依据。

保持 SKU 一致

商家系统中的 SKU 必须能够映射到 Amazon 履约库存中的 SKU。如果两套系统使用不同的标识，需要建立明确的映射表，并在创建履约订单前校验库存。

正确处理失败和取消

如果支付成功但履约失败，应把订单设为待处理状态，再由后台重试或转交人工处理，不能盲目重复提交。履约订单取消、缺货、地址无效和部分发货也需要分别处理。

先确认产品是否仍可用

如果商家后台已经找不到 Inline Checkout 或 Amazon Checkout Cart 的开发文档，通常说明产品已经停止新接入、只向旧账号开放，或已更换名称。这种情况下，无法通过前端代码强行完成集成。应以当前账号可见的产品和官方接口为准，重新采用 “自有购物车 + 当前支付方案 + Amazon 履约” 的结构。