Card Acquiring

The invisible business behind every card payment

A customer walks into a neighbourhood pharmacy, taps a card, hears a beep, takes the medicine, and leaves. The entire visible experience lasts perhaps two seconds. The pharmacy sees an approved payment. The customer sees a notification. Neither of them sees the merchant contract, terminal configuration, risk checks, network routing, issuer decision, clearing file, settlement calculation, fee deductions, reconciliation, or the bank account credit that must all work correctly before the pharmacy can truly say it has been paid.

That hidden machinery is card acquiring.

Card acquiring is the business and technology discipline that enables a merchant to accept card payments and receive the resulting funds. The acquirer sits on the merchant side of the card ecosystem. It connects merchants to card networks, carries their transactions into the wider payment system, manages merchant risk, calculates charges, funds merchants, handles disputes, and remains accountable to the card schemes for the merchants it sponsors.

This chapter follows the complete acquiring journey from the first merchant application to the final settlement and reconciliation. It explains the commercial model, the technology stack, the operational controls, the data, the risks, and the practical decisions that banks, processors, payment service providers, payment facilitators, merchants, architects, analysts, developers, testers, and operations teams must understand.

The purpose is not to turn acquiring into a list of definitions. It is to show how the whole business works as one connected story.

Learning objectives

By the end of this chapter, you will be able to:

• Explain what card acquiring is and how it differs from card issuing, payment processing, payment gateways, and card networks.
• Identify the parties in an acquiring arrangement and understand where legal, financial, operational, and technical accountability sits.
• Describe merchant onboarding, KYB, underwriting, merchant classification, pricing, contracting, and activation.
• Trace a card payment from a physical or digital checkout through authorisation, capture, clearing, settlement, and merchant funding.
• Explain why an approved authorisation is not the same as final payment.
• Understand merchant identifiers, terminal identifiers, merchant category codes, descriptors, network references, and reconciliation keys.
• Compare direct acquiring, processor led acquiring, PSP models, payment facilitator models, marketplace models, and acquiring as a service.
• Explain merchant discount pricing, interchange, scheme fees, processor charges, gateway charges, reserves, and other economic components.
• Describe acquiring risk, transaction fraud, merchant fraud, transaction laundering, chargeback exposure, refund abuse, and operational loss.
• Explain the acquiring side of EMV, contactless, tokenisation, PCI DSS, point to point encryption, and EMV 3-D Secure.
• Describe disputes and chargebacks from the merchant and acquirer perspective.
• Design reconciliation, settlement, ledger, reporting, and operational monitoring for an acquiring platform.
• Identify key system components, data flows, non functional requirements, test scenarios, and implementation mistakes.
• Apply the concepts to real merchant situations rather than treating acquiring as a theoretical card topic.

What card acquiring really means

An acquirer is a financial institution or authorised payment provider that signs merchants, enables their card acceptance, submits their transactions into a card network, receives the financial results, and settles the merchant according to an agreed contract.

The simplest way to remember the difference between issuing and acquiring is this:

• The issuer serves the cardholder.
• The acquirer serves the merchant.
• The card network connects the issuer and acquirer.
• The merchant provides the goods or services.
• The cardholder initiates the purchase.

That sentence is useful, but real acquiring is more complicated because several companies may perform pieces of the acquirer role. A merchant may sign a contract with a payment service provider, integrate through a gateway, use a processor for transaction switching, rent terminals from another company, and receive settlement from a sponsor bank. The merchant may call all of them “the payment provider,” even though their responsibilities are different.

A strong acquiring design therefore starts by separating four kinds of responsibility:

One company may hold all four responsibilities. In a modern platform, they may be distributed across several partners. The distribution must be written clearly into contracts, system design, operational procedures, and incident management. Confusion at this level later appears as missing settlements, unowned fraud alerts, duplicated disputes, and unresolved merchant complaints.

What acquiring is not

Card acquiring is closely connected to several other activities, but it is not identical to them.

A gateway can be technically excellent but cannot, by itself, replace the legal and financial role of an acquirer. A processor can route millions of transactions but may not hold the merchant contract. A bank may credit the merchant’s settlement account without being the merchant’s card acquirer. These distinctions matter whenever an incident, dispute, audit, or contractual question arises.

The acquiring ecosystem

The acquiring ecosystem has grown from a relatively simple bank and merchant relationship into a layered service chain.

Merchant

The merchant sells the goods or services and accepts the card. It may be a small physical shop, a global airline, a subscription platform, a government department, a marketplace, a mobility app, a hotel, a hospital, or a digital content provider.

The merchant is responsible for truthful onboarding information, compliant acceptance, secure handling of payment data, correct transaction submission, clear customer disclosures, evidence retention, refund practices, and cooperation during disputes and fraud investigations.

Acquirer

The acquirer contracts with the merchant directly or sponsors it through an approved model. The acquirer submits transactions to the network and is accountable for the merchant’s behaviour under scheme rules.

The acquirer normally owns or controls:

• Merchant approval and risk appetite.
• Merchant identification and registration.
• Scheme sponsorship.
• Pricing and billing.
• Settlement and funding.
• Fraud and compliance monitoring.
• Chargeback and dispute handling.
• Merchant support.
• Ongoing oversight and termination.

Acquirer processor

The processor provides the high volume technical machinery. It may run the authorisation switch, message conversion, clearing preparation, settlement calculation, terminal management, fraud interfaces, and network connectivity.

A processor may serve several acquirers. The transaction may carry the acquirer’s identity to the network even though the processor operates the connection.

Payment gateway

The gateway is commonly the merchant facing technical layer for ecommerce and in app payments. It accepts payment requests from websites, mobile applications, or commerce platforms and forwards them to an acquiring processor or payment orchestration layer.

A gateway may also provide tokenisation, hosted payment pages, software development kits, fraud checks, recurring payment storage, reporting, and routing across multiple acquirers.

Payment service provider

The term payment service provider is used differently across markets. In practice, a PSP often provides merchants with one contract and one integration for card acquiring and other payment methods. It may be an acquirer, an agent of an acquirer, a payment institution, a technical provider, or a combination of these roles.

The label is less important than the legal responsibility map. A project should never assume that “PSP” automatically means licensed acquirer.

Payment facilitator

A payment facilitator, often called a PayFac, signs and services submerchants under a sponsoring acquirer. It usually performs delegated onboarding, provides the technology, manages commercial relationships, and may control settlement distribution.

The sponsor acquirer remains accountable to the card network. It therefore needs effective oversight of the PayFac’s onboarding, monitoring, prohibited merchant controls, fraud management, chargebacks, data quality, and submerchant lifecycle.

Independent sales organisation

An independent sales organisation may market acquiring services, refer merchants, provide terminals, and support merchant relationships. Its exact permissions depend on the network, country, and contract. It does not automatically become the acquirer simply because its brand appears in the sales process.

Card network or scheme

The network defines participation rules, technical standards, transaction categories, interchange arrangements, dispute processes, fraud programs, data requirements, and settlement obligations. It routes messages between acquirers and issuers and calculates network level financial positions.

Issuer

The issuer receives the authorisation request and decides whether to approve or decline the cardholder transaction. It later receives clearing data, posts the cardholder account, participates in settlement, and may raise disputes through the network.

Merchant account bank

The bank that holds the merchant’s settlement account may be the acquirer or another bank. The acquiring platform must therefore support internal book transfers, domestic credit transfers, instant payments, or other payout rails.

Technology and service partners

The wider chain may include terminal vendors, ecommerce platforms, token service providers, 3-D Secure servers, fraud vendors, key management services, cloud providers, data centres, chargeback platforms, tax engines, foreign exchange providers, and reconciliation services.

Every additional party can increase capability and speed to market, but it also adds dependency, data movement, contractual boundaries, and incident complexity.

