Payments Glossary

What it means

Acceptance rate (approval rate) is approved transactions divided by attempted transactions, usually measured on deposits. Gambling runs structurally lower than mainstream e-commerce: transactions carry MCC 7995, which many issuing banks decline by policy or subject to stricter fraud scoring, and some markets block the code outright. Where e-commerce merchants see approval in the high 90s, gambling operators reportedly work in the 65-85% range depending on market and method mix.

Why it matters for operators

Every declined deposit is marketing spend wasted — the player was acquired at full CPA and then lost at the cashier, often permanently if the decline hits a first deposit. That makes acceptance rate one of the highest-leverage payment metrics in the business. The levers: payment orchestration with smart routing and cascading retries, network tokens instead of raw PANs (issuers approve tokenized transactions at higher rates), local acquiring in key markets, and offering local payment methods — Pix, open banking, wallets — that bypass card rails and their MCC problem entirely. Declines that push players toward workarounds also correlate with later chargeback activity, so the metric ties into risk as well as revenue.

Example

An operator lifts acceptance in one market from 74% to 81% by adding a local acquirer and enabling network tokens. On 50,000 monthly deposit attempts, that is 3,500 additional funded deposits with zero extra marketing spend.

What it means

Account-to-account payments move funds directly from one bank account to another over payment rails — UK Faster Payments, SEPA Instant in the eurozone, PIX in Brazil — without a card scheme in between. Pay-by-bank is the consumer-facing form: the player authorises a transfer from their own account instead of typing card details. Open banking supplies the API layer that makes initiating these transfers from a cashier practical, but A2A is the broader category — any direct bank transfer, initiated through open banking or otherwise, qualifies.

Why it matters for operators

Three properties change the payments equation. Cost: with no card network there's no interchange and no scheme fee, so per-transaction cost drops well below cards. Speed: instant rails settle in seconds, around the clock — funds are actually in the operator's account, not merely authorised, which changes cash-flow and payout timing. Disputes: there's no chargeback mechanism. A credit push authorised by the payer can't be reversed by a card issuer months later; disputes shift to bank transfer recall rules, which are far narrower.

That last point cuts both ways. Chargeback fraud disappears, but so does the card scheme's dispute framework — friendly-fraud losses fall while genuine-error recovery gets harder, and refunds become outbound payouts your reconciliation has to model separately. Fraud pressure moves from stolen cards to account takeover and authorised push payment scams, so the fraud stack needs retooling rather than retiring. And because settlement is instant and final, orchestration and ledger design need to treat A2A as its own flow, not a card variant.

The ceiling on this is visible in Brazil: PIX went from launch in late 2020 to the default payment rail of an entire market, and it's now the dominant deposit method for Brazilian iGaming. That's the existence proof that A2A doesn't have to stay a secondary option next to cards — given the right rail, it becomes the market.

Example

A Brazil-facing operator runs PIX as the primary deposit and withdrawal method. Deposits settle in seconds at a fraction of card cost, withdrawals land fast enough to be a marketing claim, and the dispute queue that card markets take for granted simply doesn't exist.

What it means

A chargeback happens when a player disputes a transaction with their card issuer rather than the operator. The bank reverses the payment, and the operator usually pays a penalty fee on top. In gambling, chargebacks are often "friendly fraud" — a player loses, then disputes the deposit.

Why it matters for operators

High chargeback ratios raise processing costs, trigger larger rolling reserves, and can get an operator dropped by acquirers or placed in costly monitoring programs. Strong KYC, clear billing descriptors, and fast support are the front-line defences. Keeping the ratio low is a survival issue, not just a cost.

Example

If chargebacks exceed roughly 1% of transactions, card networks may place the merchant in a monitoring program with steep fees and stricter terms.

What it means

The merchant of record is the legal entity that sells to the customer: its name appears on the card statement, and it owns liability for refunds, every chargeback, taxes, and compliance on the transaction. Three structures dominate. With an own MID, the operator is the MoR through a direct acquiring relationship. Under a payment facilitator, the operator is a sub-merchant — faster onboarding, but the payfac controls the relationship. In a full MoR arrangement, a third party sells on the operator's behalf and carries the transaction liability itself.

Why it matters for operators

The choice decides who underwrites the gambling risk. An own MID gives the best economics and data ownership but demands licenses, acquirer relationships per region, and KYC-grade compliance under the operator's own name. MoR structures appear where operators enter markets ahead of their own acquiring — common in grey-market expansion — trading margin and control for speed. The trade-offs are real: card schemes require accurate merchant categorization, so MoR setups that obscure the true nature of gambling transactions create miscoding risk that can end in fines and terminated MIDs. Many operators run hybrids, coordinated through payment orchestration: own MIDs in licensed core markets, MoR partners elsewhere.

Example

An operator licensed in Malta uses its own MID for EU traffic but enters a new region through an MoR partner, accepting several points of extra cost per transaction until local volume justifies direct acquiring.

What it means

Mobile money lets users hold and transfer value tied to a phone number, without a bank account or card. Agents handle cash-in and cash-out; transfers, merchant payments and deposits run over USSD or an app. M-Pesa in Kenya, MTN Mobile Money and Airtel Money across West and East Africa process a large share of consumer payments in their markets — for many players it's not an alternative payment method, it's the only one.

