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.

The Payments Stack Nobody Draws

Most ISVs only understand the visible layer of payments:

• The payment form
• The gateway SDK
• The API response
• The settlement report

But underneath that exists an entire ecosystem of:

• Gateways
• Acquirers
• Sponsor banks
• BIN sponsors
• Payment facilitators
• Token providers
• Switches
• Fraud tools
• Card brand networks
• Issuer processors
• Data enrichment engines
• ISO8583 message translators

Depending on your provider, there may be six to twelve companies involved in a single authorization before the issuer ever responds.

The irony?

Most ISVs have no idea who half of them are.

ISO8583: The Language Everything Actually Speaks

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.

Data Extrapolation: The Part Nobody Talks About

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:

• Stored credential indicators
• MIT/CIT classifications
• Token cryptograms
• Device telemetry
• Authentication indicators
• Level II / Level III data
• Final authorization flags
• Recurring payment metadata
• Installment indicators

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.

Why Authorization Rates Are Often a Processor Problem

ISVs are constantly told:

• “The issuer declined it.”
• “That’s just fraud pressure.”
• “Nothing we can do.”

Meanwhile:

• MIT chains are broken
• Retry logic violates network rules
• Token lifecycle management fails
• Transactions are improperly flagged
• ISO8583 mappings are inconsistent
• Network tokenization isn’t configured correctly

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.

The Interchange Games Nobody Explains

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.

Keeping Interchange on Refunds

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.

Reversals vs Refunds

Another favorite trick: obscuring the operational difference between authorization reversals (voids) and refunds.

A true authorization reversal:

• Releases the cardholder hold quickly
• Prevents settlement movement
• Often avoids interchange entirely

A refund:

• Happens after settlement
• Creates additional processing events
• Introduces additional interchange implications

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.

The Questions Most ISVs Never Ask

Here’s the uncomfortable reality:

Most ISVs do not actually know:

• Who their acquiring bank is
• Who owns the BIN sponsorship
• Whether tokenization is portable
• Which vendors are touching transaction data
• How many hops occur before authorization
• Whether retries are network compliant
• What fields are modified downstream
• What optimization engines are running in the background
• Whether auth routing is processor-controlled
• How interchange qualification is actually being managed

And to be fair — processors often prefer it that way.

Complexity creates opacity. Opacity protects margins.

Why This Matters More Than Ever

Payments is no longer just “accepting cards.”

Modern payment performance depends on:

• Data quality
• ISO8583 translation integrity
• Token lifecycle management
• Retry compliance
• Smart authorization routing
• Interchange optimization
• Fraud signal quality
• Card network rule adherence

The difference between a mediocre platform and a highly optimized one can easily be:

• Several basis points of margin
• Meaningful authorization lift
• Better customer experience
• Reduced fraud exposure
• Lower compliance risk

But you cannot optimize what you do not understand.

The Real Questions ISVs Should Be Asking

Stop asking: “Who has the cheapest rate?”

Start asking:

• Who actually controls the transaction flow?
• What do the ISO8583 mappings look like?
• Who owns the token?
• What transaction data is being modified downstream?
• How are retries being handled?
• What interchange optimization is actually occurring?
• What refund economics exist behind the scenes?
• What does the processor keep that I never see?

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.