Acquiring business models

There is no single acquiring model. The right model depends on scale, regulation, product strategy, risk appetite, technology capability, and distribution.

Direct bank acquiring

A bank contracts directly with merchants, holds the acquiring relationship with the networks, controls underwriting, receives network settlement, and funds merchants. It may own the full technology stack or use processors for selected functions.

This model gives the bank strong control over merchant quality, pricing, data, settlement, and customer service. It also requires significant investment in scheme connectivity, security, operations, certification, fraud, disputes, finance, and support.

Processor led acquiring

The acquirer owns the merchant and scheme responsibilities while a specialist processor operates major technical components. The processor may provide the switch, network interfaces, clearing files, terminal management, merchant portal, and operational tooling.

The model can reduce time to market but creates dependency on processor data, release cycles, availability, incident response, pricing, and migration capability.

PSP acquiring

A PSP gives merchants one commercial and technical service. Behind the service, transactions may be routed to one or more acquirers. The PSP may use smart routing based on geography, currency, network, cost, availability, or acceptance performance.

This model is attractive to ecommerce merchants because it simplifies integration. It can be difficult to operate if responsibility for merchant risk, settlement, disputes, token portability, and reporting is not precise.

Payment facilitator model

The PayFac brings many smaller merchants or platform sellers under one sponsored structure. Examples include appointment platforms, software platforms, mobility services, food delivery ecosystems, and creator platforms.

The model enables fast onboarding and embedded payments. Its risk comes from scale and delegation. A weak onboarding rule replicated across one hundred thousand submerchants becomes a very large acquiring problem.

Marketplace and platform acquiring

A marketplace may collect money from a buyer and distribute it among one or more sellers after deducting commission, tax, fees, or reserves. The commercial seller, merchant of record, payment facilitator, and settlement beneficiary may not be the same entity.

This model requires careful treatment of:

• Who is legally selling to the customer.
• Which name appears on the card statement.
• Which merchant category code applies.
• Who handles refunds and disputes.
• How split settlement is calculated.
• How seller balances are protected.
• Whether the platform is providing a regulated payment service.
• How negative balances are recovered.

Acquiring as a service

A licensed institution may expose acquiring capabilities through APIs to fintechs, platforms, or other banks. The client owns the user experience while the licensed provider supplies scheme access, merchant accounts, processing, settlement, and controls.

The service must not hide accountability. API convenience does not remove the need for underwriting, scheme compliance, merchant monitoring, and financial control.

Merchant onboarding: where acquiring risk begins

The transaction system is important, but the most important acquiring control often happens before the first transaction. Merchant onboarding decides who is allowed into the payment system and under what conditions.

A weak acquirer can approve transactions perfectly and still lose money because it approved the wrong merchant.

Application and business information

The merchant application normally captures:

• Legal entity name and trading names.
• Registration number and country of incorporation.
• Registered and operating addresses.
• Ownership and ultimate beneficial owners.
• Directors and authorised signatories.
• Settlement bank account.
• Websites, applications, physical locations, and sales channels.
• Products and services sold.
• Expected card turnover and average transaction value.
• Highest expected transaction value.
• Domestic and international sales mix.
• Card present and card not present mix.
• Refund expectations.
• Delivery time between payment and fulfilment.
• Recurring, instalment, subscription, or prepayment activity.
• Previous acquiring relationships and termination history.
• Requested currencies and countries.
• Use of third party sellers or fulfilment partners.

The data must be treated as a risk profile, not a form filling exercise.

KYB and ownership verification

Know your business checks establish that the entity exists, is controlled by identifiable persons, and is permitted to conduct the stated activity. Depending on the market and risk, checks may include company registry validation, beneficial ownership verification, director screening, sanctions screening, politically exposed person screening, adverse media review, bank account ownership, licence validation, website review, physical inspection, and source of funds or wealth assessment.

The acquiring team must also confirm that the real business matches the declared business. A company registered as a software consultancy but operating a high risk online trading site is not simply a data quality issue. It is a merchant risk event.

Merchant category code

The merchant category code, or MCC, classifies the merchant’s primary business activity. It influences network rules, interchange qualification, fraud monitoring, regulatory treatment, card controls, rewards, and reporting.

MCC selection should be based on the actual goods or services sold, not on the code that produces the cheapest pricing or easiest approval. Incorrect MCC assignment can cause scheme non compliance, incorrect cardholder treatment, poor fraud models, and inaccurate reporting.

A marketplace or mixed business may require additional analysis because one platform can contain sellers from many categories. The acquiring model and scheme rules determine whether submerchant level classification is required.

Underwriting

Underwriting estimates the probability and size of future loss. The key question is not only “Will this merchant commit fraud?” It is also “Could this merchant become unable to deliver, refund customers, or absorb chargebacks?”

A travel company may be honest and still present high exposure because customers pay months before travel. A ticket seller may collect a large amount today for an event next year. A subscription merchant may create recurring disputes if cancellation is unclear. A new ecommerce merchant may be legitimate but vulnerable to card testing and account takeover.

Underwriting commonly considers:

Decision and conditions

The outcome is not always approve or decline. An acquirer may approve with conditions such as:

• A transaction or monthly volume limit.
• A rolling reserve.
• Delayed settlement.
• A bank guarantee or security deposit.
• Restricted countries or currencies.
• Restricted transaction types.
• Mandatory 3-D Secure.
• Mandatory delivery evidence.
• Additional fraud controls.
• More frequent financial review.
• Prohibition of third party sellers.
• A staged go live with controlled volume.

These conditions must be technically enforceable. A risk committee decision that remains only in a document is not a control.

Merchant hierarchy and identifiers

Acquiring platforms need a clear hierarchy because one legal customer can operate many brands, stores, websites, terminals, and settlement arrangements.

A typical hierarchy may contain:

• Acquiring customer or legal entity.
• Merchant group.
• Merchant account.
• Merchant location or outlet.
• Channel.
• Terminal.
• Store or ecommerce site.
• Settlement account.
• Pricing plan.
• Risk profile.
• Submerchant.

The exact terms vary by provider. The design principle is more important than the names: every transaction must be traceable to the correct legal entity, commercial contract, acceptance point, risk profile, pricing rule, and settlement destination.

Merchant ID

The merchant ID identifies the merchant account within an acquiring or network context. A business may have several merchant IDs for different countries, currencies, channels, legal entities, brands, or risk categories.

The MID is not always globally unique. Reconciliation should therefore use it with the acquirer, processor, network, or platform context.

Terminal ID

The terminal ID identifies an acceptance device or logical terminal. In ecommerce, the term can represent a virtual configuration rather than a physical machine.

A single physical terminal replacement must not silently break store mapping, settlement, or reporting. Terminal lifecycle management is therefore part of acquiring operations.

Merchant descriptor

The descriptor is the merchant information displayed on the cardholder statement. It should be recognisable to the customer. An unclear descriptor creates avoidable disputes because customers may not recognise a legitimate purchase.

Dynamic descriptors can include branch, service, order, or seller information, but they must remain accurate and comply with network and local rules.

Other important identifiers

Practical acquiring records often include:

• Acquirer reference number or ARN.
• Retrieval reference number.
• System trace audit number.
• Authorisation code.
• Network transaction identifier.
• Processor transaction ID.
• Gateway transaction ID.
• Merchant order ID.
• Capture or batch ID.
• Settlement batch ID.
• Funding instruction ID.
• Chargeback or case ID.
• 3-D Secure transaction identifiers.
• Token and token requestor identifiers.

No single identifier follows every stage perfectly. A good data model creates a correlation chain across authorisation, capture, clearing, settlement, payout, refund, and dispute.

Building the merchant acceptance service

After approval, the merchant must be configured and enabled.

Contract and pricing setup