Why it matters for operators

In markets like Kenya, Ghana, Uganda and Tanzania, an operator without mobile money integration effectively has no deposit flow. Integration is market-by-market work: each wallet has its own API, settlement currency, fee structure and regulatory registration, and payouts (not just deposits) must work reliably because withdrawal speed drives retention. Aggregators reduce the integration burden but add margin, and reconciliation across wallets remains the operational headache.

Example

A sportsbook entering Kenya integrates M-Pesa via a local PSP. Deposits confirm in seconds over USSD — no card forms, no bank redirects — and same-day withdrawals to the same wallet become the brand's main marketing claim against slower competitors.

What it means

Open banking is a regulated framework — originating with PSD2 in the EU and UK — that obliges banks to expose APIs through which licensed third parties can initiate payments from a customer's account and read account data, with the customer's consent. In the cashier it surfaces as pay-by-bank: the player picks their bank, authenticates in their own banking app, and the deposit moves as a direct account-to-account credit transfer. No card number is entered, and no card network sits in the middle.

Why it matters for operators

The economics are the headline. A2A deposits carry no interchange or scheme fees, and because the payment is a credit push authorised by the player in their bank app, there's no chargeback mechanism to fund or defend. Strong customer authentication is built into the bank flow rather than bolted on, which is part of why pay-by-bank tends to convert well once a player has used it.

For iGaming specifically it attacks a familiar pain: card acceptance rates in a category where issuers routinely decline gambling merchant codes. A bank transfer initiated by the player doesn't hit those issuer gambling-MCC decline rules the way a card authorisation does, so in markets where card declines are the bottleneck, pay-by-bank can lift acceptance meaningfully. On the payout side, open banking data plus instant rails supports near-instant withdrawals — increasingly the retention feature that matters most.

The trade-offs are real. Bank API coverage and UX quality vary sharply by market, first-use friction is higher than a saved card, and refunds aren't native to the scheme — returning money means a fresh payout, which your reconciliation and orchestration layer has to model deliberately.

Example

An operator adds pay-by-bank alongside cards in a market where issuers decline a large share of gambling transactions. Deposits routed through open banking clear at a visibly higher rate than cards, cost less per transaction, and generate zero chargebacks — and the cashier starts steering repeat depositors toward the bank flow by default.

What it means

A payment orchestration layer sits between the cashier and a stack of PSPs, acquirers, and local payment methods, deciding where each transaction goes. Its core functions: smart routing (send a card to the acquirer most likely to approve it, based on BIN, geography, and amount), cascading (retry a declined deposit through a second and third provider automatically), failover when a PSP goes down, and unified reporting and reconciliation across every provider in the stack.

Why it matters for operators

Gambling operators rarely survive on one PSP. Providers exit the vertical, impose a rolling reserve, or fail in specific markets, so multi-PSP setups are the norm — and orchestration is what makes them manageable instead of a pile of one-off integrations. The commercial case is measured in acceptance rate: cascading alone typically recovers a meaningful share of first-attempt declines, and every recovered deposit is a saved first-time depositor the operator already paid to acquire. Orchestration also reduces switching costs, which strengthens the operator's hand when negotiating processing fees.

Example

A deposit from a Brazilian card is routed to a local acquirer rather than the default European one; it declines on a soft reason code, cascades to a second provider, and approves. Without orchestration, that player sees one decline and often never deposits again.

What it means

Strong customer authentication is the PSD2 rule that electronic payments in the EU and UK must be verified with at least two of three independent factors: something the customer knows (a PIN or password), something they possess (a phone, a card), and something they are (a fingerprint or face). On cards it's enforced through 3-D Secure challenges; in open banking flows the customer authenticates inside their own banking app, so SCA is satisfied natively rather than added as an extra step.

Why it matters for operators

SCA is where deposit conversion dies or survives. Every added authentication step loses a share of depositors, so the acceptance rate an operator actually sees depends heavily on how the exemption regime is worked. PSD2 allows exemptions for low-value transactions, for transactions a bank's transaction risk analysis (TRA) scores as low risk, and for merchants a customer has whitelisted as a trusted beneficiary — but exemptions are requested by the acquirer and granted or refused by the issuer, and issuer behaviour toward gambling merchants is often conservative. Two operators with identical traffic can see materially different challenge rates depending on which acquirers they route through and how exemptions are flagged.

This is a core reason payment orchestration earns its keep in regulated European markets: routing low-risk traffic through exemption-eligible paths and choosing acquirers by observed challenge rates is measurable revenue, not plumbing. It also explains part of pay-by-bank's appeal — the SCA already happened in the bank app the player uses daily, so after first use the flow tends to convert well with no separate 3DS hurdle.

Example

An operator's card conversion drops several points after a major issuer tightens its 3DS challenge policy for gambling merchants. The orchestration layer responds by flagging low-value deposits for the low-value exemption and shifting eligible volume to an acquirer whose TRA profile earns more frictionless approvals — recovering most of the lost conversion without touching the cashier UI.