Image Source: Created with AI

Bitcoin and Bitcoin Lightning can appear as separate entries in a casino's payment list, even though both refer to payments made with bitcoin. The extra entry identifies a different route for the payment. A cashier needs to distinguish the asset being sent from the network carrying it because the receiving instructions depend on both. The asset name alone does not describe the receiving method.

Bitcoin names the asset in this pairing; Lightning names a payment network built around bitcoin. An on-chain payment uses Bitcoin's blockchain, while a Lightning payment uses payment channels. The distinction is visible in Blockstream's December 2025 app update, which describes scanning a Lightning invoice and confirming payment. The wallet handles a request for a particular route, even when the familiar asset name stays the same.

Why the cashier separates the routes

Bitcoin and Bitcoin Lightning appear separately among the Cafe Casino online casino payment options. Both entries concern payments to the casino service. The distinction concerns how a transfer reaches the casino account: an on-chain transaction and a Lightning payment use different receiving instructions. A cashier brings the sender's wallet and the receiving service together, so its payment choices need to identify the supported route as well as the cryptocurrency. The separate Lightning entry makes that distinction explicit.

Those choices correspond to different receiving instructions. In the casino's address-based deposit flow, its crypto guide describes copying the address from the deposit page and using it in an external wallet. The address supplies a destination for that transfer. Lightning uses its own payment requests, which a wallet handles through the Lightning network. The cashier identifies the supported method at the receiving end; the wallet needs the corresponding information to carry the payment through that method.

Blockchain transfers and payment channels

An on-chain Bitcoin payment is sent as a transaction for recording on the Bitcoin blockchain. The sender's wallet creates the transaction, and the receiving address identifies its destination. The blockchain supplies the shared transaction record for this route. A casino account is part of the receiving service, while the Bitcoin network carries the transaction for recording on the blockchain.

Lightning carries payments through channels, which are payment relationships between network participants. Bitcoin committed to these channels supplies the balances that participants use to make payments. Transfers update balances within those channels, rather than placing every individual payment directly on Bitcoin's blockchain. The channels provide the connections through which bitcoin can move across the network. Receiving a Lightning payment therefore involves infrastructure capable of participating in that channel system.

A documented implementation appears in BTCPay Server's July 2025 release. Its plugin connects users to Lightning service providers that open inbound channels so their nodes can receive payments. A node is software participating in the network; inbound capacity describes the room available to receive bitcoin through its channels. The plugin lets users choose a provider and channel size.

Inbound capacity is directional: it concerns how much bitcoin can reach a node through its channels. That receiving capacity belongs to the Lightning infrastructure. An on-chain receiving address serves a different function, identifying the destination of a blockchain transaction. The two methods therefore require different arrangements on the receiving side, even when both payments involve bitcoin.

What the payment request tells the wallet

The route becomes more concrete when the receiver supplies payment information. An on-chain Bitcoin address identifies a destination for a blockchain transaction. A Lightning invoice is a request for payment through Lightning. Both can be presented as text or encoded in a QR code, but their similar appearance on a screen does not make them the same kind of instruction.

• Payment route | Asset | Typical receiving information
• Bitcoin on-chain | Bitcoin | Bitcoin address
• Bitcoin Lightning | Bitcoin | Lightning invoice

A QR code presents the payment information for scanning. The wallet reads the data it contains, so the request type determines which payment process applies. Text and QR codes are alternative ways to supply that data. Changing how a request is displayed does not change the network it belongs to.

Wallet software can also connect payment layers. In the Blockstream implementation described earlier, the app pays Lightning invoices from a Liquid bitcoin balance. Liquid bitcoin represents bitcoin on the separate Liquid Network. A swap connects that balance to the Lightning payment. In the other direction, incoming Lightning payments add to the app's Liquid bitcoin balance. The wallet handles the connection between these layers while the invoice identifies the Lightning payment.

Image Source: Created with AI

Here, the receiving network differs from the network recording the sender's wallet balance. Both directions use swaps to connect the Lightning and Liquid networks. A cashier's Lightning listing establishes the supported receiving route; the listing alone does not specify the wallet or software that handles the transfer.

One asset, different receiving instructions

The cashier label and the payment request have different jobs. The label identifies a supported receiving method; the address or invoice supplies information for a payment through it. Wallet software then handles the corresponding transfer, either directly through that network or through a connection it supports.

Bitcoin can consequently appear in more than one payment option within the same casino service. The entries share an asset, while specifying different ways to receive it. Keeping the routes separate allows each option to lead to the receiving instructions that its network requires.