The platform stores the commercial agreement, accepted brands, currencies, transaction types, settlement frequency, fees, reserve terms, refund permissions, chargeback handling, data retention, and service levels.

Pricing configuration must be versioned. When a rate changes, the system needs to know the effective date and which transactions are governed by the old or new price.

Physical merchant setup

A physical merchant may need:

• Certified terminals.
• Merchant and terminal keys.
• Network and communication configuration.
• Contact and contactless kernels.
• Receipt settings.
• Store and cashier configuration.
• Tipping or cashback rules.
• Offline and floor limit settings where applicable.
• Terminal estate monitoring.
• Remote software and parameter updates.
• Replacement and return procedures.

The terminal is not merely a card reader. It is a controlled payment device with cryptographic, software, network, and lifecycle dependencies.

Ecommerce merchant setup

An ecommerce merchant may need:

• API credentials.
• Hosted payment page configuration.
• Client side tokenisation.
• Webhook endpoints.
• Allowed domains and redirect URLs.
• 3-D Secure configuration.
• Fraud rules.
• Recurring payment settings.
• Capture rules.
• Refund permissions.
• Test and production environments.
• Certificate or key management.
• Idempotency and retry behaviour.
• Merchant initiated transaction indicators.
• Wallet and network token support.

Go live should follow technical testing, business validation, security review, and operational readiness. A successful test authorisation alone does not prove that capture, settlement, refunds, webhooks, disputes, and reconciliation are ready.

Card present acceptance

Card present acquiring covers payments where the card or payment device interacts with a physical acceptance device.

EMV contact

The chip and terminal perform an EMV dialogue. The terminal reads application data, applies terminal rules, requests cardholder verification where needed, generates transaction cryptographic data, and sends the authorisation request through the acquirer.

The issuer uses the data to evaluate authenticity and risk. The response returns through the same chain, and the terminal completes the transaction according to the result.

Contactless

Contactless acceptance uses near field communication and EMV contactless specifications. Depending on the amount, device, market, and risk, the cardholder may complete the transaction without entering a PIN or may be asked for verification.

Mobile wallets normally present a payment token and device generated cryptographic data rather than exposing the underlying card number to the merchant.

Magnetic stripe and fallback

Magnetic stripe and fallback handling remain relevant in some markets but carry higher counterfeit risk. Fallback should be monitored because repeated fallback can indicate damaged chips, poor terminal configuration, or fraud.

The system should distinguish legitimate fallback from merchants or attackers attempting to avoid chip controls.

Cardholder verification

Cardholder verification may include online PIN, offline PIN, signature in limited environments, consumer device verification, no CVM for eligible contactless transactions, or other approved methods.

The acquirer must pass accurate terminal and verification data. An issuer cannot make a sound decision if the transaction falsely claims a stronger verification method than was actually used.

Offline capability

Some EMV environments support offline decisions under controlled conditions. This does not mean the merchant can freely approve transactions without issuer contact. Offline behaviour is governed by card, terminal, scheme, and risk parameters and creates later financial exposure.

Modern always connected environments often prefer online authorisation, but transport, aviation, unattended, or connectivity constrained use cases may require carefully designed alternatives.

Card not present acceptance

Card not present acquiring covers ecommerce, in app, mail order, telephone order, subscriptions, credentials on file, and other situations where the physical card is not read by a terminal.

CNP transactions have different fraud patterns because possession of card data does not prove possession of the physical card or identity of the legitimate cardholder.

Checkout and data capture

A digital checkout may collect a PAN or token, expiry, security code where allowed, billing details, device information, order details, shipping information, customer history, and authentication data.

The safest design reduces direct exposure of the merchant environment to sensitive card data through hosted fields, redirects, client side tokenisation, network tokens, or other approved architectures.

Gateway and orchestration

The gateway validates the request, applies merchant configuration, tokenises data where required, invokes fraud and authentication services, selects a route, and sends the transaction to the processor.

Large merchants may use orchestration to route across multiple PSPs or acquirers. Routing can improve resilience and acceptance, but it must respect token portability, regulatory scope, network rules, local acquiring requirements, and accurate transaction indicators.

Credentials on file

A merchant may store a token representing a card credential for future use. The first transaction and later transactions must be classified correctly.

The distinction between a cardholder initiated transaction and a merchant initiated transaction is important. A subsequent payment cannot simply be marked as merchant initiated to avoid authentication. It must be based on a valid prior agreement, use the correct network indicators, and represent a genuinely merchant initiated event under applicable rules.

The authorisation flow

Authorisation asks whether the issuer is willing to approve a specific transaction at that moment.

A typical flow is:

1. The cardholder presents a card, wallet, or stored credential.
2. The merchant creates a payment request.
3. The terminal, gateway, or commerce platform sends it to the acquiring processor.
4. The acquirer validates the merchant, transaction type, message, and risk controls.
5. The acquirer sends the request through the relevant network.
6. The network routes it to the issuer or an approved stand in service.
7. The issuer checks card status, available funds or credit, authentication data, fraud risk, controls, and other rules.
8. The issuer approves or declines.
9. The response returns through the network and acquirer to the merchant.
10. The merchant completes or refuses the sale.

What the acquirer checks

The acquiring side may validate:

• Is the merchant active?
• Is the terminal or API credential valid?
• Is the transaction type permitted?
• Is the amount within merchant limits?
• Is the currency enabled?
• Is the country or channel allowed?
• Is the message structurally valid?
• Is duplicate submission suspected?
• Are required authentication or security data present?
• Does the merchant or transaction trigger fraud controls?
• Is the route available?
• Is the merchant above its approved volume or exposure?

A decline can therefore come from the acquirer before the request reaches the issuer.

What approval means

An approval means the issuer has accepted the authorisation request under the data presented. It usually creates or updates a hold against the cardholder’s funds or credit.

It does not guarantee that the merchant has been funded. The transaction still needs to be completed, captured, cleared, accepted into settlement, and reconciled.

This distinction is one of the most important lessons in card acquiring.

Timeouts and reversals

If the merchant or acquirer does not receive a response, it may not know whether the issuer approved the request. Retrying blindly can create duplicate holds or duplicate transactions.

The correct design uses:

• Unique transaction identifiers.
• Idempotency controls.
• Response matching.
• Reversal messages where appropriate.
• Timeout specific rules.
• Late response handling.
• Duplicate detection.
• Operational repair queues.

A reversal releases or corrects an authorisation that should no longer stand. It is not the same as a refund, because a refund normally occurs after a financial transaction has been captured or cleared.

Stand in processing

A network or processor may make a limited decision when the issuer is unavailable, based on agreed parameters. Stand in increases continuity but must be controlled because the issuer did not make the live decision.

The acquiring platform should preserve indicators showing how the transaction was authorised.

Authorisation, capture, clearing, settlement, and funding

These stages are often incorrectly treated as one event.

Authorisation

The issuer approves or declines the proposed transaction.

Capture

The merchant confirms that the transaction should move to financial processing. Capture may happen immediately, at end of day, after shipment, after checkout, or after the final amount is known.

A restaurant may authorise an estimated amount and capture a final amount including tip. A hotel may place an initial authorisation, request incremental authorisations, and capture the final bill at checkout. An ecommerce merchant may authorise at order time and capture when goods ship.

Clearing

The acquirer submits financial transaction records through the network. The network validates, enriches, prices, and passes the records to the issuer. Clearing establishes the financial obligation and carries the final transaction data used for posting, interchange, and settlement.

An approved authorisation can fail to clear. A clearing record can also differ from the authorisation. These differences must be controlled.

Network settlement

The network calculates net obligations among participating institutions according to its settlement cycles and rules. The acquirer receives or owes a net position that includes purchases, refunds, chargebacks, fees, adjustments, and other financial items.

Merchant funding

