Most ISVs can explain their technology stack in painful detail.
They can whiteboard Kubernetes clusters, event-driven architectures, OAuth flows, CDN strategies, and microservice communication patterns without breaking a sweat.
Then you ask:
“What actually happens after someone clicks Submit Payment?”
And suddenly things get vague.
“Well... it goes to the processor.”
Ah yes. “The processor.” The magical black box where card transactions disappear into the cloud and money comes out later.
Except that’s not how any of this actually works.
Most ISVs only understand the visible layer of payments.
The payment form: This is the part your customer sees — the hosted field, embedded checkout, payment modal, or custom UI. It feels like “the payment experience,” but it’s really just the front door to a much larger ecosystem.
The gateway SDK: This is the developer-friendly wrapper that makes payments feel clean and modern. But behind that SDK, your transaction data may be transformed, enriched, stripped, rerouted, or translated before it ever reaches the card networks.
The API response: Approved. Declined. Error. Timeout. That little response object tells you what happened, but rarely why it happened. For an ISV, that distinction matters because “issuer declined” may actually be the result of poor data formatting, broken token logic, or weak transaction indicators upstream.
The settlement report: This is where many ISVs think the story ends. Money moved, fees were charged, everyone goes home. But settlement reports often hide more than they reveal — especially around interchange qualification, refund economics, and processor-retained margin.
Underneath that visible layer sits the machinery that actually makes the transaction work.
Gateways: The gateway is often the first stop after your platform. It receives the transaction request, validates basic formatting, and routes it downstream. Some gateways are simple pass-through pipes; others make decisions that affect tokenization, fraud tools, retries, and data quality.
Acquirers: The acquirer is the financial institution responsible for acquiring the transaction into the card network ecosystem. For ISVs, this matters because the acquirer relationship influences pricing, compliance obligations, risk appetite, and how much flexibility you actually have.
Sponsor banks: Sponsor banks sit behind many processors, PayFacs, and ISOs. They provide the regulated banking relationship required to access card networks. If you don’t know who the sponsor bank is, you may not fully understand who ultimately controls risk decisions in your payments stack.
BIN sponsors: BIN sponsors provide the Bank Identification Number infrastructure used for acquiring or issuing activity. In some payment models, the BIN sponsor has a major role in transaction routing, network access, and compliance oversight.
Payment facilitators: PayFacs aggregate merchants under a master merchant relationship. For ISVs, PayFac models can simplify onboarding and monetization, but they also introduce shared risk, underwriting obligations, and dependency on the PayFac’s controls and economics.
Token providers: Token providers determine how card credentials are stored, replaced, updated, and reused. This matters because token ownership impacts portability, authorization performance, PCI scope, and your ability to migrate providers later without blowing up your stored credential base.
Switches: Switches route transaction messages between processors, networks, and other endpoints. They are the traffic controllers of the payments world. A switch can impact routing speed, reliability, message formatting, and ultimately whether the transaction gets where it needs to go cleanly.
Fraud tools: Fraud platforms score transactions before or during authorization. Poorly tuned fraud tools can kill good transactions, while weak controls can let bad ones through. ISVs need to understand whether fraud decisions are happening inside their platform, at the gateway, at the processor, or somewhere else entirely.
Card brand networks: Visa, Mastercard, Discover, and Amex are not just logos on cards. They define the rules, message standards, fees, dispute processes, token frameworks, and data requirements that shape transaction outcomes.
Issuer processors: Issuer processors support the banks that issued the card. They help evaluate transaction requests and return approvals or declines. The better the data they receive, the better chance they have of making the right decision.
Data enrichment engines: These tools add or modify transaction data to improve authorization performance, qualify for interchange, or satisfy network requirements. Done well, enrichment helps. Done poorly, it can create mismatches, downgrades, and unexplained declines.
ISO8583 message translators: These translate your modern API request into the card network language. This is where small data issues can become expensive problems. A missing field, incorrect indicator, or bad mapping can affect authorization rates, interchange qualification, and compliance.
At the center of the card ecosystem sits ISO8583 — the messaging standard used by Visa, Mastercard, Discover, and Amex to communicate transaction data.
Think of it as the native language of the card brands.
Your clean REST API payload? Your beautiful JSON request? Your elegant GraphQL abstraction?
Eventually all of that gets translated into an ugly little ISO8583 message packed with numeric data elements and positional fields that look like they were designed during the Cold War.
And that translation layer matters far more than most ISVs realize.
Because authorization rates, fraud scoring, issuer decisioning, token handling, and interchange qualification all depend heavily on the quality and completeness of the data being passed through those messages.
Which means one very important thing:
The platform translating your transaction data has enormous influence over your payment performance.
Most ISVs assume processors simply pass along the data they provide.
Not exactly.
Many processors, gateways, and middleware providers perform what is effectively data extrapolation — attempting to infer, supplement, or manufacture missing transaction attributes behind the scenes.
Why?
Because modern payment networks increasingly expect rich transaction metadata. In plain English, that means the transaction has to tell a complete story: who initiated it, why it is happening, whether the card was stored, whether a token was used, whether authentication occurred, and what type of transaction it really is.
That data directly impacts issuer trust, authorization rates, interchange qualification, compliance exposure, and card brand fees. Missing or incorrect metadata can make a perfectly legitimate transaction look riskier, more expensive, or non-compliant.
Stored credential indicators: These tell the networks and issuers that the card was previously saved and is now being used again. If this is missing or incorrect, stored-card transactions can look suspicious, hurt approval rates, or create compliance issues under card brand stored credential rules.
MIT/CIT classifications: These identify whether the cardholder initiated the transaction or the merchant did. This matters heavily for subscriptions, recurring billing, and installment payments because a 2:00am renewal should look like a valid merchant-initiated transaction — not a suspicious cardholder purchase.
Token cryptograms: These are dynamic security values tied to network tokenized transactions. If they are missing, stale, or malformed, issuers may treat the transaction as less trustworthy, which can reduce approvals and eliminate tokenization benefits.
Device telemetry: This includes signals about the device, browser, session, or environment behind the transaction. Strong telemetry helps fraud models separate legitimate customers from suspicious activity; weak telemetry creates false declines.
Authentication indicators: These show whether authentication occurred, such as 3DS or other verification methods. Proper indicators can shift issuer confidence, affect liability outcomes, and improve approval performance.
Level II / Level III data: This is enhanced transaction detail often used in B2B, commercial card, and purchasing card environments. Missing or poor-quality Level II/III data can cause interchange downgrades and leave savings on the table.
Final authorization flags: These tell the network whether an authorization is final or preliminary. Incorrect flags can create compliance issues, cardholder hold problems, and avoidable data integrity fees.
Recurring payment metadata: This identifies transactions tied to an ongoing billing agreement. Without it, legitimate subscription charges may look like random card-not-present transactions, increasing decline risk.
Installment indicators: These signal that the transaction is part of a structured installment plan. If the data is wrong or absent, issuers may misclassify the transaction, which can impact approvals, compliance, and customer experience.
If your platform doesn’t send this information correctly, someone downstream may try to “help.”
Sometimes they help successfully. Sometimes they guess wrong. Sometimes they strip fields entirely. Sometimes they downgrade your interchange qualification. Sometimes they quietly hurt your authorization rates while blaming issuer behavior.
And because most ISVs never see the actual ISO8583 payloads, they have no idea what’s truly being transmitted on their behalf.
ISVs are constantly told:
Meanwhile:
Issuers make authorization decisions based on the data they receive.
Bad data in = worse approvals out.
The processor sitting in the middle of the stack often has far more influence over authorization performance than merchants or ISVs realize.
Here’s where things start getting really interesting.
Most ISVs think processors make money on basis points and markup.
Sure.
But there are entire categories of hidden optimization strategies happening underneath the hood.
Here’s one that surprises almost everyone: when a refund occurs, processors often receive interchange reimbursement back from the card brands.
Do merchants or ISVs typically see that money returned?
Rarely.
Most processors simply keep it.
The merchant assumes interchange was lost forever. The processor quietly improves margin.
Nobody asks questions because almost nobody understands the settlement mechanics deeply enough to realize the reimbursement existed.
Another favorite trick: obscuring the operational difference between authorization reversals (voids) and refunds.
A true authorization reversal:
A refund:
Some providers intentionally blur these concepts because refunds can be operationally and financially more profitable than reversals.
To the merchant: “The customer got their money back.”
To the processor: one workflow is materially better for margin.
Guess which workflow quietly becomes the default.
Modern payment performance depends on far more than simply sending a transaction to a processor.
Data quality determines whether issuers receive enough context to approve the transaction confidently. Bad data makes good customers look risky.
ISO8583 translation integrity determines whether the information your platform sends actually survives the journey into the network message. If the translation is wrong, your clean API request doesn’t matter.
Token lifecycle management determines whether stored credentials continue working when cards expire, are reissued, or are replaced. This is especially critical for subscriptions, recurring billing, and marketplaces.
Retry compliance determines whether failed payments are retried intelligently or in ways that trigger card brand penalties. Bad retry logic can turn revenue recovery into compliance leakage.
Smart authorization routing determines whether transactions are routed through the best available path. In some setups, routing is optimized. In others, it’s just whatever path benefits the processor most.
Interchange optimization determines whether transactions qualify for the best available interchange category. Missing or incorrect data can quietly push transactions into more expensive buckets.
Fraud signal quality determines whether fraud tools and issuers can separate legitimate customers from suspicious behavior. Weak signals create false declines and lost revenue.
Card network rule adherence determines whether you avoid unnecessary fees, penalties, and operational surprises. The rules change constantly, and “we didn’t know” is not a great defense.
Stop asking: “Who has the cheapest rate?”
Start asking:
Because the tricks are endless.
And unless you understand how the puzzle pieces fit together — and know the right questions to ask — good luck figuring out where your money is actually going.
The payments rabbit hole is much deeper than most ISVs realize.
And under the hood?
It gets weird fast.