For a cashier team, that changes authentication, routing, data, dispute handling and failure recovery. For a customer, it changes what appears on screen and which institution can explain a problem. Neither route is automatically faster, safer or more suitable in every implementation.
The two routes in one view
Open Banking Limited describes “Pay by Bank” as a journey in which the customer chooses their bank, is redirected to the bank’s app or online service, approves the payment and returns to the merchant. The regulated payment-initiation service provider, or PISP, connects the merchant journey to the bank. Its Pay by Bank guide explains that the payment then moves over bank-payment infrastructure such as Faster Payments.
A debit-card payment instead uses the card number or token, the merchant’s acquirer, a card network and the bank that issued the card. Strong customer authentication may bring the bank into the journey, but the transaction still travels under card-scheme rules.
| Question | Open-banking payment | Debit-card payment |
|---|---|---|
| What does the customer approve? | A bank-payment instruction in the bank journey | A card transaction, sometimes with an issuer challenge |
| Main routing chain | Merchant, PISP, bank and bank-payment rail | Merchant, gateway or acquirer, card network and issuer |
| Credentials | Bank authentication stays with the bank | Card details or a token identify the payment instrument |
| Failure evidence | Consent, bank status and payment reference | Authorisation response, scheme messages and acquirer records |
| Refund or dispute path | Bank-payment and provider rules | Merchant, issuer and card-scheme processes |
This is an operating comparison, not a promise about one provider. An operator may place another gateway, risk engine or orchestration layer around either route. Our payment-orchestration map shows why the button seen by the customer rarely reveals the whole chain.
Open banking is a payment instruction, not account access for everything
“Open banking” is often used as if the cashier receives unrestricted access to a customer’s bank account. It does not. In a payment-initiation journey, the customer consents to a specific action and authenticates with the bank. The PISP does not need the customer to type bank-login credentials into the gambling site.
That can reduce the amount of sensitive card data handled by the merchant journey. It can also give the cashier a bank account-based payment reference that is useful for reconciliation. But it does not remove fraud controls, operator checks or the possibility that the bank refuses the instruction.
The UK government’s National Payments Vision treats open banking as an overlay on established interbank infrastructure. It also acknowledges an unfinished protection question: consumer protection for open-banking payments does not currently mirror the framework around card payments, and government has sought a clearer commercial and regulatory model.
That difference matters. “Authorised in my bank app” is not equivalent to “every later dispute is settled in my favour”. The payment type, allegation and provider terms determine the route. A customer reporting an unauthorised payment, a service not delivered or a gambling-account dispute is describing three different problems.
Debit cards bring mature rails and extra intermediaries
Debit cards are familiar, broadly accepted and designed for near-instant authorisation at checkout. Tokenisation and bank authentication can make the customer journey simple without exposing raw card details to every component.
The trade-off is a longer institutional chain. A decline can originate from the operator, fraud system, acquirer, network or issuer. The message returned to the customer is often less specific than the actual decision. A successful authorisation is also not identical to final settlement between the institutions.
Refunds and withdrawals are separate again. A cashier may accept a debit-card deposit but use a card payout product, bank transfer or another permitted route for withdrawals. Our feature on why gambling withdrawals take longer than deposits explains why the outbound decision cannot be inferred from the deposit button alone.
Gambling blocks do not behave identically across the two routes
Many UK banks offer gambling blocks on cards. An open-banking payment does not necessarily pass through the card control because it is not a card transaction. Banks and open-banking providers therefore need explicit data and controls if a customer’s preference is to follow the payment across rails.
The Open Banking Standard’s guidance on transaction-risk indicators includes gambling-related information and discusses how banks may apply gambling blocks in a payment-initiation journey. Crucially, the implementation guidance does not prove that every bank, PISP or payment flow handles the signal in the same way.
For a responsible cashier design, the useful question is not “does open banking bypass the block?” It is whether the route identifies the merchant category clearly, respects the bank’s response and explains a refusal without prompting the customer to defeat a control.
Operators in Great Britain also remain responsible for the payment services they make available. The Gambling Commission’s licence condition 5.1.2 requires licensees to take reasonable steps to prevent payment methods that obscure or interfere with gambling-transaction identification from being used in their gambling business. Adding a new button is therefore a compliance decision as well as a conversion project.
Credit cards are a different question in Great Britain
“Cards” should not be used as shorthand for both debit and credit in a British gambling comparison. Gambling businesses licensed by the Commission generally cannot accept credit-card payments for gambling. The restriction also covers routes through money-service businesses where the operator knows or should know that a credit card funded the transaction. The Commission’s guidance on credit cards through money-service businesses explains the operator’s responsibility.
That is why this article compares open banking with debit cards. It does not suggest an open-banking route can lawfully turn a prohibited source of funds into an acceptable gambling payment.
Which route is better depends on the failure you need to solve
An operator considering open banking can test it against concrete operating questions:
How many customers can reach a supported bank and complete authentication?
Does the payment status reconcile cleanly with the player ledger?
What happens when the bank approves but the cashier callback fails?
Can support identify which party owns a pending payment?
How are refunds, withdrawals, limits and gambling blocks handled?
What protections and complaint paths are explained before payment?
Debit-card teams should ask the same class of questions about decline codes, stored credentials, issuer challenges, refunds and payout capability. A familiar logo does not remove the need for observable states.
The Financial Conduct Authority supervises payment institutions and electronic-money institutions under the UK payment-services framework. Its overview of the Payment Services Regulations is the starting point for understanding the regulated actors, but a live implementation also depends on contracts, scheme rules and the exact permissions of each provider.
Open banking can shorten the path between a bank account and the operator, improve payment references and avoid card credentials in the merchant flow. Debit cards offer a deeply established acceptance and dispute ecosystem. The better route is the one whose identity, control and failure states the cashier can actually explain—not the one with the newest button.
