Four families of payment method, and what each one decides for you

A payment method is a route, not a logo

Every button in a cashier stands for a route. The logo printed on it is a brand; what matters sits underneath, in the instruction that travels, the parties who each have to agree before it moves, and whether the same route exists when you want the balance back. Call that route a rail. Once you can name the rail a button sits on, most of the behaviour people later find baffling stops being baffling.

Two deposits of identical size, made minutes apart, can end very differently because they left by different rails. One is authorised by your card issuer in about the time it takes to read this sentence, and lands on your statement labelled as a gambling merchant. The other is authorised by you, inside your own banking app, and reaches the site as a plain credit with a reference string attached to it. The pounds are the same pounds. The chain of permissions is not, and the chain is what breaks.

This page sorts every rail a British cashier offers into four families, and says for each one what it takes off your hands and what it quietly hands back to you to deal with. The debit card rail is the one the cashier was built around, so it is the reference point everything else is measured against.

The four families and what each one takes on

The families are not a marketing split. They are four genuinely different mechanisms, and a rail belongs to exactly one of them no matter how many logos are stacked on top. Cards pull. Wallets and phone rails pull on your behalf, through a layer. Bank rails push. Prepaid value is loaded first and then spent down, which means nobody collects anything from an account of yours at the moment of the deposit.

Every family trades one problem for another. A card asks nothing of you beyond a number and a confirmation, but it exposes the whole account behind it to a merchant you may not know well. A wallet keeps your card details away from the site, but adds a second set of rules that can refuse the payment for reasons the site never hears about. A bank push cannot be reversed by anyone downstream, which is excellent for control and useless when you have typed the reference wrong. A voucher caps your exposure to the value printed on it, and in exchange usually offers no way home at all.

Push and pull: who asks whom for the money

Pull means the cash desk, or something acting for it, sends a request towards your money and waits to be told yes or no. You are present for that request, you confirm it, and then it leaves your hands. The answer comes from whoever holds the account, and it can be no for reasons that have nothing to do with the amount: a setting in your banking app, a merchant category the issuer will not process, a fraud rule that fired because the device looked new.

Push is the reverse. Nothing is sent towards your money. You open your own bank, you create the payment, your bank authenticates you and then releases funds in one direction. No part of the chain downstream of your bank can ask for those funds again, which is exactly why a push is safe and exactly why a mistyped reference is such a nuisance.

Hold that distinction and the awkward cases sort themselves out. A wallet sits on the pull side even when it feels like you are sending money, because something still has to collect from whatever funds the wallet. Open banking rails sit on the push side even though the payment starts inside the cashier, because the authentication happens in your bank and the money moves outwards only.

Cards: the rail the cashier was built around

Card rails are the default because they are the only ones present in every cashier, and because the whole mechanism of holds, captures and reversals was designed around them. When you enter a card the site does not take money; it asks for an authorisation, and the issuer sets that amount aside. The actual taking is a separate step, often moments later and sometimes not until the end of the day. That gap is the source of most of the confusion about a deposit that has not appeared.

In Great Britain this family is narrower than it looks, because only debit cards are available for gambling. Credit cards were removed from the rail entirely, and the removal was written broadly enough that routing a credit card through a wallet does not get around it.

Where cards genuinely win is the return journey. Because the scheme keeps a reference to the original transaction, a payout can be aimed back at the exact card that funded the account without you re-entering anything. Where they lose is privacy: nothing about a card payment is hidden from the bank that issued it.

Wallets: a layer between you and the site

A wallet is a deliberate extra party. You fund it from something, the site asks the wallet rather than the funding instrument, and the wallet answers. That shape buys you two useful things. The site never learns your card number, so a cashier you are sampling for the first time cannot keep it. And the wallet can have its own policy, applied before any request reaches your bank.

That second thing cuts both ways, which is the honest objection to the whole family. A wallet with its own gambling policy may simply decline to process for a merchant it has not approved, and the cashier will often show you a flat failure with no explanation, because none was given to it. You then have three parties to ask instead of one.

Device wallets behave slightly differently again. Apple Pay and Google Pay are not really holding balances; they are presenting a substitute number for a card you have already added, with the confirmation done by your face or your fingerprint instead of a code. The rail underneath is still a card pull, so every card rule still applies, including the British one about credit.

Phone rails: your network as the ledger

Phone rails are the odd family, and in Britain they are common enough to deserve their own treatment. The deposit is not taken from a bank at all. It is added to a mobile account, which then collects it from you later on a bill or takes it immediately out of prepaid credit. The authentication is a code sent to the number, or nothing more than being on the network when the request is made.

Because the money has not touched your bank, this is the one family where a deposit can happen without any card, account or app being involved. That is the appeal, and it is also the warning. Depositing from a phone removes every friction a bank would have added, including the gambling controls you may have set there on purpose.

The mechanics split by billing type. Billing to a monthly contract defers the money, so spending and paying are separated in time. Prepaid credit does not defer anything. The intermediary that sits between networks and sites is what makes either version work, and it is the party that sets the per-payment ceiling you will run into long before the site's own limits matter.

Bank rails: your own app does the paying

