Merchant Payment (Merchant Transaction): Definition

A merchant payment is any electronic payment made by a customer to a business in exchange for goods or services. The simple direction — customer to business — is what separates it from a peer-to-peer transfer, and that direction sets off a whole machinery of accreditation, fees and consumer-protection rules that wouldn't apply if your friend was sending you a tenner. To accept merchant payments at all, the business has to be registered as a merchant with a bank or processor, has to identify what it sells via a Merchant Category Code, and has to accept that every transaction will pass through a layered settlement chain that takes a few percentage points along the way.

The phrase "merchant payment" sounds straightforward, but it covers everything from a £3 contactless tap at a coffee shop to a six-figure invoice paid by ACH between two manufacturers. The underlying machinery is the same — the merchant accepts the payment instruction, an acquirer routes it through a network, the issuer or the customer's bank authorises it, and a few days later the money settles into the merchant's account. What changes between use cases is the rail, the fee structure and the consumer-protection rules.

The Players in the Merchant Payment Ecosystem

Five distinct parties get involved in every card-based merchant payment, plus the customer makes six. They each take a cut.

The customer initiates the payment, using a card, a wallet, a bank app or an Open Banking authorisation. The issuer is the bank that gave the customer the card or holds the customer's account; they authorise the payment and bear fraud risk on it (or shift that risk to the merchant under defined rules). The card network — Visa, Mastercard, Amex, Discover — owns the rails the message travels along and sets the interchange rates. The acquirer (also called the acquiring bank) is the merchant's bank; they hold the merchant's account, accept liability for the merchant to the network, and settle funds into the merchant's account a few days later. The processor handles the technical message-routing between the merchant and the network. The gateway is the API layer the merchant's website or terminal actually talks to. In smaller merchants, the acquirer, the processor and the gateway are often the same company — Stripe, for example, plays all three roles at once for most customers.

For an account-to-account payment over Open Banking or FedNow or Faster Payments, the chain is shorter: customer's bank initiates, scheme clears, merchant's bank credits. No interchange, fewer parties, no scheme fees in the card sense — but also no chargeback infrastructure.

Who Actually Touches the Money

It's worth being precise about which party holds funds at which moment, because this is where merchants get caught out when things go wrong. At authorisation, nobody has moved anything — the issuer has merely flagged the funds as reserved against the customer's available balance. At settlement, the issuer debits the customer's account and the funds flow through the network into a clearing account, then into the acquirer's account, then finally into the merchant's account. If the acquirer fails between clearing and merchant credit (rare but it happens), the merchant is an unsecured creditor for that float. This is why scheme rules require acquirers to ringfence merchant funds in segregated accounts — and why "we use Stripe, we don't need a merchant account" is a slight oversimplification. Stripe is a payment facilitator with its own master merchant account that all its sub-merchants sit under, and the segregation rules still apply.

What Distinguishes a Merchant Payment from a P2P Transfer

This is the line that matters legally and commercially. A merchant payment is regulated as a commercial transaction. The merchant has registered with an acquirer, signed scheme rules, declared a category, and accepted the chargeback and refund rules. The customer has consumer-protection rights — Section 75 in the UK for purchases over £100 on a credit card, chargeback rights on a debit card, the right to dispute the transaction with their bank if the goods don't turn up.

A peer-to-peer transfer is the same technical money movement without those protections. If you send a friend £200 via Faster Payments, you don't get to dispute it later because you fell out. If a merchant accepts a P2P transfer instead of a proper merchant payment to dodge the fees, both parties lose the consumer-protection layer, and the merchant arguably also loses their right to operate under their scheme rules.

Card networks actively police this. Misclassifying merchant payments as P2P transfers — sometimes called transaction laundering or factoring — is a serious scheme-rule breach and can get a merchant terminated from accepting cards entirely.

The Grey Area: PayPal F&F, Revolut, Wise

Modern fintech wallets blur the line. A sole trader who asks a customer to "send me £50 on PayPal Friends & Family" is doing exactly the misclassification scheme rules forbid — and the customer loses purchase protection if the work isn't delivered. PayPal will close accounts when it detects this pattern. Similarly, a freelancer who routes client invoices through Revolut personal rather than Revolut Business is technically operating outside the consumer-protection framework, and HMRC will treat it the same regardless. The convenience of dodging the 1.4-2.9% merchant fee gets expensive fast when a customer disputes a £2,000 invoice and there's no scheme to fall back on.

