美国销售税、拒付与争议风险
把美国销售税设置、高风险订单、手动 capture、拒付原因码、证据包和月度 fraud/dispute ratio 放进一套风控节奏。 这篇可以单独读，也可以作为利润、商品数据、广告、隐私、支付和客服之间的风险治理 handoff。
先说清楚：这篇可以单独读
如果你现在只遇到一个具体问题，比如支付审核、GMC 暂停、EU 资料不齐、cookie banner 不确定、拒付上升或促销上线前心里没底，可以直接从本课开始。
TrekCup 会作为本课案例。我们不把合规写成法律百科，而是把风险拆成 owner、证据、停止条件和下一步动作，让运营团队知道今天应该补什么、暂停什么、谁负责。
本课产出：美国销售税、拒付和争议风险表
把美国销售税设置、高风险订单、手动 capture、拒付原因码、证据包和月度 fraud/dispute ratio 放进一套风控节奏。
本课目标是交付一份拒付风险矩阵。这份资产必须能回答四个问题：当前风险是什么，证据在哪里，谁负责，什么时候可以继续或必须暂停。
- 第一步：列出影响上线或扩量的风险节点。
- 第二步：为每个节点绑定公开来源、内部证据和 owner。
- 第三步：把继续、小流量测试、补证据、暂停或升级写成规则。
拒付风险矩阵：evidence pack
下面这张表是本课的可交付资产。使用时不要只填状态，要写清来源、证据、owner、截止时间和 stop/go 规则。
| 风险节点 | 证据或来源 | 经营判断 |
|---|---|---|
| 销售税设置 | 注册州、tax ID、shipping tax、override | 未注册不要随意收税 |
| 订单风控 | AVS/CVV/IP、shipping mismatch、velocity | 高风险订单先验证再履约 |
| 证据包 | tracking、沟通、IP、账单、产品页、退款政策 | 证据跟原因码匹配 |
| 月度比例 | fraud + dispute / settled transactions | 超过预警线要收紧风控 |
公开来源参考：
- https://help.shopify.com/en/manual/taxes/us
- https://help.shopify.com/en/manual/taxes/us/us-tax-setup
- https://help.shopify.com/en/manual/payments/chargebacks/preventing-chargebacks
- https://help.shopify.com/en/manual/payments/chargebacks/chargeback-reasons
- https://help.shopify.com/en/manual/fulfillment/managing-orders/protecting-orders/fraud-analysis
- https://help.shopify.com/en/manual/orders/flow
- https://corporate.visa.com/content/dam/VCOM/corporate/visa-perspectives/security-and-trust/documents/visa-acquirer-monitoring-program-fact-sheet-2025.pdf
这些来源用于确认平台、监管、支付、隐私、税费或广告政策边界；非官方调研信号只转成 source-neutral 的操作判断，不在前台显名。
税务和拒付都需要前置 owner
TrekCup 进入美国不能只在 Shopify 里打开 tax collection。团队要先判断责任州、注册状态、shipping tax 和 override，再把订单风控和拒付证据放进同一套复盘。
落地时，把这个判断写进拒付风险矩阵。每个高风险动作都要能追溯到一个证据包、一个 owner 和一个明确的 stop/go 规则，而不是在上线当天靠感觉决定。
高风险订单不要自动发货
Shopify fraud analysis 的价值在于让团队在 fulfillment 前停下来。高风险订单可以验证、取消或退款；如果直接发货，后续拒付时证据和现金都会更被动。
落地时，把这个判断写进拒付风险矩阵。每个高风险动作都要能追溯到一个证据包、一个 owner 和一个明确的 stop/go 规则，而不是在上线当天靠感觉决定。
证据包按原因码准备
未收到货、欺诈、商品不符、重复扣款和退款争议需要不同证据。矩阵里不能只写上传 tracking，而要写对应原因码、证据字段、owner 和提交截止时间。
落地时，把这个判断写进拒付风险矩阵。每个高风险动作都要能追溯到一个证据包、一个 owner 和一个明确的 stop/go 规则，而不是在上线当天靠感觉决定。
TrekCup 操作演练
TrekCup 抽查最近 20 个美国订单：找出高风险标记、shipping/billing 不一致、退款、tracking 缺口、销售税状态和客服沟通。最后写出继续、hold、verify、cancel 或 refund 规则。
执行检查
- 每个风险节点都有 owner，不用模糊的团队一起看代替责任人。
- 每个公开 claim 都有官方或机构来源，不用社媒截图当正文证据。
- 每个 blocker 都有暂停范围、恢复条件和复盘时间。
- 结果要写回下一次 launch gate、利润复盘或季度治理 roadmap。
拒付风险矩阵的证据链检查
拒付风险矩阵最容易失败的地方，是只收集资料但不形成判断。更稳的做法是把证据分成四层：公开规则、内部事实、客户承诺和经营动作。公开规则回答平台或监管边界，内部事实回答店铺现在做到了什么，客户承诺回答页面和 checkout 说了什么，经营动作回答团队准备继续、暂停还是升级。
如果四层证据冲突，先暂停高风险动作。例如页面承诺免费退货，但客服 SOP 写的是买家承担退货；广告承诺快速发货，但 EU 包裹没有清楚税费责任；系统里有 cookie banner，但第三方脚本在同意前已经触发。这些冲突都要先进入evidence pack，再决定是否上线。
最小记录方式是一张 8 列表：风险节点、公开来源、内部证据、客户触点、owner、当前状态、下一步动作、恢复条件。字段少一点没关系，关键是每次上线、扩市场、换支付、加像素或改 claim 时都用同一张表。
当团队暂时拿不到完整证据时，可以标记为临时通过，但必须限制流量、限制市场或限制 SKU，并写清补证据的截止时间。合规治理的价值不在于一次性完美，而在于让每次增长动作都带着更清晰的风险边界。
拒付风险矩阵的验收标准
第一条验收标准是可复查。任何人打开拒付风险矩阵，都能看到公开来源、内部截图或系统记录、客户触点和最后决策。不要只写已确认或没问题，这种状态无法被下一位同事复查。
第二条验收标准是可执行。表里每个 blocker 都要能变成动作：补政策页、改产品页、暂停广告、hold 订单、调整 checkout 文案、补标签资料、联系支付方或安排外部确认。不能执行的判断，需要继续拆小。
第三条验收标准是可恢复。暂停不是终点，暂停后要写恢复条件。例如补齐 business info 后重新提交 GMC，补齐产品安全资料后打开 EU 市场，拒付比例回到警戒线以下后恢复自动 capture。没有恢复条件，团队会在保守和冒险之间来回摇摆。
第四条验收标准是能回写到其他系列。拒付风险矩阵的结论要能进入利润复盘、商品数据、广告结构、邮件发送、CRO 页面和客服 SOP。这样合规不是额外会议，而是每个增长动作前的一道运营控制点。
第五条验收标准是能解释给非合规同事。广告同事要知道为什么某个国家不能放量，客服同事要知道客户问到税费或退款时该怎么回答，运营同事要知道哪些订单需要 hold，创始人要知道哪些风险会影响现金和账号。
第六条验收标准是能留下版本记录。每次修改拒付风险矩阵，都要记录改动时间、改动原因、影响页面或流程、验证结果和下次复查日期。三个月后回看时，团队能知道某个 gate 为什么变严、某个市场为什么暂停、某个 claim 为什么被改写。
最后，验收时要检查这份资产是否真的改变了下一步动作。如果填完拒付风险矩阵之后，预算、页面、客服话术、商品资料、支付设置和事件记录都没有任何变化，说明它还只是文档。真正可用的风控资产，会让团队更快决定哪里可以继续，哪里必须先停。
交给产品 claims 审核前要带上的争议信号
本课承接利润复盘里的退款和拒付成本，并把风险结果交给客服、履约和支付设置。
如果你是从利润、广告、CRO、邮件、商品数据或运营系列跳到这里，记住边界：前面的系列负责创造增长动作，本系列负责判断这些动作能否安全进入市场、能否继续扩量、是否需要暂停或升级。