Set up recurring billing with the stored-credential framework: first transaction tagged as customer-initiated (CIT), every renewal after that tagged merchant-initiated (MIT), with the original transaction ID from that first CIT carried forward on every renewal. Worked across test cards for three weeks straight.
Then one issuer in our mix started declining renewals with code 05 (do not honor) on roughly 4% of subscriptions, all routed through the same BIN range. Turned out we were resetting the stored original transaction ID whenever a customer updated their card, since the update flow treated it as a new CIT event and generated a fresh ID. Most issuers didn't care and kept approving off the card credentials alone. One issuer actually validated that the MIT chain traced back to a real prior auth, and broke the moment the chain reset.
The spec treats this as one indicator. In practice it's enforced on a sliding scale from 'ignored entirely' to 'hard requirement,' and you only find out which issuers sit where by watching decline codes cluster on BIN ranges over a few weeks.
Anyone else tracking stored-credential chains across card updates? Curious how others handle the reset-on-update case without breaking the MIT history.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.