The Settlement Flow

When a customer pays a merchant by card, the transaction goes through two distinct phases: authorisation and settlement.

Authorisation happens in real time. The gateway sends the transaction to the processor, the processor sends it to the network, the network sends it to the issuer, the issuer checks the customer has the funds and the transaction isn't suspicious, and the issuer sends back an approve or decline code. The whole chain typically completes in 200–500 milliseconds. At this point, the funds are reserved against the customer's account but not yet moved.

Settlement happens later, usually overnight or on a scheduled batch. The merchant submits the day's approved transactions to the acquirer; the acquirer claims the funds from each issuer through the network; the network nets the totals between banks; and the acquirer credits the merchant's account, minus fees, on the agreed schedule — typically T+1, T+2 or T+3 in most markets. For high-risk industries the acquirer may hold a rolling reserve as well.

This split is why "my customer paid yesterday but I haven't got the money yet" is normal and not a problem. The payment is committed at authorisation; the cash moves at settlement.

Authorisation Hold vs Capture

One nuance trips up new merchants: authorisation doesn't equal capture. A hotel that swipes a card at check-in authorises £500 to ring-fence funds for the stay, but doesn't capture (claim) the actual £312 until checkout. Until capture, the hold sits on the customer's available balance even though no money has moved. Most acquirers automatically release uncaptured authorisations after seven days, but some issuers hold them for longer, and customers get angry phone calls from their bank about "missing" money that the merchant never actually took. If your business takes deposits or pre-authorisations, capture promptly or explicitly reverse the auth — don't leave the hold hanging.

Settlement Delays and Reserves

Acquirers don't credit funds the moment a card is swiped. A standard low-risk merchant gets T+2 (two business days after the transaction) in the UK, T+1 if they pay for faster settlement, and same-day for premium tiers. For high-risk MCCs — travel, ticketing, gambling, anything where customers might chargeback months later — the acquirer holds back a percentage of every transaction as a rolling reserve, typically 5-10% held for 180 days. A new travel agent might find 10% of their revenue locked up for six months at any given time. This isn't punitive; it's the acquirer's protection against the merchant going bust before chargeback liabilities are settled. It's also why a sudden change in business profile — a flat-pack furniture merchant suddenly listing flights — gets flagged immediately.

The Merchant Category Code (MCC)

Every merchant is assigned a four-digit Merchant Category Code (MCC) when they're set up with an acquirer. The MCC describes what the merchant sells — 5411 is grocery stores, 7372 is software companies, 5812 is restaurants, 4900 is utilities. Some MCCs are gambling, adult content or political donations, and those get a different fee and risk profile.

The MCC drives a surprising amount. It sets the interchange tier the merchant pays. It determines whether the issuer is allowed to authorise the transaction at all (some cards block adult-content MCCs by default). It influences fraud-monitoring thresholds, points-and-rewards eligibility, and even consumer cashback rates. Merchants who think their interchange is too high should check what MCC they've been classified under before changing processor — sometimes a misclassified MCC is the entire problem.

When the MCC Is Wrong

We've seen this with our own customers. A B2B SaaS company classified as 5734 (computer software stores — retail) was paying retail-tier interchange instead of the lower commercial-card rate appropriate for 7372 (computer programming services). Over a year of £180k in card volume, the difference came to about £1,400 in unnecessary fees. The fix took one email to the acquirer. Similarly, charities classified as standard retail rather than 8398 (charitable organisations) miss out on the discounted interchange rate that several issuers apply for donations. Worth checking your monthly statement for the MCC code — it's usually printed near the merchant ID.

What the Merchant Pays

The total cost of accepting a card-based merchant payment splits into three layers. Interchange is the largest chunk — typically 0.2-0.3% on UK consumer debit cards, 0.3% on UK consumer credit cards (both capped by EU and UK regulation), and significantly more on commercial cards and cards issued outside Europe. The interchange goes from the acquirer to the issuer. Scheme fees are a smaller layer paid to Visa or Mastercard for using the network — usually 0.05–0.15% plus per-transaction fees. Processor markup is what the acquirer and gateway add on top. This is the one merchants can actually negotiate; the first two are set elsewhere.

