销售数字商品时如何确认用户的真实身份？

结论

验证 e-mail 和手机号码有必要，但这只能证明用户可以访问某个邮箱和号码，既不能确认用户的真实身份，也不能证明最终在 ATM 付款的人就是下单者。

这类欺诈通常不是账户被盗，而是付款 reference 被转交给了第三方。增加 SMS 验证可以提高作案成本，却无法彻底阻止攻击。更可靠的方案需要同时做到：

• 发放付款 reference 前验证联系方式；
• 绑定订单、付款人和数字商品领取账户；
• 对异常订单采取限额、延迟交付或人工审核；
• 支付机构能够返回付款人信息时，将其与订单资料进行匹配；
• 对高风险订单使用实名/KYC，而不是继续增加普通验证码。

如果支付系统完全不提供付款人身份，商家就无法根据一笔 ATM reference 入账确认付款人的真实身份。这个信息缺口来自支付渠道，网站无法百分之百补足。

为什么 e-mail 和 SMS 仍然有用

e-mail 验证可以排除无效地址，确保订单通知、风险提醒和数字商品能够发送到一个可访问的邮箱。

SMS 验证也会增加攻击者的成本：

• 攻击者需要准备能接收验证码的号码；
• 批量注册和生成 reference 会更困难；
• 同一号码关联多个账户时更容易暴露；
• 结合国家代码、号码信誉和频率限制，可以过滤一部分低成本攻击。

不过，不能把 email_verified 或 phone_verified 视为”实名状态”。攻击者仍可使用临时邮箱、预付费 SIM、虚拟号码或他人的号码。更合理的状态设计是：

email_verified = 能访问该邮箱
phone_verified = 能访问该号码
identity_verified = 身份经过独立核验
payer_matched = 支付机构返回的付款人与订单身份匹配

这些状态各自代表不同的验证结果，不能互相替代。

优先确认支付系统能够提供什么

先联系支付机构或收单机构，确认付款完成后的通知能否提供以下信息：

• 付款账户持有人姓名；
• 付款账户或银行卡的脱敏标识；
• ATM、银行或支付渠道标识；
• 付款时间、金额和交易 ID；
• 能否限制付款人、设置付款用途或显示商户名称；
• 是否支持撤销、冻结、延迟结算或欺诈申诉；
• 是否允许在 ATM 页面显示订单说明或反诈骗提示。

如果能取得可靠的付款人姓名或账户标识，可以将其与订单实名资料进行匹配。姓名不一致时，应暂停交付并转入人工核实。

如果回调中只有 reference、金额和时间，商家只能确认”有人支付了这张订单”，不能确认”下单者本人支付”。这种渠道应被视为无法验证付款人的高风险支付方式。

推荐的下单流程

1. 验证联系方式后再生成 reference

建议采用以下顺序：

创建账户
  → 验证 e-mail
  → 验证手机号码
  → 风险评估
  → 生成短时有效的付款 reference
  → 收到支付通知
  → 核对付款数据
  → 交付或转入人工审核

未验证的账户不应获得付款 reference，否则攻击者仍能低成本批量获取 reference，再将其用于分类广告平台。

验证码应满足基本的安全要求：

• SMS 验证码应在短时间内失效，例如 5～10 分钟；
• 每个验证码只能使用一次；
• 限制每个 IP、设备、账户和号码的发送次数；
• 连续输错后暂时锁定；
• 日志中不记录明文验证码；
• 拒绝明显的虚拟号码时，为正常用户保留申诉渠道；
• reference 也应设置合理的有效期。

2. 明确显示付款对象和反诈骗警告

生成 reference 前，让用户确认类似内容：

此 reference 只能用于购买本站订单中的数字商品。不要将其用于购买手机、门票或分类广告中的其他商品。付款后，数字商品只会交付到当前已验证账户。

付款说明、e-mail 和 SMS 中还应显示：

• 商户名称；
• 订单号；
• 商品类型；
• 金额；
• reference 有效期；
• “不要代陌生人付款”的警告。

这些提示无法阻止蓄意欺诈，但可能让受害者在 ATM 付款前发现收款方与广告卖家并不一致。如果支付机构允许在 ATM 屏幕上显示商户名称或付款用途，效果通常比只在网站上提示更好，因为真正付款的人未必访问过商家网站。

3. 不要立即交付高风险订单

数字商品通常无法追回，即时交付会扩大损失。可以根据订单风险采取不同的处理方式：

具体延迟多久，需要结合正常用户体验和实际欺诈窗口决定，不能假定某个固定时长一定有效。

4. 对高风险交易实施实名验证

如果业务确实需要确认客户身份，应使用正规的身份核验服务，例如：

• 检查身份证件的真实性；
• 进行活体检测；
• 匹配姓名、出生日期和证件资料；
• 在法律允许的情况下，将付款人资料与实名资料匹配。

让用户手工上传身份证照片并由商家自行保存，通常并不理想。这会带来证件泄露、伪造识别、访问控制和数据保留等风险。应优先选择符合当地法律要求的专业 KYC 服务，并尽量只保存核验结果和必要标识。

实名验证可以只用于高金额、新账户或风险评分超过阈值的订单，无须要求所有客户提交证件。

一个可落地的风险控制示例

下面是一段简化的服务端伪代码。联系方式验证只是生成 reference 的前置条件，支付完成后还要单独判断能否交付。

type OrderRiskInput = {
  emailVerified: boolean;
  phoneVerified: boolean;
  accountAgeHours: number;
  orderAmount: number;
  ipCountry?: string;
  phoneCountry?: string;
  deviceOrderCount24h: number;
  phoneAccountCount: number;
  payerNameMatched?: boolean;
};

