Reconciliation script matched stored payment methods by a hash of PAN + expiry, alongside the gateway token. Worked fine until Visa's Account Updater service kicked in on a card reissue and rewrote the last four digits and expiry on file, without touching the token.
The gateway still charged the subscription successfully using the token. Our ledger, matching on the old PAN hash, treated the renewal as a payment method it had never seen and created a duplicate customer record. Took two days of log diffing to catch it, because the actual charge succeeded every time - nothing failed, nothing alerted, the data just quietly forked.
Count from one billing cycle: 3 out of roughly 1,200 active subscriptions hit this. Small number, but each one meant a support ticket about "missing" payment history and a manual merge.
Fix was obvious in hindsight: never key anything long-lived off PAN or expiry, only off the token, and treat account updater events as a first-class webhook to log even when they change nothing you're actively checking.
Curious how other teams key their stored payment methods for reconciliation. Token only? Token plus a stable customer-side ID? Anyone still matching on card metadata for legacy reasons and dealing with this same drift?
Top comments (0)