Total all-in cost for a typical UK e-commerce merchant runs 1.4–2.5% of transaction value. For Amex it's higher. For an Open Banking pay-by-bank transaction, the merchant pays a flat fee — pence per transaction rather than a percentage — and no interchange at all, which is why merchants who can route customers to bank payments often do.

The Cost of a Cross-Border Payment

The fee gets worse when the customer is overseas. A US-issued card paying a UK merchant doesn't fall under the EU/UK interchange cap, so the issuer can claim up to 1.5-1.8% interchange instead of 0.3%. Add a cross-border scheme fee (typically 0.4-0.6%), a currency-conversion margin if the merchant prices in USD, and a processor markup, and the total can hit 3.5-4.5%. This is why some merchants offer dynamic currency conversion at checkout — letting the customer pay in their home currency at a slightly worse FX rate, but converting at a lower scheme fee tier. Whether that's a good deal depends on the customer, not the merchant. Most consumer-rights groups argue against DCC because the FX margin is usually worse than the customer's own card would have given them.

Interchange++ vs Blended Pricing

Merchants doing more than about £100k a month should be on interchange++ pricing — where the statement shows interchange, scheme fees and processor markup as three separate line items. Anything else is blended pricing, where the processor charges a single flat percentage and pockets the difference. Blended works for small merchants because the average works out; for larger ones it's almost always more expensive than IC++. The downside of IC++ is the statements are dense — twelve pages of fee detail per month is normal. The upside is you can see exactly where the money's going and negotiate the markup directly.

The Channels a Merchant Payment Can Use

Merchant payments aren't limited to card transactions. The full set of channels in 2026 includes card-not-present e-commerce, card-present in-store payments, telephone payments (a subset of CNP), digital wallet payments, Open Banking bank transfers, ACH payments in the US, direct debit in the UK and Europe, and instant rails like FedNow and Faster Payments. The merchant decides which channels to enable, and the trade-off in each case is fees against risk against settlement speed.

Telephone Payments: The Channel Everyone Forgets

Card-not-present over the phone is a category of its own. The merchant takes the customer's card number verbally and keys it into a virtual terminal or CRM. It's slow (90-180 seconds per transaction), it's lossy (customers misread numbers, agents mistype), and the chargeback rate is two to three times higher than e-commerce because there's no 3D Secure authentication. The bigger problem is PCI DSS: the moment an agent hears a card number, the agent's workstation, the call recording, the CRM, the phone system and everything they touch fall in scope for PCI compliance. That's why DTMF capture exists — the customer types digits on their phone keypad, the digits get masked before they reach the agent's ear, and the agent and their systems stay out of scope. Paytia's Secure Card Capture is exactly this.

Open Banking: The Channel Growing Fastest

UK Open Banking payments grew from a niche in 2021 to over 22 million payments a month by mid-2025. The economics are obvious for the merchant: a flat fee of 10-30p per transaction instead of 1.4-2.5% of value. For a £500 transaction, that's £12 saved. The trade-off is the customer journey — they have to authenticate with their banking app, which adds friction compared with a saved card. Merchants get the best result by offering Open Banking as the default for high-value transactions where the saving is large, and saved cards for low-value ones where the friction matters more. Open Banking also has no chargeback, which is great for the merchant and worse for the customer; if the goods don't turn up, the customer's only remedy is to ask the merchant for a refund.

Card-Present vs Card-Not-Present

Where the customer's card is physically presented to a terminal — chip-and-PIN, contactless, mobile wallet tap — the merchant gets the cheaper interchange tier and the issuer carries the fraud liability. The terminal proves the card was present, EMV proves it was the real chip, and the customer either authenticates with a PIN or accepts the contactless limit (£100 in the UK as of 2025).

Card-not-present transactions — online, phone, mail order — are higher fee and the merchant carries the fraud liability unless they authenticated the customer through 3D Secure 2 (3DS2). 3DS2 shifts liability back to the issuer in the same way a PIN does for card-present, which is why most CNP merchants now treat 3DS2 as effectively mandatory even when scheme rules don't strictly require it.

