支付宝与1688互通小程序如何通过推广二维码审核

2026-10-24支付小周

结论

不要让审核人员使用普通商家的动态推广二维码，也不要通过“模拟支付成功”绕过验证。建议单独提供一个长期有效的审核入口，固定绑定审核专用商家、测试商品和可支付订单，并在审核备注中说明账号、操作路径、跳转至 1688 收银台的条件和回跳结果。

如果 1688 针对当前业务提供沙箱或联调环境，应优先使用官方测试支付链路。如果审核环境不支持沙箱，则需要准备低金额真实订单，并提前确认审核人员能否访问 1688 收银台及完成付款。录屏和接口截图通常只能作为补充材料，不能代替审核人员实际操作验证。

为什么普通推广二维码不适合审核

商家自行生成的二维码通常带有动态商家参数。审核人员扫码后可能遇到以下情况：

二维码绑定普通测试账号，只能查看基础数据；
商家没有可购买的商品，或者商品、库存、配送地址不完整；
创建订单需要特定账号权限；
支付前必须登录 1688，审核账号无法继续操作；
二维码过期、参数失效，或者商家在审核期间重新生成了二维码；
支付跳转依赖来源参数，直接进入小程序时缺少必要的上下文；
支付后无法正常返回小程序，审核人员看不到最终订单状态。

审核入口不需要模拟所有商家，但必须提供一条稳定、完整且可以重复执行的业务链路。

推荐的审核方案

1. 建立审核专用商家和商品

在业务后台创建独立的审核商家，例如 audit_demo_merchant，并准备以下内容：

一个长期有效的测试商品；
明确的库存、价格和商品状态；
可用的收货地址或虚拟履约方式；
审核专用买家账号；
可重复创建订单的能力；
对支付成功、取消支付和支付失败的状态处理。

如果使用真实支付，建议把商品价格设为业务允许的最低合理金额。不要擅自设置 0.01 元商品。能否使用低金额交易，应以平台规则和实际业务限制为准。

2. 生成固定审核二维码

审核二维码应始终进入同一个审核场景，不能依赖普通商家的临时数据。二维码参数可以包含审核场景标识，但服务端必须对其进行校验，不能只凭前端参数开放特殊能力。

例如，二维码可以携带以下参数：

page=pages/product/detail
query=scene=audit_demo&merchantId=audit_demo_merchant&token=SIGNED_TOKEN

二维码的具体生成接口和参数格式，应以当前支付宝小程序后台及相关官方文档为准。不要直接使用可伪造的 isAudit=true 作为审核身份依据。

3. 服务端识别并校验审核场景

服务端需要验证二维码中的签名、有效期及允许访问的商家范围。

import crypto from 'node:crypto';

function verifyAuditScene({ scene, merchantId, expiresAt, signature }, secret) {
  if (scene !== 'audit_demo') {
    return false;
  }

  if (merchantId !== 'audit_demo_merchant') {
    return false;
  }

  if (!Number.isFinite(Number(expiresAt)) || Date.now() > Number(expiresAt)) {
    return false;
  }

  const payload = `${scene}:${merchantId}:${expiresAt}`;
  const expected = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');

  const actualBuffer = Buffer.from(signature || '', 'utf8');
  const expectedBuffer = Buffer.from(expected, 'utf8');

  return (
    actualBuffer.length === expectedBuffer.length &&
    crypto.timingSafeEqual(actualBuffer, expectedBuffer)
  );
}

审核场景只能固定测试数据和操作入口，不能伪造订单状态，也不能跳过真实的下单、支付通知或订单查询流程。

4. 提供完整的支付验证链路

审核人员需要能够按顺序完成以下操作：

扫描审核二维码；
进入审核专用商品页；
确认商品、数量和金额；
创建真实的测试订单；
点击支付；
跳转至 1688 收银台；
完成或取消支付；
返回小程序；
查看最终订单状态。

创建订单时，建议由服务端生成业务订单号，并处理好重复点击，避免产生大量难以管理的订单。

async function createAuditOrder(userId) {
  const product = await productService.getByCode('AUDIT_DEMO_PRODUCT');

  if (!product || product.status !== 'ON_SALE') {
    throw new Error('审核商品当前不可购买');
  }

  const order = await orderService.create({
    userId,
    merchantId: 'audit_demo_merchant',
    productId: product.id,
    quantity: 1,
    amount: product.price,
    source: 'MINI_PROGRAM_AUDIT'
  });

  const cashierResult = await paymentService.create1688CashierOrder({
    orderNo: order.orderNo,
    amount: order.amount,
    subject: product.name,
    returnUrl: buildReturnUrl(order.orderNo)
  });

  return {
    orderNo: order.orderNo,
    cashierUrl: cashierResult.cashierUrl
  };
}

