Added card-surcharging logic for a US merchant: debit cards skip the 3% fee, credit cards get it, per the usual state rules. Classification ran off a static BIN range table refreshed quarterly from our processor.
Surcharge complaints started trickling in — cardholders insisting their debit card got charged a credit surcharge. Pulled the flagged transactions: roughly 1 in 180 had a BIN that our table listed as credit, but the issuer's own authorization response carried a debit indicator in the response fields.
Turns out prepaid and co-branded cards get reissued under ranges that shift between debit and credit designation as issuers rebalance portfolios, and BIN tables lag actual issuer records by weeks to months. The authorization response usually carries the real account type in the response (card type indicator, or equivalent field depending on network) — more current than any static table, because it comes straight from the issuer at auth time.
Switched the surcharge decision to read off the authorization response instead of the pre-auth BIN lookup. Still keep the BIN table for pre-auth estimates shown at checkout, but settle the actual charge based on what the issuer says in the response.
Anyone else running surcharge or interchange logic purely off BIN lookups? Curious how often that assumption breaks for you in practice.
Top comments (0)