---
title: "Processor"
url: "https://mahouse.world/glossary/processor"
type: "glossary term"
topic: "Payments infrastructure"
author: "Ihor Vlasov"
reviewed: "2026-09-20"
published: "2026-08-10"
---

# Processor

A processor is the company whose systems run the transaction machinery for an acquirer or an issuer — receiving authorisations, applying rules, routing to the networks, clearing, computing fees and settlement — as a service bought rather than built. Acquirer processors serve the merchant side; issuer processors serve the card-issuing side, including the modern platforms fintechs issue on. The word is also used loosely for any PSP, so contracts define it.

**Also known as:** Payment processor, Card processor, Issuer processor, Acquirer processor

## Key facts

- **Used at:** every card transaction — the acquirer's processor handles the merchant's message, the issuer's processor handles the cardholder's; banks and fintechs outsource most of it
- **Binding:** a processing agreement with volume pricing, service levels, exclusivity terms and change-of-control clauses; the processor is a PCI service provider and often a scheme-registered third-party agent
- **Typical pricing:** fractions of a cent to a few cents per transaction at scale, plus monthly platform fees and charges for cards on file, disputes, reports; issuer-processing for fintech programmes at $0.10–0.50 per active card per month plus per-transaction fees
- **Typical consolidation:** the 2019 mergers — Fiserv–First Data, FIS–Worldpay, Global Payments–TSYS — combined the largest acquirer and issuer processors; the modern issuer processors grew on fintech programmes and are themselves acquisition targets
- **Parties:** the processor, its acquirer or issuer clients, the schemes (whose messaging standards it implements), and the merchants and cardholders who never see it

## How a processor works in practice

On the acquiring side: a merchant's gateway sends an authorisation; the acquirer's processor receives it, validates it, applies the acquirer's rules, formats it for the network and sends it; the response returns the same way. At day's end the processor clears the approved transactions to the networks, receives the settlement files, computes each merchant's fees and net position, and produces the settlement instructions and the reports. On the issuing side: the network delivers an authorisation request for one of the issuer's cards; the issuer's processor checks the account, the limits and the fraud rules — or the issuer's own systems do, through the processor's API — and answers; it then posts the transaction, produces statements, handles disputes and manages the card lifecycle.

Fintechs made the issuer side interesting. A neobank issuing cards needs a processor that can answer authorisations in real time from the neobank's own logic — the "just-in-time funding" model, where the processor asks the fintech whether to approve — and the modern issuer processors were built for that, with APIs instead of files. They charge per card and per transaction, and a neobank's processor bill is one of its largest costs and dependencies.

For an acquirer of a payments business the processor contract is diligence: term, exclusivity, pricing tiers, service levels, and what a migration would cost — because the processor is where the platform actually is.

## Example

A neobank with 800,000 active cards pays its issuer processor $0.30 per active card per month plus $0.02 per transaction: about $4.3m a year on 60 million transactions. The contract runs five years with a change-of-control consent clause. A buyer of the neobank, itself a bank with a legacy processor, models three options: stay on the fintech's processor ($4.3m a year, rising with volume); migrate to its own platform (a $6m project, eighteen months, and a real-time authorisation capability its platform lacks); or renegotiate at the combined volume ($3.1m). It chooses the third, obtains the consent, and keeps the neobank's stack — the acquisition was partly for it.

## Common mistakes

- Building a fintech's product on a processor without reading the exclusivity and change-of-control terms.
- Assuming "processor" in a contract means the same thing to both parties.
- Migrating processors on a schedule that ignores card reissuance and stored credentials.
- Buying a payments company for its "platform" when the platform is a processor's, under contract.
- Ignoring the processor's own dependency on the schemes' certification cycle, which sets the pace of every product change.

## Related terms

- [Acquirer](https://mahouse.world/glossary/acquirer.md)
- [Issuer](https://mahouse.world/glossary/issuer.md)
- [Payment Gateway](https://mahouse.world/glossary/payment-gateway.md)
- [Payment Service Provider](https://mahouse.world/glossary/payment-service-provider.md)
- [Stand-In Processing](https://mahouse.world/glossary/stand-in-processing.md)
- [Card Network](https://mahouse.world/glossary/card-network.md)

— Ihor Vlasov, M&A FinTech Expert. Last reviewed 2026-09-20. https://mahouse.world/authors/ihor-vlasov