这里的 create1688CashierOrder、请求字段和返回字段只是业务封装示例，不是 1688 官方接口名称。实际实现必须使用项目已经接入的开放平台接口，并按照官方要求处理签名、授权和回调。

5. 支付结果以服务端为准

从 1688 收银台返回小程序后，不能只根据前端回跳参数把订单标记为支付成功。应按以下方式处理：

服务端接收并验证支付通知；
必要时主动查询支付结果；
前端返回结果页后轮询订单状态；
超时后显示“支付结果确认中”，并允许用户刷新。

async function waitForPaymentResult(orderNo) {
  const maxAttempts = 10;

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await my.request({
      url: `/api/orders/${encodeURIComponent(orderNo)}/status`,
      method: 'GET'
    });

    if (response.data.status === 'PAID') {
      return 'PAID';
    }

    if (response.data.status === 'CLOSED') {
      return 'CLOSED';
    }

    await new Promise(resolve => setTimeout(resolve, 1500));
  }

  return 'PROCESSING';
}

示例中的 /api/orders/.../status 是项目自有接口，需要根据实际后端地址调整。

如果审核人员无法完成真实付款

先确认具体障碍，再选择相应的处理方式。

1688 提供可用的测试支付环境

将审核专用账号、商品和订单接入该环境，并在审核说明中写明：

测试账号；
登录方式；
测试支付凭据；
支付步骤；
预期结果；
测试数据是否会自动清理。

沙箱能力、账号申请方式以及能否用于小程序审核，都必须以当前平台实际提供的能力为准。

1688 没有可用于审核的测试支付环境

准备低金额真实订单，并确认以下事项：

收银台能在审核设备上打开；
不要求审核人员使用开发者的个人账号；
不要求审核人员自行注册特殊企业账号；
订单可以退款或自动关闭；
审核备注明确说明会发生真实扣款；
方案符合支付宝、1688及所属行业的交易规则。

不要向审核人员提交开发者的支付密码、短信验证码或个人支付账户。

审核人员客观上无法访问收银台

应通过审核后台备注、工单或平台支持渠道，提前说明跨平台支付依赖，并提交以下辅助材料：

从扫码进入到支付完成的连续录屏；
1688 收银台跳转页面；
支付回调日志；
服务端订单查询结果；
支付前后的订单状态对比；
测试账号和复现步骤。

这些材料可以帮助审核人员了解完整链路，但能否代替现场支付验证，取决于当前审核规则，不能提前保证。

审核备注可以这样写

审核入口：请扫描提交的“审核专用二维码”。

测试路径：
1. 扫码进入审核专用商品页；
2. 点击“立即购买”；
3. 使用页面预置的测试地址提交订单；
4. 点击“去支付”，页面将跳转至 1688 收银台；
5. 完成或取消支付后返回小程序；
6. 在订单详情页查看支付结果。

审核商家：audit_demo_merchant
审核商品：审核专用测试商品
测试账号：按审核后台安全方式提供
预计金额：以页面实际展示为准

说明：
支付由 1688 收银台处理，小程序不会在前端伪造支付结果。
支付完成后，订单状态可能需要短暂同步，可在订单详情页点击刷新。
如审核环境无法访问 1688 收银台，请通过审核反馈渠道联系我们，并参考随审材料中的完整支付录屏和订单状态记录。

注意事项

审核二维码的有效期应覆盖整个审核周期，不要设置得过短。
审核数据不要依赖定时任务频繁重置，以免在审核期间消失。
二维码参数必须经过服务端签名校验，防止审核入口成为越权入口。
审核模式不能直接返回“支付成功”，也不能绕过支付通知验证。
如果需要登录 1688，应提前提供合规的审核账号和登录说明。
提交前，应在未登录、弱网和重新扫码等情况下完整测试流程。
支付成功、用户取消、重复点击和回跳失败等情况都需要验证。
不要在审核说明中填写密码、支付口令、密钥或短信验证码等敏感信息。
跨平台跳转方式、允许打开的域名和页面承载方式，应以当前支付宝及 1688 的开放平台规则为准。

建议采用“固定审核二维码 + 审核专用商家和商品 + 可执行的支付环境 + 服务端真实验签和查单 + 清晰审核说明”的方案。这样既能保留商家自行生成推广二维码的正式业务模式，也能让审核人员获得一条不受动态商家数据影响的完整验证路径。