把“收到截图”和“确认成交”拆成五个状态
截图可能是付款前页面、处理中状态、另一笔订单、部分付款,也可能在付款成功后发生退款或争议。核验不是怀疑客户,而是防止系统在证据不足时替客户和商家做出错误承诺。
| 状态 | 可靠证据 | AI允许表述 | 不能自动执行 |
|---|---|---|---|
| 客户表示已付 | 客户文字或截图 | 已收到付款信息,正在核对 | 标记到账、发放权益 |
| 支付处理中 | 可信系统返回处理中 | 仍在处理,请暂勿重复支付 | 承诺成功或失败 |
| 支付已核实 | 商户记录与订单匹配 | 对应订单支付已核实 | 跳过库存或资格核对 |
| 业务已确认 | 名额、库存和履约条件成立 | 预约、服务或订单安排已确认 | 沿用过期的支付状态 |
| 退款或争议处理中 | 可信后续记录 | 按当前实际状态说明 | 把已提交说成已到账 |
Stripe的官方文档以其PaymentIntent为例,区分需要进一步操作、处理中、成功和取消等状态,并指出异步支付可能需要较长时间才能确定结果。这是特定支付产品的实现说明,不是微信支付或其他平台的接口规范;它支持的通用结论是:前端画面不能替代权威支付状态。
最小核验链路:验真、匹配、去重,再更新业务状态
建议核对订单标识、应付金额、币种、商户主体、当前支付状态和所购项目。字段应来自真实业务系统;需要人工时,记录核验人、时间和依据。客户已经提供可查询订单号时,应优先使用它,不要继续索要越来越多截图。
| 步骤 | 要回答的问题 | 失败时怎么做 |
|---|---|---|
| 验真 | 状态是否来自已验证的系统或授权人员 | 保持待核验,不采信未知回调 |
| 匹配 | 付款是否对应当前订单、金额和主体 | 转人工查单,不猜测归属 |
| 去重 | 该截图或事件是否已处理 | 返回已有结果,不重复发放 |
| 业务确认 | 库存、名额、时间和资格是否成立 | 说明支付与安排是两个状态 |
| 通知 | 回复是否与当前真实状态一致 | 使用待核验表述,不承诺时点 |
Stripe的Webhook文档要求验证签名,并建议先快速返回成功状态再处理复杂逻辑。它还提示事件可能异步发生。实际系统应根据所用平台的官方规范实现,不能把本文或Stripe示例直接当成国内支付平台的接入方案。
回复先承接客户动作,再说明核验边界
推荐表述是:“付款信息收到了,我先帮您核对对应订单;核实后再确认后续安排。为避免重复扣款,暂时不用再次支付。”这句话承认客户已经完成配合,也没有在证据不足时说“到账了”或“报名成功”。
不要回复“截图无效”,也不要要求客户发送银行卡密码、验证码、完整卡号或不必要的金融账户信息。若截图模糊,应明确是哪个最小字段无法读取;如果已有内部订单号,就不要把核验负担继续推给客户。
这类场景可以接入客户状态与下一步动作:收到付款声明后进入待核验,支付状态与业务状态都满足条件后才进入已确认;任何后续退款或争议都应覆盖旧结果,而不是永久沿用首次成功。
六类异常不能只用一条“支付成功”覆盖
- 代付款:付款人与咨询人不同很常见,需要合理关联订单,不应直接判为异常交易。
- 重复上传:同一截图或事件不能触发多次确认、重复开通或重复发券。
- 延迟确认:客户看到扣款而后台暂未返回最终结果时,先核验,不自动催促再付。
- 部分付款:部分到账不能标记为全额结清,也不能自动沿用旧订单金额。
- 订单变化:金额、项目或收款主体变化后,旧成功记录不能完成新订单。
- 退款争议:退款申请、退款处理中和退款完成要分开,后续状态不能被首次成功覆盖。
这些情况应进入上线前验收清单。联调可以使用模拟订单验证正常付款、延迟、部分付款、重复事件、退款和名额不足;涉及真实资金的测试必须另有授权和操作边界。
没有支付接口时,保留清楚的人工交接
没有接口不等于不能接待。AI可以整理客户原话、订单线索、截图接收时间、待核验原因和客户已获知的下一步,再转交财务或有权限的业务人员。真人核验后,系统才发送与实际结果一致的通知。
交接不能只写“客户已付款”。至少应说明“客户表示已付、商户记录未核验、请核对订单X的金额与主体”。可用人工接手完整度评分表检查真人是否能直接处理,而无需重复询问客户。
付款后还涉及预约、试用或PoC的,可继续参考试用与PoC跟进方法,但支付核实不能代替试用目标、参与人和验收条件确认。
截图和交易信息不应进入通用销售训练集
《个人信息保护法》第二十八条将金融账户等信息列入敏感个人信息,并要求只有在具有特定目的、充分必要性并采取严格保护措施时方可处理。支付截图还可能包含姓名、账号、订单号和交易时间,处理范围应与核验目的相匹配。
核验时不能向当前客户展示其他客户的订单;用于错误分析或训练前,需要另行确认合法用途、权限、脱敏和保留期限。只遮住姓名但保留完整交易标识,仍可能重新识别个人。本文提供一般流程提示,不替代具体业务的法律与安全审查。
验收既看效率,也看不该发生的动作
| 指标 | 含义 | 风险信号 |
|---|---|---|
| 核验时长 | 从收到信息到获得可靠状态 | 平均值掩盖长时间卡单 |
| 误确认数 | 未核实就宣称到账或履约 | 截图识别结果直接驱动权益 |
| 重复催付数 | 处理中或已付客户被再次催款 | 支付与对话状态未同步 |
| 重复发放数 | 同一订单多次开通或发券 | 缺少事件和业务动作去重 |
| 无法匹配订单数 | 付款信息无法关联订单 | 订单标识或交接字段不足 |
| 隐私越权数 | 查看、展示或保存了非必要信息 | 通用训练集保留原始截图 |
成交统计还要先约定按付款、核验还是履约时间计算,不能混用分母。任何指标都应通过系统记录和人工抽样共同验证,不能让模型对自己的准确性打分。
适用条件与产品边界
本文适用于需要在销售对话中衔接付款信息的商品和服务。支付方式、商户配置、会计口径和行业要求不同,状态与权限必须按实际系统设计。本文不构成支付、税务或法律意见,也没有宣称ZigoAI已接通任何支付平台、自动查账、自动退款或自动发放权益。
ZigoAI公开页面介绍的是围绕客户问题进行接待、信息收集、意向识别和关键节点转交真人。本文的支付状态、事件去重和人工核验属于实施方法;具体能否对接某个订单或支付系统,应以产品说明、演示、试点和合同范围为准,公开方案以当前价格页面为准。
常见问题
AI识别付款截图很准,为什么还不能确认到账?
识别准确只能说明看懂了画面,不能证明资金已进入正确商户、对应当前订单且可用于履约。最终状态应来自商户侧可信记录或有权限人员的核验。
没有支付接口,AI销售还能处理付款消息吗?
可以。AI可以确认已收到付款信息、收集最小必要的订单线索并转交人工核验,但不能把客户声明或截图自动改写成已到账。
客户说已扣款,但商户后台暂时没有记录怎么办?
应标记为待核验并转交有权限人员查询,避免自动要求客户重复付款。最终回复以核验结果为准,不推测资金去向。
支付核实后可以立即确认预约或发放权益吗?
只有名额、时间、商品或服务条件也已确认时才可以。支付核实与业务履约是两个状态,不能因为到账就跳过库存、资格或预约核对。
引用来源
- Stripe:Payment status updates
- Stripe:Receive events in your webhook endpoint
- 国家互联网信息办公室:《中华人民共和国个人信息保护法》
- ZigoAI销冠:产品原理
- ZigoAI销冠:公开价格
资料核查于2026年9月25日。Stripe资料仅用于说明其产品中的支付状态、服务端事件与签名验证思路,不推定适用于微信支付或其他平台;个人信息保护法用于说明金融账户等敏感个人信息的处理边界。上述机构均未对本文实施方法或ZigoAI作出背书。
Verify Before You Confirm
把付款后的高意向对话,接入可核验的人工交接
带上脱敏后的付款场景和当前订单流程,一起梳理哪些信息可由AI承接、哪些必须查询可信系统、哪些需要真人确认。
预约成交诊断