Casino payment method checker

What a payment-method check actually reports

A payment-method check is not a lookup on a company. It is a lookup on a mechanism: the rail a deposit travels, the regulatory chain that rail sits under, and whether that chain permits the rail to be used for the specific purpose of funding a gambling account. Two operators can offer what looks like the same button on a cashier page and be running two entirely different mechanisms behind it, with two different answers to the question this check is built to answer.

That framing matters because a checker that reported on companies instead of rails would be making a claim about conduct rather than about mechanism. A dated, sourced status on a mechanism is something a reader can verify independently against the primary sources cited here. An accusation against a named business is not, and is outside the scope of a tool that explains payment rails rather than policing the operators running on them.

Why the same-looking route can behave two different ways

Two payments can both start on a phone without using the same rail. Carrier billing charges a mobile contract account or deducts the amount from pay-as-you-go credit. Apple Pay and Google Pay instead present a device-specific token for the card loaded into the wallet. The card issuer and card network still authorise that payment, and the transaction appears on the underlying card account rather than on a monthly phone bill.

A checker that only asked whether a phone was used would group those mechanisms together. The useful questions are what account is debited, who authorises the transaction and which regulatory chain applies. Those details separate carrier billing from a tokenised card payment even when the cashier labels are similar.

The chain that actually decides eligibility

UK payment-services regulation sets out, in one schedule, both a definition of what counts as a regulated payment service and a separate list of activities that are deliberately carved out of that definition. A route only needs regulatory permission if it falls on the regulated side of that line; a route that falls inside a carve-out does not need it, and cannot rely on one just because a similar-looking route elsewhere does.

The relevant carve-out here is the Electronic Communications Exclusion, and it is narrower than its name suggests. It covers digital content delivered over a telecoms or IT connection, voice-based services, charity donations, and tickets: a short, subject-matter-specific list, not a general allowance for anything billed through a phone. A gambling deposit is not digital content, not a voice-based service, not a charity donation and not a ticket, so it fails this test on what it actually is before any question of amount or of which firm is involved is even reached.

There is a second layer worth knowing about even though it rarely changes the answer on its own: the exclusion does not stop working the instant it passes through one company. A provider further down the chain from the one that first relies on the exclusion can inherit that standing, but only for as long as the party at the head of the chain continues to satisfy the conditions the exclusion depends on. That conditional inheritance is the mechanism, not a footnote to it, and it is why tracing a route properly means following the whole chain rather than checking a single link and stopping.

Reading a result: a rail's standing, not a verdict on a company

The checker below reports its result the same way every other status on this site is reported: as a lit or unlit state carrying its own text label, never as a colour pair standing in for a verdict. A route that is unlit for the purpose being asked about is not being called illegitimate in general. It is being reported as unsuited to this one specific use, which is a narrower and more useful statement than a blanket judgement would be.

The individual method pages set out, route by route, who handles the money at each step and what limits attach to it; the glossary defines the regulated roles that come up along the way. The lookup below ties those two together into a single question: is this specific route allowed for this specific purpose.

How the six results are derived

Debit card, PayPal, open banking and tokenised phone-wallet payments each reach an institution already providing a payment service. The route differs in every case: a bank authorises a card, an e-money institution moves a wallet balance, a PISP instructs a bank, or a card network maps a phone token back to the card underneath. None needs the electronic communications exclusion to make the transaction a payment service.

A prepaid voucher also rests on an issuer holding an e-money permission, though its purchase and redemption occur at different moments. The code carries stored value to the cashier and cannot receive a withdrawal in reverse. Its route is eligible for the question asked here, but that says nothing about which casino accepts it or which commercial limit that casino applies.

Carrier billing is the outlier. Its regulatory footing begins with an exclusion for a limited group of purchases made through an electronic communications network. The list contains digital content, voice services, charity donations and tickets. A gambling deposit is outside the list, so the route fails before the £40 and £240 conditions or any downstream provider are considered.

What the result leaves for the cashier and the bank to decide

Eligibility is not availability. A route can be permitted for a gambling deposit and still be absent from a particular cashier. Where it is present, the operator can set its own minimum and maximum, while the bank, issuer or wallet can apply another limit or decline. The checker has no basis for predicting those operational decisions and does not turn a rail classification into a promise that a payment will clear.

The funding source can also change the answer inside one visible method. Apple Pay loaded with a debit card uses a permitted card rail; the same interface loaded with a credit card remains caught by licence condition 6.1.2. A PayPal balance funded by a debit card or bank account sits differently from credit-card funding that the prohibition was written to reach through a money service business.

Withdrawals are another separate decision. PayPal and bank-account routes can usually receive a return payment. A voucher code or a mobile-account charge cannot. The checker answers the deposit question in front of it, while the method pages record whether a second route will be needed when money leaves the gambling account.

Why the result describes the route in words

A binary tick or cross would hide the reason for the answer. The result instead names the party handling the money and states whether the route involves an authorised institution or depends on an exclusion that does not reach a gambling deposit. The written explanation remains available when colour, animation or scripting is unavailable.

That phrasing also keeps the conclusion narrow. "Excluded for this deposit" does not mean a telecoms billing service is defective or unlawful. Carrier billing is built for the purchases listed in the exclusion and can work exactly as intended for them. The mismatch is between the route and the subject matter of a gambling deposit.

Named firms need a narrower claim. A register can confirm that a particular legal entity holds a permission on a stated date. It cannot show which hidden chain a cashier used for one player's transaction. The checker therefore stays at rail level and leaves operator status to the dated licence lookup.

Every result can also be followed back to the full six-row list when scripting is unavailable. That matters because the selected view is a convenience, not a separate source of truth. The written rows exist in the initial document, and the control only changes which one remains visible after selection.

Check a payment method

Pick a route below. With scripting on, checking narrows the six routes to the one asked about; without it, all six are already listed, and nothing here is hidden behind a script that has to load first.