The acquirer calculates what the merchant should receive and sends funds to the merchant’s settlement account after applying agreed deductions, reserves, adjustments, and timing rules.

Network settlement and merchant funding are related but not identical. An acquirer may fund merchants before it receives network settlement, after it receives settlement, or according to another agreed schedule. The difference creates liquidity and credit exposure.

Transaction types and their practical meaning

Acquiring platforms must model transaction types correctly because each has different financial, fraud, operational, and dispute behaviour.

Terminology varies across APIs and processors. A business analyst must map the commercial meaning to the exact network messages and platform states rather than assuming that two systems use “void,” “reversal,” or “refund” in the same way.

Acquiring economics

The merchant pays for acceptance through a commercial price often called the merchant discount rate or merchant service charge. The amount may be a percentage, a fixed fee, or a combination.

The merchant price can contain several components:

• Interchange paid by the acquirer to the issuer for many purchase transactions.
• Network or scheme fees.
• Acquirer margin.
• Processor cost.
• Gateway or platform fee.
• Terminal rental or device fee.
• Fraud and authentication service charges.
• Cross border or currency charges.
• Chargeback and retrieval fees.
• Settlement or payout fees.
• Minimum monthly fees.
• Compliance or non compliance fees.
• Value added service fees.

Interchange is not usually the acquirer’s revenue. It is commonly a cost transferred through the card system from acquirer to issuer. The acquirer earns its margin after covering interchange, network, processing, risk, service, capital, and operating costs.

Blended pricing

The merchant pays a simple rate for a category of transactions. The provider absorbs variation in underlying costs.

This is easy to understand but can hide the cost composition.

Interchange plus plus

The merchant pays actual interchange, network fees, and a separately stated acquiring markup. This gives transparency but creates more complex statements and variable charges.

Flat pricing

The merchant pays the same published percentage and fixed amount across a broad set of transactions. This is common for small merchants and platform models.

Tiered pricing

Transactions are grouped into pricing tiers based on qualification. This can be difficult for merchants to understand and requires clear disclosure.

Cost drivers

The underlying cost and risk can vary according to card product, domestic or cross border status, merchant category, channel, authentication, data quality, transaction timing, network, region, and regulatory caps.

A project should never hard code one “interchange percentage” into a business case. Rates and qualification rules change and are market specific.

Merchant settlement and reserves

The merchant expects one simple result: money in the bank. Producing that result accurately is a major acquiring capability.

Settlement schedule

Merchant funding may be same day, next business day, or after several days. The timing depends on market infrastructure, currency, merchant risk, cutoffs, weekends, holidays, payout rails, reserves, and contract.

Terms such as T plus one should be defined precisely. Does T mean transaction date, capture date, clearing date, network settlement date, or business date? Which time zone applies? What happens after cutoff? What happens on a holiday?

Gross and net settlement

In gross settlement, the merchant receives the transaction amount and fees are collected separately.

In net settlement, fees, refunds, chargebacks, reserves, or adjustments are deducted before the payout.

The merchant statement must make the calculation understandable.

Reserve models

A reserve protects the acquirer against future refunds, chargebacks, fines, or merchant failure.

Common models include:

• Upfront reserve.
• Rolling reserve, where a percentage of each settlement is held and released later.
• Fixed reserve amount.
• Delayed settlement.
• Event based reserve.
• Guarantee or collateral.
• Dynamic reserve based on risk changes.

Reserve calculation, release, use, and closure treatment must be transparent and auditable. A reserve is not revenue. It is a controlled balance associated with potential future obligations.

Negative merchant balances

Refunds, chargebacks, fees, or adjustments can exceed current sales. The merchant position becomes negative.

The acquiring platform needs rules for:

• Netting against future sales.
• Direct debit or account recovery.
• Reserve usage.
• Credit line or overdraft.
• Collection and legal recovery.
• Suspension of refunds or acceptance.
• Escalation and closure.

Negative balance management is especially important in platform and submerchant models.

Reconciliation and financial control

Acquiring reconciliation is not one comparison. It is a chain of comparisons across systems and stages.

A complete model reconciles:

1. Merchant requests against gateway records.
2. Gateway records against processor authorisations.
3. Authorisations against captures and reversals.
4. Captures against clearing submissions.
5. Clearing submissions against network acceptance.
6. Network settlement against acquirer settlement accounts.
7. Merchant payable calculations against payout instructions.
8. Payout instructions against bank confirmations.
9. Fees and adjustments against billing records.
10. Operational transaction records against the general ledger.

Common reconciliation breaks

• Authorisation approved but never captured.
• Capture created without a matching authorisation.
• Duplicate capture.
• Reversal not matched to the original authorisation.
• Clearing rejected by the network.
• Amount or currency changed unexpectedly.
• Merchant mapped to the wrong settlement account.
• Fee configuration differs between pricing and settlement.
• Refund posted twice.
• Chargeback received but not allocated to the merchant.
• Network settlement file missing or duplicated.
• Payout instruction rejected by the bank.
• Rounding differences across currencies.
• Cutoff or business date mismatch.
• Late presentment.
• Missing reference chain.

Suspense and repair

Unmatched financial items should move to controlled suspense accounts and operational repair queues. They should not disappear into manual spreadsheets without ownership.

Each break needs:

• A unique case.
• Financial amount and currency.
• Source systems.
• Expected and actual state.
• Owner.
• Age.
• Materiality.
• Repair action.
• Accounting treatment.
• Audit trail.
• Root cause category.

Reconciliation is where hidden technology defects become visible as money.

Ledger and accounting view

The acquiring ledger must represent several kinds of balances:

• Amounts receivable from networks or issuers.
• Amounts payable to merchants.
• Merchant fees receivable.
• Network and interchange costs payable.
• Reserve liabilities.
• Chargeback and refund positions.
• Settlement bank balances.
• Suspense balances.
• Processor or partner balances.
• Tax positions where applicable.
• Foreign exchange gains or losses.
• Scheme fines and operational losses.

The accounting event should be linked to the business event. A ledger entry called “card settlement adjustment” without transaction, merchant, batch, or scheme references is difficult to investigate.

The platform must also define whether postings occur at authorisation, capture, clearing, network settlement, merchant funding, or a combination. Authorisation holds are normally different from final financial ledger entries. The correct design depends on whether the institution operates the issuer side, acquirer side, merchant wallet, settlement account, or several of these together.

Merchant and transaction fraud

Acquiring risk has two broad dimensions: fraudulent transactions at a legitimate merchant and a fraudulent or abusive merchant.

Transaction fraud

Examples include:

• Stolen card use.
• Card testing with many small attempts.
• Account takeover.
• Bot driven checkout attacks.
• Synthetic identities.
• Friendly fraud.
• Refund abuse.
• Digital goods abuse.
• Triangulation fraud.
• Promotion and voucher abuse.
• Fraud through compromised merchant credentials.

Transaction fraud

Examples include:

• A fake merchant collecting payments without delivering.
• A merchant processing sales for an undisclosed third party.
• Transaction laundering.
• Factoring or processing another merchant’s transactions.
• Bust out behaviour, where volume grows rapidly before the merchant disappears.
• Collusive transactions.
• False refunds to related cards.
• Misuse of card verification transactions.
• Sale of prohibited or illegal goods.
• Descriptor manipulation.
• Deliberate MCC misclassification.
• Creation of shell submerchants.

The acquirer must monitor both transaction level and merchant level behaviour. An issuer may stop one suspicious card transaction. Only the acquirer can see the pattern across the merchant estate.

Acquiring fraud controls

Useful controls include:

• Merchant and submerchant velocity.
• Sudden volume or ticket size change.
• Approval and decline pattern.
• Excessive account verification.
• High refund ratio.
• Refunds to unrelated credentials where prohibited.
• Chargeback and fraud ratios.
• Geographic mismatch.
• Device and IP intelligence.
• Repeated cards across many submerchants.
• Unusual night or weekend activity.
• Dormant merchant reactivation.
• Website and product monitoring.
• Descriptor consistency.
• MCC consistency.
• Settlement bank account changes.
• Beneficial ownership changes.
• High risk keyword or domain monitoring.
• Links between merchants, owners, devices, accounts, and cards.

Risk controls should produce actions, not only scores. Actions may include review, step up authentication, transaction decline, capture delay, reserve increase, settlement hold, merchant suspension, or termination.

PCI DSS, encryption, tokenisation, and data responsibility

Acquirers operate in an environment where payment account data must be protected throughout its lifecycle.

PCI DSS provides technical and operational requirements for entities that store, process, transmit, or can affect the security of cardholder data. Merchants, acquirers, processors, gateways, and service providers may all have obligations depending on their role and environment.

Compliance is not a one time certificate. It requires continuous control, evidence, scanning, testing, access management, monitoring, vulnerability management, incident response, and oversight of service providers.

Scope reduction

A good acquiring product helps merchants reduce the systems that directly handle sensitive data. Common approaches include:

• Hosted payment pages.
• Hosted fields.
• Redirect checkout.
• Client side tokenisation.
• Network tokenisation.
• Point to point encryption.
• Approved payment terminals.
• Segmented cardholder data environments.

Scope reduction does not mean responsibility disappears. Merchant websites, scripts, access controls, integrations, and service provider dependencies can still affect payment security.

Sensitive authentication data

Sensitive authentication data has stricter treatment than ordinary business data. Systems must not retain prohibited elements after authorisation. Logging, observability, data lakes, support screenshots, test tools, and developer traces are common places where sensitive data can leak unintentionally.

A secure design masks data by default and prevents it from entering logs.

Tokenisation

Tokenisation replaces a card number with another value.

A gateway token may be usable only within one provider. A merchant token may represent a customer’s stored credential. A network token is provisioned within the card network token ecosystem and may have domain controls and lifecycle updates.

Tokens improve security and continuity, but the design must answer:

• Who owns the token?
• Where can it be used?
• Can it move to another acquirer?
• How is it mapped to the merchant customer?
• How are updates and deletions handled?
• What happens when a card is replaced?
• Which token is used in disputes and reconciliation?
• Which parties remain in PCI scope?

Point to point encryption

Point to point encryption protects card data from the acceptance device to a secure decryption environment. It reduces exposure within merchant systems when implemented under the relevant approved solution and operational controls.

Encryption is only as strong as its key management, device integrity, certificate lifecycle, access controls, and monitoring.

EMV 3-D Secure and strong customer authentication

EMV 3-D Secure supports the exchange of transaction, merchant, payment, device, and risk data between the merchant side and issuer side so the issuer can authenticate the cardholder for ecommerce payments.

A typical 3DS ecosystem includes:

• The merchant checkout.
• A 3DS server on the merchant or PSP side.
• The directory server in the network domain.
• The issuer’s access control server.
• The cardholder’s browser or application.
• The payment gateway and acquirer.

Frictionless flow

The issuer evaluates the data and authenticates without asking the cardholder for an additional interaction. The customer experiences little or no interruption.

Challenge flow

The issuer requests an additional step, such as approval in a banking application or another supported authentication method.

The purpose is not to challenge every customer. The purpose is to provide enough trustworthy data for risk based authentication and challenge only where needed.

Acquirer responsibilities

The acquiring side must ensure that:

• The merchant is enrolled correctly.
• The right 3DS version and message data are used.
• Authentication results are linked to the payment.
• Electronic commerce indicators and authentication values are carried accurately.
• Exemptions or out of scope claims are applied correctly where local regulation allows them.
• Recurring and merchant initiated relationships are represented accurately.
• Failed authentication is handled according to merchant, issuer, regulatory, and scheme rules.
• Evidence is retained for disputes and audits.

In the European Economic Area, strong customer authentication requirements affect many electronic card payments. Exemptions and merchant initiated treatment are not shortcuts. Their eligibility, risk, transaction history, agreements, and data indicators must be managed correctly.

Disputes and chargebacks

A chargeback is a network governed financial process through which an issuer can return a transaction to the acquirer under an applicable reason and evidence framework.

From the merchant’s perspective, a chargeback may feel like money being taken back. From the acquirer’s perspective, it is a formal financial claim with deadlines, evidence requirements, scheme rules, and exposure.

Typical lifecycle

The exact stages and names vary by network and region, but a dispute can involve:

1. Cardholder inquiry or complaint.
2. Issuer investigation.
3. Information request where applicable.
4. Chargeback raised to the acquirer.
5. Acquirer notification and merchant debit or provisional handling.
6. Merchant evidence collection.
7. Representment where justified.
8. Further challenge or pre arbitration.
9. Arbitration or final liability.
10. Financial posting, fee assessment, and case closure.

Evidence

Useful evidence depends on the dispute reason and may include:

• Transaction receipt.
• EMV data.
• 3DS authentication result.
• Proof of delivery.
• Customer communication.
• Terms accepted at checkout.
• Cancellation policy.
• Refund record.
• Device and login history.
• Order details.
• Service usage.
• Merchant descriptor.
• Recurring mandate.
• Prior undisputed transaction relationship.

Evidence should be collected during the transaction lifecycle, not reconstructed after a chargeback arrives.

Chargeback operations

A strong system controls:

• Scheme deadlines.
• Case status.
• Reason codes.
• Financial postings.
• Merchant communication.
• Evidence completeness.
• Document security.
• Representment decisions.
• Fees.
• Recovery from merchant balance or reserve.
• Network responses.
• Final outcome.
• Root cause analytics.

Chargebacks are not only an operations problem. High disputes may reveal poor descriptors, unclear cancellation, weak customer service, fraud, product quality issues, or merchant misconduct.

Refunds are not reversals

This distinction causes frequent defects.

A reversal normally corrects or cancels an authorisation before final financial completion. It helps release the cardholder hold.

A refund returns money after a completed purchase. It creates a new financial transaction linked to the original purchase.

A void is a platform term that may mean cancellation before batch closure, cancellation before clearing, or a reversal request. Its exact meaning must be defined.

The product should prevent:

• Refund above the permitted amount.
• Duplicate refund.
• Refund to an unrelated card where not allowed.
• Refund before original transaction identification.
• Refund after merchant closure without controlled handling.
• Refund when merchant balance cannot cover it without an exposure decision.
• Refund data that cannot be matched in settlement.

Acquiring operations

Card acquiring is a 24 hour operational service even where clearing or merchant funding runs in batches.

Real time monitoring

Teams monitor:

• Authorisation availability.
• Response time.
• Technical decline rates.
• Issuer decline distribution.
• Timeout rate.
• Reversal success.
• Duplicate rate.
• Route health.
• Network connectivity.
• HSM and key services.
• 3DS performance.
• Fraud service performance.
• Terminal connectivity.
• API errors.
• Webhook delivery.
• Processor queues.
• Capacity and latency.

End of day monitoring

Teams also monitor:

• Capture completion.
• Open authorisations.
• Clearing file creation.
• Network acknowledgement.
• Rejected records.
• Settlement file receipt.
• Merchant funding calculation.
• Payout creation.
• Bank response.
• General ledger posting.
• Reconciliation breaks.
• Fee and reserve calculation.

Merchant support

Merchant questions commonly include:

• Why was a payment declined?
• Why is a payment missing from the portal?
• Why was the customer charged twice?
• Why has settlement not arrived?
• Why is the payout amount lower than sales?
• Why was a reserve held?
• How should a refund be processed?
• What does a chargeback mean?
• Why is the terminal offline?
• Why did a wallet or 3DS transaction fail?
• Why does the statement descriptor look wrong?

