DoorDash 事故调查：商家错价导致骑手卡额度不足

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 题目未明确卡额度配置、商家价格来源与支付 provider。以下按订单预估总价决定预授权/卡上限，现场实际金额更高而被拒付的可能链路推演；这只是调查假设，需用日志证伪。
• 目标优先级为骑手/顾客即时影响、资金与风控边界、客服负载，再到根因修复；不因赶进度直接全局提高卡额度。
• 事故响应需要产品、支付、商家运营、客服和风控的共同决策，变更通过已有安全开关与审计流程。

解题路线

1. 先确认范围：按 merchant、地区、支付通道、订单创建时间和应用版本分组看卡拒付率、金额差分布、积压订单数、客服队列与受影响骑手。建立单一 incident timeline，并指定指挥/技术/沟通负责人。
2. 用订单 ID 串起菜单标价、结账预计金额、卡授权上限、商家实际小票、provider decline code 与客服工单。比较事故前后变更：价格同步、税费/小费、促销、卡额度计算和 POS 接口。
3. 短期缓解可按受影响商家暂停新接单或关闭错误商品；对已到店订单提供人工核价与有上限的单笔额度调整/替代付款流程，记录审批与证据。给骑手/顾客及时状态与取消/补偿选项，客服使用统一脚本和批量识别标签。
4. 修复后先小流量恢复，检查拒付率和实际/预估金额差是否回基线，逐步重开；回放积压订单、核对误扣/重复付款、对骑手/商家/顾客结算与补偿。事后加入价格新鲜度、授权余量、拒付告警与演练。

手动走一遍

某商家 12:00 起商品从 20 美元误标为 10 美元，100 个骑手到店时公司卡额度只按 10 美元订单配置而被拒付。值班先用 merchant_id 限定范围、暂停该商家的新订单，并给已有订单进入人工核价队列；核对 provider decline code 后才决定单笔调整。恢复价格后，抽样支付成功、客服排队和账务差异，再分批重开。金额与数量仅用于训练示例，非题目披露。

规模与取舍

设每分钟新订单 R、事故持续 T 分钟，理论受影响上界约 R×T；排查优先用高基数 order_id 追踪与 merchant 维度聚合，避免全量扫所有日志。缓解能力应按积压数、人工核价每小时处理量和客服到达率估算，超过能力时暂停入口更有效。

易错点与追问

容易失分的边界

• 把卡拒付都归因于商家错价会漏掉通道故障、风控封卡、卡过期或额度计算 bug；需查 decline code 与金额差证据。
• 全局放大卡额度会扩大盗刷/误收费损失；只能在可审计范围内对已核实订单做限额处理。
• 仅恢复新单而忽略在途/失败订单，会留下骑手滞留、重复支付、客服积压和账务差异。
• Incident 轮的重点常是跨团队操作与恢复决策，不是只画出支付微服务图； 也强调这一点。

继续深挖

• 若价格变化高频且商家 POS 是权威源，给菜单快照版本与 last_verified_at；下单前/到店前重新校验，超过差额阈值触发确认。
• 若 provider 异步返回 UNKNOWN，先查询原授权状态并保持单一 payment attempt 幂等键，避免为了救单造成重复扣款。
• 事后评估平均发现时间、缓解时间、被困骑手分钟数、客服排队与财务差异结清时间，而不只看服务恢复时间。