The fraud rate gap is real. Card-present fraud in the UK runs around 5p per £100 of spend. CNP fraud runs around 14p per £100 — nearly three times higher. The interchange and scheme fees are priced accordingly.

The Regulatory Layer

Merchant payments sit inside a stack of regulation that varies by jurisdiction but always covers four things: licensing of payment institutions and acquirers (FCA in the UK, ACPR in France, BaFin in Germany), card-data security via PCI DSS (administered by the PCI SSC, enforced by the card schemes), consumer authentication via Strong Customer Authentication rules under PSD2 in the EU/UK and equivalent rules in other markets, and anti-money-laundering and counter-terrorist-financing obligations on the acquirer to know who its merchants are.

PCI DSS in 2026

PCI DSS v4.0.1 is the current version. v4.0 went live in March 2024 and the future-dated requirements that gave merchants extra time hit their hard deadline in March 2025. By now, every merchant should be assessed against v4.0.1, not v3.2.1. The change that bites most CNP merchants is requirement 6.4.3, which mandates that payment-page scripts loaded into the browser are inventoried, integrity-checked, and justified — a response to Magecart-style skimming attacks where attackers inject card-stealing JavaScript into checkout pages. Most merchants now need either a script-monitoring tool or an SAQ-A-eligible setup where the card fields are hosted entirely on the processor's domain via an iframe.

SCA and 3DS2

Strong Customer Authentication is the EU/UK rule that says CNP card transactions need two-factor authentication unless they fit an exemption (low-value, trusted beneficiary, transaction risk analysis, merchant-initiated). The mechanism is 3D Secure 2, where the issuer's app or web challenge confirms the cardholder is who they say they are. Exemptions exist but the issuer decides whether to honour them, and many issuers now decline anything that isn't 3DS2-authenticated, regardless of exemption. A merchant that turns off 3DS2 to reduce friction usually sees their authorisation rate fall, not rise.

Failure Modes a Merchant Should Plan For

Even a well-set-up merchant payment can go wrong. The common failure modes are worth listing so a merchant can recognise them.

• Soft decline: the issuer wants 3DS2 authentication. Re-route through 3DS2 and retry — most card platforms do this automatically.
• Hard decline: the issuer has refused (insufficient funds, card blocked, suspected fraud). Don't retry; the customer needs to use a different card.
• Authorisation reversal: the issuer authorised but then reversed within the window. Usually a fraud-rule trigger on the issuer side. The merchant gets the transaction back in a pending state.
• Settlement mismatch: the captured amount doesn't match the authorised amount. Common with tips, shipping recalculations, partial refunds. Acquirers handle small variances but flag large ones.
• Chargeback: customer disputes the transaction post-settlement. Acquirer claws back the funds and the merchant has 15-45 days to defend with evidence. Costs the merchant the transaction value plus a chargeback fee (typically £15-£25).
• Friendly fraud: the customer received the goods but disputes the transaction anyway. The merchant's best defence is delivery proof and 3DS2 authentication on the original transaction.
• Account funding mismatch: the acquirer credits less than expected because of a fee rebate, a chargeback claim, a reserve hold, or a missed settlement file. Reconcile the statement to the daily batch totals to spot it early.

Best Practice for a Merchant Setting This Up

A merchant accepting card payments for the first time — or moving from one processor to another — should treat the setup as a layered checklist.

First, choose the channels that match your business. A B2B SaaS company doesn't need a card terminal; a market-stall food trader doesn't need an e-commerce gateway. Don't enable channels you won't use, because each one adds compliance scope.

Second, verify your MCC matches what you actually sell. If you're a multi-category merchant — say, a hotel that also sells gift vouchers — you might need separate merchant IDs with different MCCs.

Third, get the SAQ right. Self-Assessment Questionnaires under PCI DSS come in flavours: SAQ A for fully outsourced (Stripe iframe), SAQ A-EP for direct-post setups, SAQ D for anyone touching card data. The wrong SAQ means you're either over-compliant (paying for audits you don't need) or under-compliant (vulnerable to a much bigger fine if you breach).

Fourth, turn on 3DS2 everywhere. Authentication friction is overstated; refusal rate on properly-implemented 3DS2 is under 5%, and the chargeback protection it gives back is worth far more.