Support tools need a complete transaction timeline. Showing only the authorisation response is not enough.

Incident ownership

An incident may cross merchant, gateway, processor, network, issuer, fraud, settlement, and bank payout systems. The operating model needs one coordinating owner, clear severity rules, technical and business impact, merchant communication, financial exposure tracking, recovery steps, and post incident action.

Acquiring system architecture

A modern acquiring platform may contain the following components.

Merchant management system

Stores merchant, owner, contract, hierarchy, MID, terminal, pricing, risk, settlement, and lifecycle information.

Onboarding and underwriting

Collects applications, integrates KYB services, evaluates risk, manages approvals, and enforces conditions.

Terminal management system

Registers terminals, distributes configuration, manages software versions, monitors devices, and supports key or certificate lifecycle processes.

Gateway and payment APIs

Accept merchant requests, authenticate the merchant, validate messages, tokenise credentials, and expose payment operations.

Payment orchestration

Chooses routes, handles retries, normalises provider responses, and coordinates multiple payment services.

Acquiring switch

Processes high volume authorisation and financial messages, applies routing, validates merchant controls, and connects to networks or processors.

HSM and key management

Performs protected cryptographic operations and manages keys, certificates, and security domains.

Fraud and merchant risk

Scores transactions, monitors merchant behaviour, creates alerts, and supports investigation and action.

3-D Secure server

Coordinates merchant side authentication messaging for ecommerce.

Clearing engine

Creates, validates, receives, and processes clearing records and network files.

Settlement and funding engine

Calculates network positions, merchant payables, reserves, fees, adjustments, and payout instructions.

Pricing and billing

Applies merchant pricing and produces invoices, statements, and fee details.

Reconciliation platform

Matches records across payment, network, banking, partner, and ledger sources.

Dispute platform

Manages chargeback cases, evidence, deadlines, financial events, and network interaction.

Merchant portal

Provides transaction search, reports, settlement statements, refunds, dispute actions, user management, and support.

Data and reporting platform

Supports operational reporting, risk analytics, finance, merchant insights, regulatory reporting, and scheme reporting.

A diagram can make this stack look sequential, but production behaviour is event driven and stateful. A refund may arrive months after the original sale. A chargeback may arrive after merchant closure. A network adjustment may affect a previous settlement period. The architecture must preserve durable relationships across time.

Data and event design

The transaction state should not be represented by one mutable status field such as “SUCCESS.”

A useful state model separates:

• Authentication status.
• Authorisation status.
• Capture status.
• Clearing status.
• Network settlement status.
• Merchant funding status.
• Refund status.
• Dispute status.
• Reconciliation status.
• Accounting status.

A payment can be authorised, partially captured, cleared, merchant funded, partially refunded, and later disputed. One status cannot describe that accurately.

Event principles

A robust platform should use:

• Immutable event identifiers.
• Idempotent processing.
• Correlation across stages.
• Event time and processing time.
• Original and current amount.
• Original and settlement currency.
• Business date and calendar date.
• Source system.
• Versioned schemas.
• Clear retry semantics.
• Dead letter and repair handling.
• Audit history.
• Personally identifiable and payment data protection.
• Retention and deletion rules.

Where Kafka or another event platform is used, publishing an event does not by itself prove financial completion. Consumers, ledger postings, settlement outputs, and reconciliation must confirm the end to end result.

Non functional requirements

Acquiring is a high availability, low latency, high integrity service.

Availability

Authorisation services often require continuous availability. Planned maintenance must account for global merchants, time zones, and network obligations.

Performance

The platform must meet response time expectations under normal and peak load. Slow responses can create checkout abandonment, duplicate retries, and uncertain transaction outcomes.

Scalability

Capacity planning must consider seasonal peaks, flash sales, travel events, salary days, transport rush hours, and card testing attacks, not only average volume.

Resilience

The design needs controlled failover, route degradation, queue protection, back pressure, replay, disaster recovery, and dependency isolation.

Security

Security includes merchant authentication, least privilege, key management, secure software delivery, data masking, network segmentation, vulnerability management, monitoring, and incident response.

Financial integrity

No transaction should be silently lost, duplicated, or altered. Recovery must preserve financial state, not merely restore service availability.

Auditability

Every important configuration, approval, transaction, risk action, settlement adjustment, and manual repair needs an attributable audit trail.

Practical implementation view for business analysts

A card acquiring project can appear to be an API integration. It is actually a business, risk, finance, operations, data, and technology transformation.

Questions to settle before design

• Who is the legal acquirer?
• Who contracts with the merchant?
• Who performs KYB and underwriting?
• Who owns scheme registration?
• Which networks, countries, currencies, and channels are in scope?
• Which merchant types are prohibited or restricted?
• Who carries fraud, chargeback, and merchant insolvency exposure?
• Who receives network settlement?
• Who funds the merchant?
• Which payout rails are used?
• How are reserves controlled?
• Which processor and gateway are used?
• Who owns tokens?
• How are disputes exchanged?
• Which system is the source of truth for merchant, transaction, settlement, and fee data?
• Which ledger accounts and accounting events are required?
• What happens when a partner is unavailable?
• How does a merchant exit or migrate?

Requirement areas

A complete requirement set normally covers:

• Merchant application.
• KYB and screening.
• Underwriting and approval.
• Merchant hierarchy.
• Pricing.
• Contracting.
• Terminal or API provisioning.
• Authentication and authorisation.
• Capture and reversal.
• Clearing.
• Scheme settlement.
• Merchant funding.
• Fees and reserves.
• Refunds.
• Fraud and merchant monitoring.
• PCI and security.
• 3DS and regulatory authentication.
• Disputes.
• Reconciliation.
• General ledger.
• Reporting.
• Merchant portal.
• Operations and support.
• Data retention.
• Migration.
• Service management.

Mapping requirements

Do not map only request and response fields. Map the business meaning and lifecycle of each field.

For example, a merchant reference may be optional in the processor API but mandatory for merchant reconciliation. A 3DS result may be present in authorisation but also needed later for dispute evidence. A network transaction ID may be generated after authorisation and required for subsequent merchant initiated payments. A settlement date may differ from the merchant payout date.

Decision tables

Acquiring needs explicit decision tables for:

• Merchant approval.
• MCC assignment.
• Route selection.
• Authentication requirement.
• Retry and reversal.
• Capture timing.
• Settlement timing.
• Reserve application.
• Refund permission.
• Negative balance handling.
• Chargeback recovery.
• Merchant suspension.
• Manual repair.

Decision tables reduce ambiguity and improve test coverage.

Testing an acquiring platform

Testing must go beyond one successful payment.

Merchant lifecycle tests

• New merchant approval.
• Conditional approval.
• Rejected merchant.
• Beneficial owner mismatch.
• Settlement account change.
• MCC change.
• Pricing change with future effective date.
• Merchant suspension and reactivation.
• Terminal replacement.
• Merchant closure with open refunds and disputes.
• Submerchant onboarding and termination.

Payment tests

• Approved and declined authorisation.
• Timeout with late approval.
• Duplicate request.
• Reversal.
• Partial capture.
• Multiple capture where supported.
• Capture above authorised amount where not allowed.
• Incremental authorisation.
• Partial approval where supported.
• Refund and partial refund.
• Duplicate refund.
• Contact, contactless, wallet, ecommerce, recurring, and merchant initiated flows.
• 3DS frictionless and challenge.
• Authentication failure.
• Token lifecycle event.
• Foreign currency transaction.
• Cross border transaction.
• Offline or deferred acceptance where supported.

Financial tests

