Every card payment processing triggers a chain of events - money moves between banks, transaction records are created, and what customers see in their banking app is shaped by decisions made long before they tapped their card.
This article breaks down the mechanics of card payments, explains how acquiring fits in, and shows why the transaction data that comes out of this process is so often inconsistent - and what you can do about it.
What is payment processing
Payment processing is the end-to-end sequence that moves a card transaction from the moment a customer pays to the moment the merchant receives funds. It involves multiple parties and happens in three phases: authorisation, clearing, and settlement.
The customer initiates the payment by tapping a card at a POS terminal, inserting a chip, or entering card details online covering both card-present and card-not-present transactions. The merchant's payment system captures the transaction details and forwards them to the acquiring bank (also called the acquirer) - the financial institution that processes payments on behalf of the merchant.
In some cases, the merchant operates under a Payment Facilitator (PayFac) instead - a model where a single entity like Stripe, Square, or Adyen aggregates many sub-merchants under one master account, handling onboarding, compliance, and settlement on their behalf. For the issuing bank, this means the PayFac name often appears in the descriptor alongside or instead of the actual merchant, adding another layer of identification complexity.
The acquirer routes the authorisation request through the relevant card network - Visa, Mastercard, or another scheme. The network identifies which issuing bank provided the card and passes the request along.
The issuing bank then runs its checks. It confirms the card is valid, verifies that sufficient funds or credit are available, and evaluates the transaction for fraud signals. It returns an approval or decline back through the same chain: card network to acquirer to merchant.
This entire authorisation process takes only a few hundred milliseconds. But it is just the first phase.
Once the transaction is authorised, clearing begins. At the end of the business day, the merchant sends all authorised transactions in a batch to the payment processor, which forwards them to the card networks. During clearing, exact amounts are confirmed and interchange fees are calculated.
Settlement is the final step. The issuing bank transfers the funds (minus interchange fees) to the acquiring bank, which deposits the money into the merchant's account. In Europe, settlement typically follows SEPA credit transfer cycles and TARGET2 processing windows. A domestic SEPA transfer may settle within one business day, while cross-border or non-priority transactions can take longer. The common claim of "one to three business days" is a reasonable average, but not a universal rule.
Card processing is also not the only rail in play. SEPA direct debits, instant credit transfers, and Wero (the pan-European scheme backed by the European Payments Initiative) are expanding beyond traditional card networks. Account-to-account payments using IBANs bypass card rails entirely, and domestic schemes like Germany's Girocard coexist alongside international networks. This article focuses on card processing, but the coexistence of these rails matters for anyone building payment products in Europe.
The key takeaway: every step in the card processing chain generates data. And data quality depends on how the merchant was set up in the first place.
What is acquiring
Acquiring is the merchant-facing side of the payment equation. An acquiring bank enables a business to accept card payments - providing the merchant account, the connection to card networks, and the infrastructure for processing and settlement.
Before a merchant can accept cards, the acquiring bank must onboard it: verifying legitimacy, assessing risk, and assigning identifiers - a merchant ID, MCC, descriptor, and terminal/POS IDs. These identifiers travel with every transaction.
The acquiring bank also bears financial responsibility. If a chargeback occurs, the acquirer is liable for returning funds to the issuer. Acquirers must also ensure PCI DSS compliance across their merchant base.
For banks and fintechs on the issuing side, the acquiring bank is a crucial but invisible counterpart. You never interact with it directly, yet the data it creates at onboarding determines what your transaction records look like all of it originates on the acquiring side.
How this creates transaction data
Every card transaction that reaches an issuing bank carries a set of data fields that were created during the acquiring and processing chain. These fields form the raw material that banks use for transaction categorisation, analytics, personalisation, and fraud prevention. Â
The most important ones include:
Merchant ID (MID) - a unique identifier assigned by the acquirer to each merchant account. A single retail chain might have dozens of MIDs across different locations and acquirers.
POS ID / Terminal ID - identifies the specific point-of-sale device or terminal where the transaction took place. A merchant with multiple registers or online channels will have multiple POS IDs.
Merchant Category Code (MCC) - a four-digit code that classifies the merchant's primary business activity. Visa, Mastercard, and other networks each maintain their own MCC lists, which broadly overlap but differ in how they handle niche industries and regional merchants.
Merchant descriptor - the text string that appears on the cardholder's statement. It typically includes some version of the merchant's name and location, but the format and content vary widely depending on how the acquirer configured the merchant account.
For a deeper look at why MCCs alone are not enough for reliable categorisation, read our other article. Â
This is the data that arrives at the issuing bank with each transaction. And this is the data that product teams, analytics functions, and PFM (personal financial management) features must work with.
Why transaction data quality breaks
In theory, these fields should identify the merchant, its category, and the transaction location. In practice, the data is often inconsistent, incomplete, or misleading.
Merchant setups vary across acquirers. There is no universal merchant database. Each acquirer onboards independently, assigns its own MIDs, and formats descriptors by its own conventions. The same chain might appear as "STARBUCKS STORE 4421" through one acquirer and "SBUX 4421 LONDON" through another.
MCCs are frequently inaccurate. Codes are assigned at onboarding and rarely updated. A bookshop that pivoted to electronics might still carry its original MCC. Branches of the same chain often receive different MCCs across countries - or even within the same country.
Descriptors are inconsistent. A free-text field with limited character space. Acquirers format it differently, abbreviate unpredictably, and sometimes include irrelevant internal codes. Cardholders often cannot recognise the merchant from the descriptor alone.
Multiple POS systems and acquirers per merchant. Each combination can produce a different MID, descriptor, and MCC. A supermarket chain across several European markets might generate dozens of distinct transaction "identities" - none obviously the same merchant.
The downstream impact: broken categorisation, degraded banking app UX, unreliable spending analytics, and noisier fraud detection.
If you are evaluating how to fix this at the API level, our guide on best practices and pitfalls covers the most frequent mistakes banks make.
How Tapix helps
Tapix solves the merchant identity problem by enriching raw transaction data with clean, structured, and verified merchant information.
Rather than relying on MCC codes or raw descriptors, Tapix resolves merchant identity across acquirers, geographies, and POS systems. It matches transactions to real-world merchants and returns a consistent set of enriched data points. The practical benefits for banks and fintechs include: Â
Clean merchant name - a standardised, human-readable merchant name replaces cryptic descriptors. Customers actually recognise the businesses they paid. Support tickets about unrecognised transactions drop. Dispute rates decrease.
Merchant logo - a verified logo for each merchant, ready for use in banking apps and transaction feeds. This turns a raw text list into a visual, trustworthy payment history that drives daily app engagement.
Accurate categorisation - a multi-layered tagging system that goes far beyond MCC limitations. Where a single MCC tells you "5411 - Grocery Stores and Supermarkets," Tapix distinguishes between an organic food shop, a convenience store, and a hypermarket - all under the same code. This powers more granular PFM features, better credit scoring inputs, and smarter product recommendations.
GPS location - exact geographic coordinates of the merchant outlet where the transaction occurred. This enables location-based features, analytics, and more accurate fraud detection by comparing transaction location with the cardholder's known patterns.
Additional data points - including the merchant's website URL, Google Places ID, phone number, and payment gateway identification. Together, these give banks a comprehensive merchant profile per transaction - a foundation for hyper-personalised communication, card-linked offers, and compliance with Visa and Mastercard enhanced merchant data mandates.
The result is a transformation of raw processing data into usable, product-ready data. Instead of working around inconsistencies baked into the acquiring chain, banks and fintechs can build reliable categorisation, meaningful spending insights, and a polished customer experience on top of clean, enriched transaction data.