Bank rails move the act of authorising out of the cashier and into software you already trust. In the classic form you copy details out of the cashier, make a payment in your bank, and the site matches the arrival to your account using the reference. In the modern form the cashier hands you to your bank, your bank shows you the amount and the recipient, you confirm, and the payment is created with the reference already correct.

Both are pushes, so both are one-way. A manual transfer is the slowest rail at the front door, because a human process is sometimes involved in matching references, and one of the most predictable at the back, because a bank credit either arrives or does not. The open banking version removes the typing and most of the waiting without changing the direction of travel.

Challenger banks blur this family with the card one, since they issue cards as well as hold accounts. An account that is also an app can fund a card pull, a push, and a wallet top-up on the same day, and only one of those routes is governed by the switches in its own settings.

Prepaid value: money with nobody attached to it

The fourth family breaks the pattern because there is no account to collect from. You buy value, you present a code, and the cashier takes from the code until it is empty. Nothing is pulled, nothing is pushed, and no instrument of yours is registered with the site beyond a string of digits.

This is the most contained rail there is. The exposure cannot exceed what you loaded, there is no instrument to be stored and reused, and no statement line names the merchant. A voucher bought in a shop achieves in one step what people otherwise try to achieve with virtual cards and separate accounts.

It also has the harshest asymmetry in the whole set, and it is better to meet that fact here than at the cashier. A code is a one-direction instrument. There is no account behind it for a payout to be aimed at, so winning on this rail means being handed a different one on the way out, and the different one will need to be verified from scratch.

Why the money comes back the way it went out

The rule that surprises people most is the simplest to justify. Payouts are returned, wherever possible, along the route the deposit took. This is not an operator being awkward. It is the one arrangement under which the money provably goes back to the person it came from, which is precisely what a licensed site has to be able to demonstrate.

Consider the alternative. If a deposit arrived by card and a payout left by bank transfer to a different name, the site would have moved value between two instruments on a customer's word alone. Closing the loop removes that possibility, and it removes it cheaply, because the original transaction reference already exists on the rail.

The practical consequence is that your deposit decision is also your payout decision, made before you have any reason to think about payouts. If you intend to be paid into an account, fund from that account.

Rails with no return channel at all

Some rails simply do not have an opposite direction, and no amount of asking creates one. A shop-bought voucher has no account behind it. A charge added to a phone bill cannot be un-added by the site, because the site never had a relationship with your network; the network does, and it has no mechanism for receiving winnings on your behalf. A device wallet that proxies a card can usually route a refund to the card underneath, but it is the card that receives it, not the wallet.

When a rail is one-way, the site has to pay you by a second rail, and that second rail is where the identity work lands. You will be asked for an account in your own name, and the documents that prove it, and none of that can be skipped on the grounds that the deposit needed none of it.

The fix is to decide the exit before the entrance. Pick a one-way rail deliberately, as a spending cap, knowing that a payout will mean a fresh set of details. Do not pick one by accident because it was the fastest button on the screen, and then meet the problem with a balance already sitting there.

What the site decides and what your bank decides

Two different organisations can refuse the same payment, and they almost never explain themselves in the same words. The cash desk decides which rails it offers at all, what the floor is on each of them, whether a bonus is available on that rail, and whether your account is in a state to transact. Those are commercial and compliance decisions, and the site can tell you about them.

Your bank decides whether the request that reaches it is allowed. That covers available balance, the merchant category, any gambling setting you hold, the strength of the authentication, and whatever its fraud rules make of the attempt. The site is not told which of those applied; it receives a refusal and shows you a generic message.

So the useful question is never a broad is it working. It is which party said no. If the cashier never reached the stage of asking your bank, the floor on that rail or its availability is the problem. If your bank answered, nothing the site does will change the answer until the setting that caused it is changed.

Identity checks follow the rail you chose

Checks are not a single gate placed at the end. They are spread across the journey, and the rail you picked determines where they fall. A card pull from an account in your own name carries a name, so part of the work is already done. A voucher carries nothing, so all of it is still waiting. A bank push carries a verified name from your bank, which is the strongest evidence of the set and the reason this rail is often the smoothest at payout time.

Nothing about this is optional for a licensed site, and in practice the check has been arriving earlier and earlier, often before a first deposit rather than at a first withdrawal. What the documents are for is worth reading once in advance, rather than at the moment a balance is frozen behind them.

Where people trip is the mismatch. The name on the payment instrument, the name on the account and the name on the document all have to be the same person. A joint account, a partner's card or a phone registered to someone else each break that chain, and the break is found at the exit rather than the entrance.

Questions worth answering before you fund anything

None of the four families is the right answer in general. The right answer depends on what you want the rail to take off your hands, and the decision takes about two minutes if you ask in the right order. Payout route first, because it is the one you cannot change later. Then the controls you want to keep in play. Then speed, which matters least and is advertised most.

If you have a gambling block switched on at your bank, the honest answer is that you decided this already, and the rails that bypass the block are the rails to avoid. The block is a tool you gave yourself, and the one thing worth knowing now is that it covers the rails that pass through your bank and nothing else.

Everything else is detail that belongs on the individual rail pages. Each one is written from the same angle as this hub: who asks whom, where it stalls, and what happens when you want the money back. A bank with the switch built into the app is a good place to see all three of those in one place.