function calculateRisk(input: OrderRiskInput): number {
  let score = 0;

  if (!input.emailVerified) score += 100;
  if (!input.phoneVerified) score += 50;
  if (input.accountAgeHours < 24) score += 20;
  if (input.orderAmount >= 100) score += 20;
  if (
    input.ipCountry &&
    input.phoneCountry &&
    input.ipCountry !== input.phoneCountry
  ) {
    score += 15;
  }

  if (input.deviceOrderCount24h > 3) score += 30;
  if (input.phoneAccountCount > 1) score += 25;
  if (input.payerNameMatched === false) score += 100;

  return score;
}

function decideOrderAction(input: OrderRiskInput) {
  const risk = calculateRisk(input);

  if (!input.emailVerified || !input.phoneVerified) {
    return { action: "DO_NOT_CREATE_REFERENCE", risk };
  }

  if (risk >= 100) {
    return { action: "REJECT_OR_MANUAL_REVIEW", risk };
  }

  if (risk >= 40) {
    return { action: "CREATE_REFERENCE_WITH_REVIEW", risk };
  }

  return { action: "CREATE_REFERENCE", risk };
}

这些分值不能直接照搬，需要根据真实订单、误报情况和历史欺诈记录调整。风险系统还应保留每条规则的命中原因，方便客服解释和人工复核。

支付回调可以用明确的状态机处理：

async function handlePayment(payment: PaymentNotification) {
  const order = await findOrderByReference(payment.reference);

  if (!order) {
    return markPaymentForInvestigation(payment, "UNKNOWN_REFERENCE");
  }

  if (order.status === "FULFILLED") {
    return;
  }

  if (payment.amount !== order.expectedAmount) {
    return holdOrder(order.id, "AMOUNT_MISMATCH");
  }

  if (
    payment.payerName &&
    order.verifiedLegalName &&
    !namesMatch(payment.payerName, order.verifiedLegalName)
  ) {
    return holdOrder(order.id, "PAYER_IDENTITY_MISMATCH");
  }

  const risk = await recalculateRiskAfterPayment(order, payment);

  if (risk.requiresReview) {
    return holdOrder(order.id, "POST_PAYMENT_RISK_REVIEW");
  }

  return fulfillToVerifiedAccount(order.id, order.accountId);
}

namesMatch() 不能只比较两个字符串是否完全相等。姓名可能存在空格、顺序、重音符号和缩写等差异。因实名不匹配而拒绝交易时，还应提供人工复核机制。

限制 reference 的滥用

在支付系统允许的范围内，可以对 reference 增加以下限制：

• 每个 reference 只对应一个订单；
• 设置较短的有效期；
• 付款成功后立即失效；
• 限制单个账户每天生成 reference 的数量；
• 未付款订单过多时，不再允许继续生成；
• 同一手机、设备或网络批量创建时触发审核；
• 不让 reference 出现在公开 URL、分析系统或第三方脚本中；
• 禁止客服向未核验账户重新发送或转移 reference。

随机调整付款金额的小数位有助于区分订单，但不能验证付款人的身份。攻击者可以把准确金额和 reference 一并发给受害者，因此这种方法不能充当身份验证。

要求付款后上传 ATM 小票通常也不可靠。受害者可能把小票交给攻击者，图片本身也可以修改。

商品交付也要绑定账户

数字商品只能交付到创建订单时已经验证的账户。付款后，不应允许用户临时更改收件 e-mail、手机号码或账户。

如果商品是许可证、余额或下载权限，可以采取这些措施：

• 绑定已验证账户；
• 暂时禁止新账户转移或赠送商品；
• 为高风险商品设置冷静期；
• 首次使用时再次验证账户；
• 保留订单、支付、领取和使用记录；
• 发生异常时冻结尚未消耗的权益。

这些措施可以增加攻击者获利和转卖的难度，但无法阻止无辜第三方向 reference 付款，因此仍需配合付款前警告和付款人核对。

证据留存与隐私

为了配合警方、支付机构和受害者处理案件，可以保留必要的审计信息：

• 账户创建及验证时间；
• reference 的创建、发送和失效时间；
• 登录 IP 和与安全有关的设备标识；
• 手机和 e-mail 的验证状态；
• 风险规则命中记录；
• 支付机构提供的交易 ID；
• 数字商品的领取和使用记录；
• 用户接受付款警告的时间和版本。

不能因为担心欺诈就无限期收集和保存身份证、完整手机号或设备指纹。数据收集范围、保存期限、跨境处理方式以及向警方披露信息的规则，取决于所在国家或地区的隐私、电子商务和反洗钱法律，应由当地律师或合规人员确认。

最实际的组合方案

如果现有的 ATM reference 支付方式无法更换，至少应落实以下措施：

1. 只有 e-mail 和 SMS 都验证成功，才能生成 reference。
2. 为 reference 设置有效期、数量限制和频率限制。
3. 在所有付款信息中明确显示商户名称、数字商品用途和反诈骗警告。
4. 对新账户、异常设备和高金额订单延迟交付或进行人工审核。
5. 尽可能从支付机构获取付款人信息，并与订单实名资料匹配。
6. 对高风险交易接入 KYC。无法核对付款人的订单不应自动交付。
7. 建立退款、证据保留、报警协作和异常账户封禁流程。

e-mail 和 SMS 验证是必要的基础控制，但防护强度主要取决于能否核对付款人，以及商家是否愿意暂停交付无法核对的高风险订单。如果支付渠道始终不披露付款人信息，就没有纯技术手段可以百分之百确认下单者与 ATM 付款者是同一个人。

备注：内容仅供参考。