All packsSaaS Billing + Tax CoreSolve
stripe customer resubscribe new subscription id cache bug
A returning customer gets a new subscription id
Keying a local billing cache by Stripe subscription id breaks the moment a canceled customer resubscribes and gets a brand-new sub_ id (D2).
What goes wrong
A customer who cancels and later resubscribes gets an entirely new Stripe subscription id, not a reactivated old one. A local cache table keyed by that subscription id either collides with the old canceled row or silently forks into two rows for one account -- either way, the app's idea of "is this account paying" goes wrong for a real, common lifecycle event, not an edge case.
Why agents get it wrong
Keying the cache by the Stripe object's own id looks like the obvious, safe choice -- it's unique, it's what Stripe gives you first. The bug only appears on the second subscription for the same account, which most manual testing never exercises because it means canceling and waiting, not just checking out once.
What SaaS Billing + Tax Core pre-decides
D2 keys the Subscription cache row by accountId, not by Stripe subscription id, specifically so a churn-and-return customer updates the same row instead of orphaning it. D5's supersession rules then govern exactly when a different incoming subscription id is allowed to replace that row's contents versus being refused as a logged, operator-visible orphan.
Source: ARCHITECTURE.md D2