一张卡绑定多个订阅：商户映射、替换成本与余额碎片怎么建模

用户补发了一张 MPChat 卡。卡号没变，有效期和 CVV 更新了。后台仍按卡号末四位把八项订阅标为“绑定有效”。几天后，一项官网续费失败。客服只知道它关联这张卡，找不到用户该去哪个账号检查付款资料。

系统缺的是付款路径，而不只是一个卡片状态。下面的对象和代码仅作架构示例，不代表 MPChat、Apple 或商户的现网接口。

Subscription {
subscription_ref, service_ref, purchase_account_ref,
billing_route_ref, next_bill_at, expected_amount, currency
}

BillingRoute {
route_ref, channel: DIRECT | APP_STORE | GOOGLE_PLAY | OTHER,
payer_account_ref, merchant_ref
}

CardBinding {
route_ref, card_ref, credential_epoch,
review_state: CONFIRMED | REVIEW_REQUIRED | UNKNOWN
}

CardObservation {
event_ref, card_ref, descriptor, amount, currency,
card_state, observed_at
}

RouteMatch {
event_ref, route_ref, match_state: CANDIDATE | CONFIRMED | UNMATCHED,
source_order_ref
}

CardBalanceSnapshot {
card_ref, available_amount, currency, observed_at
}

Subscription 保存每项软件的续费关系；BillingRoute 指向管理订单和付款方式的账号。三个 App Store 订阅可以共用一个 Apple 计费入口，但仍有三项需要核对的购买记录。五个官网账号则可能对应五个入口。

CardObservation 记录卡侧看到的交易。商户描述、金额和时间可以帮助提出匹配候选，不能直接证明它属于哪项订阅。尤其是应用商店可能合并购买，RouteMatch 应等原渠道订单提供证据后再转为 CONFIRMED。日志里不要保存完整卡号、CVV、验证码或完整邮箱。

补卡后的检查量按已知付款入口计算：

review_count =
count(distinct route_ref
where CardBinding.card_ref == affected_card)

这算的是待核对入口，不是必然要重新绑卡的次数。卡号末四位相同也不足以维持 CONFIRMED。已知使用受影响卡片的绑定可进入 REVIEW_REQUIRED；用户到原计费渠道确认后，才更新状态。credential_epoch 只是内部版本标记，不存放安全码。

资金准备也只能按目标卡算。A 卡可用 18 美元，B 卡可用 26 美元，明天从 A 卡发起的订单预计需要 20 美元。两卡合计 44 美元，对这次续费没有直接帮助。先把预计账单、已知税费和费用换算到同一币种，再结合有效报价与 A 卡的最新余额判断：

if binding.review_state != CONFIRMED:
return CHECK_PAYMENT_METHOD

if balance_snapshot.is_stale or estimate.fx_quote_is_stale:
return REFRESH_INPUTS

if balance_snapshot.available_amount < estimate.total_with_buffer:
return FUND_TARGET_CARD

return FUNDS_PREPARED

FUNDS_PREPARED 仅表示当前估算下目标卡资金已准备好。商户是否接受卡片、是否生成订单、会员是否生效，还要分别核对。

回归测试至少覆盖四种情况：八项订阅只对应六个付款入口；补卡后末四位不变但绑定仍待核对；B 卡余额充足而目标 A 卡不足；卡侧已清算但商户订单未确认。把这些状态分开，用户才能看到准确的下一步。