• Clearing acceptance and rejection.
• Network settlement.
• Gross and net merchant funding.
• Fee calculation.
• Reserve hold and release.
• Negative merchant balance.
• Chargeback debit and representment credit.
• Payout rejection and retry.
• Holiday and cutoff behaviour.
• Rounding.
• Multi currency settlement.
• General ledger balancing.
• Reconciliation breaks and repair.

Non functional tests

• Peak volume.
• Failover.
• Dependency timeout.
• HSM unavailability.
• Network interruption.
• Message replay.
• Duplicate file.
• Corrupt file.
• Delayed settlement input.
• Access control.
• Penetration testing.
• Recovery point and recovery time.
• Audit trail completeness.

A practical end to end example

Consider a small online furniture merchant.

The merchant applies for card acceptance. The acquirer verifies the company, owners, website, settlement account, refund policy, delivery model, and expected volume. Furniture has a meaningful delivery period, so the acquirer assesses fulfilment exposure. The merchant is approved with next business day settlement, a monthly volume limit, and a small rolling reserve.

The merchant integrates a hosted checkout and receives tokens rather than storing card numbers. EMV 3-D Secure is enabled. The merchant uses authorisation at order time and capture when the item ships.

A customer buys a table for 40,000 rupees. The checkout creates an order reference. 3DS completes without a challenge based on the issuer’s risk decision. The gateway sends the authorisation through the acquirer and network. The issuer approves and places a hold.

The merchant has not yet been paid.

Two days later the warehouse confirms shipment. The merchant submits capture using the original payment reference. The acquirer links it to the authorisation and submits clearing. The network delivers the clearing record to the issuer and includes it in settlement.

The acquiring settlement engine calculates the merchant payable. It deducts the agreed merchant fee and reserve contribution. It creates a payout instruction to the merchant’s bank account. The payout is confirmed by the banking rail. The merchant portal shows gross sale, fees, reserve, and net payout.

Three weeks later the customer reports that one part was damaged. The merchant issues a partial refund. The refund is linked to the original transaction, included in clearing and settlement, deducted from the merchant position, and shown in the portal.

Months later, if a dispute arrives, the acquiring platform can retrieve the order, 3DS result, authorisation, capture, shipment evidence, refund, merchant statement, and funding entries through one correlation chain.

That is acquiring working properly. The customer sees a payment and refund. The merchant sees a sale and settlement. The acquirer sees a controlled lifecycle of risk, messages, money, evidence, and accounting.

Common implementation mistakes

Treating approval as settlement

An approved response is shown as “paid” before capture and clearing are confirmed. This causes fulfilment, accounting, and customer service problems.

Using one transaction status

A single status hides partial capture, refund, dispute, and settlement state.

Ignoring merchant risk after onboarding

Merchant behaviour changes. Ongoing monitoring is essential.

Hard coding pricing

Interchange, network charges, merchant rates, and rules change. Pricing needs effective dating and configuration.

Weak identifier design

Systems cannot trace a payment across gateway, processor, network, settlement, payout, and dispute.

Retrying without idempotency

Timeout recovery creates duplicate authorisations, captures, refunds, or payouts.

Mixing reversal and refund

The wrong financial operation is sent and cardholder funds are not corrected properly.

Assuming one calendar

Merchant day, processor day, network day, bank day, and accounting day may differ.

Ignoring negative balances

Refund and chargeback obligations remain even when the merchant has no current sales.

Designing only the happy path

Operations receives no repair tools for rejects, missing files, late responses, and mismatches.

Treating PCI as a document exercise

Sensitive data leaks through logs, support tools, test files, and analytics.

Losing authentication evidence

3DS information is used at authorisation but not retained for later dispute handling.

Unclear partner responsibility

The acquirer, processor, gateway, PayFac, and bank each assume another party owns the incident.

Good acquiring principles

A mature acquiring platform follows several simple principles:

• Know the merchant before trusting the transactions.
• Keep legal, financial, scheme, and technical roles explicit.
• Treat authorisation and financial completion as separate states.
• Preserve a correlation chain from checkout to ledger.
• Make every retry idempotent.
• Configure rules and rates with effective dates.
• Monitor merchant behaviour continuously.
• Protect payment data by design.
• Build disputes and refunds into the original payment lifecycle.
• Reconcile every material financial stage.
• Give operations repair tools, not only dashboards.
• Explain merchant settlement in plain language.
• Design for partner failure.
• Test timeouts, duplicates, partial completion, and delayed data.
• Never allow a manual adjustment without audit and accounting control.

Interview and scenario questions

What is the difference between an issuer and an acquirer?

The issuer serves the cardholder and decides whether to approve the payment. The acquirer serves the merchant, submits the transaction into the network, receives the financial result, and funds the merchant.

Is a payment gateway an acquirer?

Not necessarily. A gateway is a technical service that receives merchant payment requests. It may belong to an acquirer or connect to one or more acquirers.

Why can an approved payment still fail?

Approval is only the authorisation stage. Capture may not occur, clearing may be rejected, settlement may fail, or merchant funding may be held or rejected.

What is the merchant discount rate?

It is the price charged to the merchant for card acceptance. It can include interchange, network fees, processing, acquiring margin, gateway services, risk costs, and other agreed charges.

Why does the acquirer care about merchant insolvency?

Customers may request refunds or chargebacks after the merchant has spent the sale proceeds or stopped trading. The acquirer can remain financially liable in the card system.

Why is MCC accuracy important?

MCC affects network rules, pricing qualification, risk models, card controls, regulatory treatment, rewards, and reporting.

What is the difference between a reversal and a refund?

A reversal corrects or cancels an authorisation before final completion. A refund returns funds after a completed financial transaction.

What should happen after an authorisation timeout?

The platform should use idempotency, response matching, late response handling, duplicate controls, and a reversal where appropriate. It should not simply resend an uncontrolled payment.

Why are reserves used?

Reserves protect against future refunds, chargebacks, fines, or merchant failure. They are controlled merchant related balances, not acquirer revenue.

What is the main risk in a PayFac model?

The sponsor acquirer delegates significant merchant activity while remaining accountable to the network. Weak submerchant onboarding or monitoring can scale rapidly.

What is transaction laundering?

A merchant processes transactions for undisclosed goods, services, websites, or third parties through an approved merchant account.

What should be reconciled?

Merchant requests, authorisations, captures, clearing, network settlement, merchant funding, fees, disputes, bank confirmations, and general ledger entries.

Which metrics matter?

Important metrics include authorisation conversion, technical declines, latency, timeouts, reversal success, capture rate, duplicate rate, fraud, chargebacks, refunds, settlement timeliness, payout failures, reconciliation breaks, reserve exposure, merchant concentration, and support cases.

Acquiring functional capability catalogue

A mature acquiring platform should expose the following capabilities as governed, testable functions. Each capability needs a business owner, configuration source, event history, servicing view, reconciliation path, and exception queue. The acquirer should be able to explain not only whether a merchant processed a transaction, but why the merchant was allowed to process, how the transaction moved to payout, what fees and reserves were applied, and what evidence exists if the transaction becomes a dispute.

Merchant master data

Merchant master data should define the merchant population in scope, the data required before activation, the controls applied during processing, and the evidence retained after each decision. Runtime behaviour should connect onboarding, risk monitoring, transaction processing, settlement, merchant billing, dispute management, and finance reconciliation. For direct merchants, the evidence should be visible at merchant level. For payment facilitators and marketplaces, it should also be visible at submerchant, seller, or platform participant level where applicable. Weakness in Merchant master data usually appears as payout confusion, unreconciled breaks, avoidable disputes, uncontrolled merchant exposure, incorrect fee income, or support teams unable to explain what happened.

Acquiring operating metrics

