支付方式评审（Payment Method Review）把支付方式的收入、待处理订单（on-hold）管道、失败订单数量、支付方式集中度、支付标签覆盖和网关设置背景，整理成一份面向商户的简明评审。它不是支付处理商事故报告、结账漏斗分析、付款后冲正分析，也不是预订前旅程研究。
默认范围 若用户未指定日期范围，默认使用最近 30 天并开启对比。对自定义范围应传入确切的开始与结束日期，而不是近似到最近的时间段。对比基准为上一个对应时段。
评审时将以下几类数据分开看待：
- 已收款收入：所选时段内已完成和处理中的订单，按支付方式标签分组。
- 待处理管道：所选时段内下单但等待付款的订单，不属于已收款收入，也不自动等于损失收入。
- 失败订单：所选时段内的失败订单数量与金额，属于结账风险，不等于已收款收入、预订前购物车活动、付款后冲正或处理商事故。
- 支付设置背景：当前店铺资料与 WooCommerce 支付设置是即时状态，而分析数据是按时间段界定的。
主要能力 技能会读取店铺资料，获取店铺名称、货币、地区和结账设置背景；按支付方式拉取已收款收入数据，读取总已收款收入、已付款订单数、客单价、覆盖率、支付方式行、收入占比、退款金额与比率、各行的待处理管道、对比字段以及掉出的支付方式；再拉取订单与管道诊断，读取已付款、待处理、待定、失败、已取消、已完成和处理中等状态计数，以及管道订单数/金额、最久待处理时长、时长分桶和管道支付方式行；随后拉取待处理订单聚合和失败订单聚合，必要时再加取对比时段的聚合值，用于当前与上期的数量/金额对照。如果某支付方式有显著管道，或类似卡类方式出现在待处理管道中，且这有助于实际检查，才会拉取渠道背景，仅用于观察待处理管道是否集中在某个获客渠道，不会演变成广告效果或转化分析。只有商户明确要求追查具体订单时，才会以行模式列出订单，并对客户信息做假名化处理，不暴露姓名、邮箱、电话或地址。若调用跨越超过 365 天，需走扩展范围审批流程，不得拆分范围绕过限制。
解读规则 评审以支付方式表现开头，而非泛泛的收入回顾。移动幅度使用返回的对比字段，不自行手算差值、百分比、占比、平均值、比率、超指数点、失败订单比率、支付组合变化或集中度指标；支付方式占比直接使用返回字段，不用某方式收入除以总收入来构造自己的分母。已收款收入、待处理管道、失败订单和仪表盘匹配数据要分开处理。待处理管道视为等待付款，不是已收款收入，也不是未实现收入；银行转账、支票、发票、直接借记等手动方式在付款清算期间合法地停留在待处理状态。类似卡类的网关出现在待处理订单上是一个检查信号，不是网关事故的证明。失败订单视为结账风险，只陈述失败了什么、有多少，不主张失败原因。失败订单跟进建议为“抽查订单备注和网关日志中的重复消息”，不引导查看处理商原因码或风险筛查模式，除非商户提供处理商证据。即使是否定式表述，也避免点名不受支持的原因；若原因细节不可用，直接说“数据不含原因级别的支付细节”。比较失败或待处理聚合时使用“较大”“较小”“相近”等中性措辞并引用两个值，避免“轻微”“显著”“激增”等幅度标签。不得仅凭集中度、待处理管道、失败状态计数或空白标签就称某方式损坏、故障、宕机、配置错误或导致失败，应表述为“检查”“复核”“核实”“查看”。退款金额与退款率是诊断信号，不是某方式导致退款、处理商冲正、风险筛查问题或不满的证明。小样本需用小样本语言：若某项支付方式结论基于 5 笔或更少的订单、待处理、失败或退款，应先说明数量再解读百分比或变化。最终答复不得提及工具名、能力名、参数名、数据库表、内部字段路径、过滤器 JSON、状态别名或原始字段名，应翻译为“支付方式”“已收款收入”“订单”“待处理金额”“状态构成”“已收款收入占比”“在待处理管道中超指数”等商户语言，也不建议构建新的技能、端点、连接器或插件功能。
输出结构 评审以“Payment Method Review”为标题，包含店铺、时段、对比时段；然后是快照（两到三句，覆盖领先支付方式、已收款收入集中度、待处理管道或失败订单是否需要关注、标签是否完整到足以信任评审，样本太小则直言）；已付款支付组合（按已收款收入列出主要支付方式，含已收款收入、已付款订单数、客单价、收入占比、对比变化和退款率）；集中度与变化；待处理管道；失败订单；支付标签覆盖；网关与后台检查（两到三项）；下一步行动（三项可在 WooCommerce 后台、支付设置、网关仪表盘/日志、订单跟进、结账设置、风险筛查设置或银行转账说明中完成的具体步骤）。语气平静、运营导向、贴合商业实际，让商户看完后知道哪些支付方式承载已收款收入、支付管道哪里需要检查、失败订单能证明什么和不能证明什么，以及今天可做哪些支付管理动作。