The surface problem: a wrong fee
The symptom was clear. Patients were seeing a 3 percent surcharge on debit card payments. The surcharge was inconsistent. Some debit cards were charged correctly. Others were not. The pattern was not immediately obvious.
The payment portal used a third-party payment gateway. The gateway connected to a processor. The processor referenced a BIN database to determine whether a card was debit or credit. The BIN database was maintained by the payment processor and updated periodically.
The logical assumption was that the BIN database was outdated. Newer debit cards sometimes use BIN ranges that were historically assigned to credit products. If the database had not been updated recently, it might classify a modern debit card as credit.
But that assumption turned out to be wrong. The BIN database was updated. The processor was classifying the card correctly. Somewhere else in the chain, the correct classification was being overridden.
Tracing the payment: four systems deep
The payment flow went like this: patient enters card details on the portal, portal sends the transaction to the gateway, gateway sends it to the processor, processor classifies the card and returns the result, gateway applies surcharge rules based on classification, portal displays the total to the patient.
That is four systems. Each one has its own logic, its own data model, and its own assumptions about how cards are classified.
The investigation went layer by layer.
First, the processor logs were checked. The processor was correctly identifying the card as debit. Good. The BIN database was not the problem.
Second, the gateway logs were checked. The gateway was receiving the correct classification from the processor but then applying a surcharge anyway. Something between the processor response and the surcharge calculation was wrong.
Third, the surcharge rules were examined. The gateway had a list of card types that should trigger the surcharge. The rule was simple: if card type is credit, apply 3 percent. But the rule was checking the raw BIN range against a hardcoded list of credit BINs instead of using the processor's classification.
Fourth, the hardcoded list was found. It was a static array of BIN prefixes, embedded in the gateway configuration, written years ago and never updated. The list classified a range of modern debit BINs as credit. When a patient used a card in that range, the processor correctly said "debit," but the gateway's hardcoded list overrode the processor and said "credit."
The fix: three lines of code
The fix was to remove the hardcoded BIN list and use the processor's classification directly. Instead of checking the card's BIN prefix against a static list, the gateway now checks the processor's response.
Three lines of code. A conditional that read the processor response instead of the hardcoded array. A fallback for cases where the processor was unavailable. A log statement for debugging future issues.
Three lines of code, deployed to production. The surcharge stopped appearing on debit transactions immediately.
Why this took a week
Three lines of code do not take a week to write. They take a week to find.
The investigation required understanding the payment processing chain end to end. The portal code. The gateway configuration. The processor API. The BIN database structure. The surcharge rules. Each layer had to be traced, logged, and verified before moving to the next.
It also required understanding the business context. Why was the surcharge there in the first place? Which card types should it apply to? What were the compliance implications if the wrong fee was being charged? A developer who only understood the code would have fixed the hardcoded list without asking whether the hardcoded list should exist at all.
This is the kind of bug that offshore development teams miss routinely. Not because they are bad developers. Because the bug was not in any one system. It was in the interaction between systems, layered on top of a business rule that predated the current implementation. You cannot diagnose that from a ticket. You have to trace the entire chain.
The operational support model
Most software companies sell development. They build new features. They launch new products. They deliver projects.
Operational support is different. Operational support is about keeping business-critical software running correctly after it is built. It is the bugs that only appear after months in production. The edge cases that surface when a real patient uses a real card. The problems that exist at the intersection of systems that were never designed to work together.
These problems are expensive because they are hard to diagnose and easy to dismiss. The vendor said the card was credit. The client was frustrated. Without someone who could trace the payment through all four systems and prove the vendor wrong, the client would have either accepted the wrong answer or spent months fighting with the vendor's support team.
The business impact of those three lines of code was not technical. It was financial. Every debit transaction that was incorrectly surcharged was money the patient should not have paid. Over time, that is a compliance liability, a reputation problem, and a source of patient complaints that nobody could explain.
The bottom line
The hardest bugs are not the ones with stack traces. They are the ones where every system says it is working correctly, and the problem only exists in the space between them.
Fixing those bugs requires developers who think in systems, not tickets. Developers who trace the data through every layer instead of stopping at the first plausible explanation. Developers who understand the business well enough to know which three lines of code actually solve the problem, and which three lines just move the problem to a different system.
That is what real operational software support looks like. And it is why businesses that depend on their software need more than a development team. They need a partner who treats their software like it matters.
Book a discovery session to talk about ongoing operational support for your business-critical software.