Fifth, monitor your authorisation rate weekly. A drop of more than 2-3 percentage points is a signal — either your customer base is shifting, your fraud rules are too tight, or your processor is doing something. Authorisation rate is the single most actionable merchant-payment metric and most merchants don't watch it at all.

How Paytia Fits Into This

Paytia handles the telephone-payment channel of merchant payments. When a customer calls your business to pay by card, Paytia's Secure Card Capture lets the customer key the card details into their phone — never speaking them aloud — while the agent stays on the line. Card data is masked from the agent's ear and never touches your agent's workstation, your CRM, or your call recording. The transaction is processed by your existing acquirer (we work with Stripe and the major UK and US acquirers) and the funds settle into your existing merchant account on your existing schedule. Nothing changes about your merchant of record, your MCC, your pricing or your reconciliation. What changes is that the telephone channel of your merchant payments stops dragging your contact centre into PCI DSS scope.

Frequently Asked Questions

Is "merchant payment" the same as "payment processing"?

Closely related but not identical. A merchant payment is the transaction itself — the customer paying the business. Payment processing is the technical service that routes the transaction through the network. A merchant accepts merchant payments; a processor handles payment processing. The processor enables the merchant.

Do I need a merchant account to accept payments?

Strictly speaking, yes — but if you use Stripe, Square, PayPal or a similar payment facilitator, the facilitator's master merchant account covers you and you don't need your own. The trade-off is the facilitator's pricing is usually higher than a direct acquirer relationship, but the onboarding is faster and the contract is simpler. Most merchants under about £200k a month are better off with a facilitator; above that, a direct merchant account starts to make sense.

What's the cheapest channel for a merchant payment?

Open Banking and account-to-account bank transfers are the cheapest by a wide margin — typically 10-30p per transaction regardless of value. The trade-off is the customer journey is a bit more friction than a saved card. For a £20 transaction, the saving over card is small; for a £2,000 transaction, it's substantial.

Can I pass merchant payment fees on to my customer?

In the UK and EU, surcharging on consumer debit and credit cards is banned under PSD2. You can surcharge on commercial cards and on non-EU-issued cards, but in practice most UK merchants don't. In the US, surcharging is legal in most states with specific notice requirements. Either way, scheme rules require the surcharge be no more than the actual cost of acceptance.

How long does the money take to reach my bank?

Standard settlement in the UK is T+2 — two business days after the transaction. Some acquirers offer T+1 for a fee, and a few offer same-day settlement at a premium. For high-risk merchants, expect a rolling reserve held back for 90-180 days.

What happens if my acquirer goes bust?

Merchant funds in transit are required by scheme rules to sit in segregated accounts, ringfenced from the acquirer's own balance sheet. In an insolvency, those funds should return to merchants. In practice it's slower and messier than that — Wirecard's collapse in 2020 saw merchant funds tied up for months. Diversify across more than one acquirer if you can't afford the cash-flow risk.

Are recurring subscription payments handled the same way?

Recurring card payments are flagged as merchant-initiated transactions (MIT) and are exempt from SCA on the renewal. The initial transaction needs full SCA with the customer present, and the merchant stores a network token for subsequent renewals. The interchange is the same as a normal CNP transaction but the chargeback rules are different — customers can dispute a recurring charge they thought they'd cancelled, so good cancellation flows are a fraud-prevention measure.

How does Paytia change the cost of a merchant payment?

Paytia doesn't change your interchange, scheme fees or processor markup — your existing acquirer still handles the transaction at your existing rates. What Paytia adds is a small per-transaction fee for the telephone-capture channel, which is more than offset by removing your contact centre from PCI DSS scope. For most merchants, the saving from descoping is several thousand pounds a year against a Paytia bill of a few hundred.

What's a payment facilitator and how does it differ from an acquirer?

A payment facilitator (sometimes "PayFac") is a merchant of record that aggregates many small merchants under one master merchant account with a real acquirer. Stripe, Square and PayPal are PayFacs. The PayFac onboards merchants quickly, handles compliance for them, and pays them out — but in exchange charges a flat percentage that's usually higher than a direct acquirer relationship. An acquirer is the real bank holding the merchant account; a PayFac sits on top of an acquirer and resells access.