The acquirer should manage the portfolio through metrics that connect growth, risk, service, and finance. Growth metrics include onboarded merchants, activated merchants, processing merchants, transaction count, gross processing volume, average ticket, channel mix, card-present share, card-not-present share, cross-border volume, wallet volume, and gateway conversion. Risk metrics include chargeback ratio, fraud ratio, refund ratio, reserve coverage, high-risk MCC concentration, volume spikes, transaction laundering alerts, card-testing attempts, suspended merchants, negative merchant balances, and terminated merchants.

Service metrics include onboarding cycle time, underwriting referral age, terminal delivery time, gateway activation time, authorization success rate, authorization latency, capture failure rate, payout timeliness, payout exceptions, merchant statement delivery, dispute evidence timeliness, complaint volume, and incident response. Finance metrics include merchant discount income, interchange cost, scheme fees, processor cost, gateway fees, terminal fees, chargeback fees, refund fees, reserve balances, suspense balances, GL breaks, revenue leakage, and profitability by merchant segment.

These metrics should be reviewed by merchant segment, MCC, risk tier, channel, PayFac, submerchant, currency, country, processor, and network. Aggregate acquiring numbers can hide a dangerous merchant or a broken integration. A small group of merchants can drive most chargebacks, most settlement breaks, or most revenue leakage. The management rhythm should include daily exception review, weekly risk review, monthly portfolio performance, quarterly pricing and reserve review, and immediate incident review after outage, fraud spike, settlement failure, or network compliance issue.

The merchant's year: lifecycle events on the acquiring side

A merchant relationship, like a cardholder one, lives through recurring events, and the acquiring operation's quality shows most clearly in how it handles the merchant's year.

Onboarding anniversaries bring the periodic review: the merchant's business is re-verified, its financial standing refreshed, its activity compared against what was underwritten, and its pricing re-negotiated or renewed, with the review's depth scaled to the risk the merchant has demonstrated. Seasonal rhythms shape the operation's calendar: the retailer whose volume triples in December needs capacity, fraud thresholds that recognise the season, and payout reliability at the moment cash flow matters most, and acquirers that plan the season with their merchants earn the loyalty that pricing alone never buys. Growth events test the relationship's foundations: the merchant that doubles volume in a quarter triggers re-underwriting, because growth changes risk, and the acquirer that handles the conversation as partnership rather than suspicion keeps the merchant through it.

Difficult events define the operation's character: the merchant in financial distress, where monitoring, reserve adjustments and honest conversation happen before failure rather than after; the merchant under attack, where fraud spikes demand joint response rather than unilateral termination; and the exit, whether the merchant leaves for a competitor or the acquirer exits the relationship, where data portability, final settlements and reserve release are executed to the contract's letter. Merchants talk to each other, and an acquirer's reputation in the merchant community is built almost entirely on these difficult days, not on the smooth ones.

Acquiring economics: pricing, margin and the business of acceptance

Acceptance is a business with thin margins and enormous volumes, and its economics discipline every operational choice this chapter has described.

The revenue stack starts with the merchant service charge, the fee the merchant pays per transaction, which must cover interchange paid to the issuer, scheme fees paid to the networks, and the acquirer's own processing, risk and servicing costs before any margin survives. Pricing structures translate this stack into merchant-facing offers: blended pricing quotes one rate per card type, simple to sell and opaque to reconcile; interchange-plus pricing passes interchange through at cost with a stated markup, transparent and preferred by larger merchants who can audit it; and subscription or flat models bundle acceptance into a monthly price for the smallest merchants. Each structure allocates risk differently: blended pricing bets the acquirer's mix assumption against the merchant's actual card mix, and the bet is won or lost in basis points across millions of transactions.

Cost discipline is where acquiring margin is actually made: processing efficiency, fraud and chargeback losses held to target, scheme fee optimisation through correct transaction coding, and servicing cost per merchant, all measured relentlessly because there is no fat to hide them in. Value-added services widen the thin core margin: fraud tooling, data analytics, settlement acceleration, integrated point-of-sale, and the platform features that make the acquiring relationship sticky. The strategic truth of acquiring economics is that raw acceptance is nearly a commodity, and the acquirers that prosper are the ones that make acceptance the foundation of a broader merchant relationship rather than the whole of it, which is why this chapter's operational excellence matters: in a thin-margin business, operational defects are not quality issues, they are the margin itself leaking away.

Final perspective

Card acquiring is often described as “helping merchants accept cards.” That is true, but incomplete.

The acquirer admits merchants into the card ecosystem, connects acceptance devices and digital checkouts, protects payment data, routes authorisations, submits clearing, manages network settlement, prices the service, funds merchants, watches for fraud, absorbs timing and credit exposure, handles refunds and chargebacks, reconciles money, and proves every important event to auditors, networks, regulators, merchants, and finance teams.

A good acquiring service feels simple because the complexity has been designed properly. The customer taps or clicks. The merchant receives a clear answer and predictable settlement. The issuer receives accurate transaction data. The network receives compliant messages. Operations can investigate exceptions. Finance can balance the books. Risk can see emerging exposure. The merchant can understand what happened without learning the internal architecture.

That is the real standard for card acquiring: not merely processing a transaction, but turning a moment at checkout into a secure, traceable, correctly priced, fully settled, and explainable financial outcome.

Standards and authoritative references

Acquiring rules are network, market, product, and contract specific and they change over time. Implementations should always use the current official publications applicable to the institution.

Useful primary sources include:

• PCI Security Standards Council publications for PCI DSS and related payment security standards.
• EMVCo specifications and educational material for EMV chip, contactless, payment tokenisation, and EMV 3-D Secure.
• Visa and Mastercard operating rules, transaction processing rules, merchant guidance, and dispute documentation.
• Local payment services law, strong customer authentication rules, consumer protection rules, anti money laundering law, sanctions obligations, and data protection requirements.
• The acquirer’s signed network agreements, processor specifications, certification material, merchant contracts, and approved risk policies.

This chapter explains the operating model and enduring principles. Exact fees, reason codes, deadlines, permitted practices, technical fields, and liability rules must be confirmed against the current official source for the relevant network and market.

Retail, card, operations and business alignment

For the Malla Banking Academy Consumer & Business Banking curriculum, Card Acquiring should always be read through a retail-consumer, business-customer, card-operations and back-office lens. Retail banking means the individual customer experience: account access, card usage, payments, disputes, fees, statements, fraud protection, servicing, and clear communication. Business banking means entity authority, users, mandates, files, merchant activity, facilities, reconciliation, operational evidence, and relationship support. Card operations connects both worlds because cards touch consumer spending, business purchasing, merchant acceptance, fraud monitoring, authorization, settlement, chargebacks, accounting and servicing.

This chapter is therefore not a generic banking note. It is aligned to real retail and business banking operations: what the customer sees, what staff must control, what the core or processor records, what finance reconciles, what risk and compliance monitor, and what evidence must remain available when something goes wrong.

Explain a merchant payout before declaring it settled

Assume a fictional day's captured sales of 20,000, refunds of 800, an agreed blended acquiring fee of 1.5 percent of gross captured sales (300), and a contractual reserve withholding of 500. The merchant's expected payout is 18,400. These are contract assumptions, not current interchange rates. Scheme settlement to the acquirer and the acquirer's payout to the merchant are different obligations and may occur on different calendars.

Match captured items, network clearing, scheme settlement, merchant receivable or payable, reserve movements, payout instruction and the merchant bank's outcome. A failed payout leaves the merchant payable outstanding; it does not justify charging the customer again. A chargeback may arrive after payout, creating a merchant receivable or reserve draw under the contract. Finance owns the reconciliation; operations owns the failed payout; merchant risk owns reserve and exposure decisions; compliance handles the relevant merchant-review conditions.

For a payment facilitator, identify the sponsoring acquirer, facilitator and submerchant separately. Contract delegation does not erase the sponsor's applicable scheme responsibilities. Security scope follows the actual environment and service relationships; see PCI DSS intended audience.