Channels Overview

A channel is a set of static crypto addresses that stay open indefinitely, ready to accept inbound payments from your customers. Unlike a Payment Link — which is a one-off URL for a single transaction — a channel is the right primitive for ongoing inflows: subscription billing, recurring top-ups, B2B settlement, or any pattern where the same customer or cohort of customers sends crypto to you repeatedly.

How a channel works

Each channel is bound to one Pay Currency — the asset your customer will send (USDT, USDC, and so on). For that pay currency, BEEM provisions a static address on every supported network: a USDT channel comes with addresses on Tron, Solana, Polygon, Ethereum, and any other USDT-supported network simultaneously. The customer picks the network that suits them; whichever they pick, the deposit lands in the same channel.

Funds arriving on any of those addresses are converted to the wallet's currency and credited to the linked wallet. So a USDT channel feeding a EUR wallet accepts USDT on any supported network and the wallet balance increases in EUR.

A channel is tied to exactly one wallet, but a wallet can have many channels feeding into it. The typical setup for a merchant with multiple pay currencies is one channel per asset (USDT, USDC, and so on), all settling into the same wallet. The same pattern works for logically-separated customer cohorts: a channel per cohort, each carrying a distinct Reference, all crediting the same wallet for unified balance and reconciliation.

Three currencies, three roles

A channel involves three currencies, and getting them straight makes the rest of the page much easier to follow.

A worked example: a merchant prices their checkout in EUR. The end customer wants to buy something worth EUR 100. BEEM converts that at the current rate and the merchant displays "send USDT 125" to the customer. The customer sends 125 USDT on the network of their choice. BEEM converts the inbound USDT to EUR and the merchant's EUR wallet is credited with the equivalent EUR 100.

What the customer actually receives

When you share a channel with a customer, what you hand over is the raw crypto address on whichever network the customer will pay on. There is no hosted BEEM payment page, no built-in QR code, no checkout UX — your application is responsible for showing the customer the relevant address (or a network selector if you want to support multiple networks) and any pricing context they need.

This is by design. Channels are intended to be embedded inside the merchant's own product surface. The Channel Payments page (link below) then gives you the full record of every inbound payment with on-chain references for reconciliation.

📘

XRP destination tags

For XRP-based channels, the Tag field on each address is the destination tag the customer must include alongside the address. Without it, the deposit cannot be attributed and will not be credited. Display the tag prominently alongside the address whenever you surface an XRP channel to a customer.

Compliance and holds

Every inbound payment passes through BEEM's compliance screening before it is marked complete. If a payment triggers a screening rule — sanctions, on-chain risk, jurisdictional, threshold-based — it is held for review. The Was On Hold flag on the Channel Payments page indicates whether a given payment was screened and released, or screened and held for further review.

Held payments do not credit the wallet until they clear. They remain visible in the Channel Payments view so your operations team can see them and follow up.

Channels are permanent

Once created, a channel cannot be closed, paused, renamed, or deleted. The status is always OPEN. Confirm the wallet, pay currency, display currency, and reference are correct before clicking Add channel — there is no edit path afterwards.

🚧

Same constraint as wallets

Rename, archive, and close are on the product roadmap. Until they ship, treat channel creation as a one-way operation.

The Reference field

The Reference is an internal-only label your team uses to identify the channel in lists, webhooks, and reconciliation reports. It is never shown to the customer paying on the channel. Use a naming convention that makes the channel obvious to finance and operations: typically the counterparty or business line plus the pay/wallet pair, for example PSP_1, MerchantA_USDT-EUR, or OTC-desk-USDC.

What's next