How BEEM works
The objects you'll work with on BEEM and how they fit together.
BEEM is structured around five core objects. Together, they define how a merchant receives, holds, and sends crypto.
A collection point for funds, denominated in a single currency (fiat or crypto). BEEM handles network and conversion automatically.
Static crypto addresses for a specific currency, valid across all supported networks. Share them with customers as part of the Crypto Payments offering to accept ongoing inbound crypto.
Single-use URLs for crypto deposits or withdrawals. Each link is created with a fixed amount, currency, and network.
Saved withdrawal destinations for individuals or entities. Reference a contact when sending funds out, instead of entering destination details each time.
Sign-off rules that gate withdrawals. Set policies separately for UI and API initiations, with optional amount-tiered approver requirements.
How they fit together
A merchant's funds live in Wallets, each denominated in a single currency.
Crypto moves into wallets through:
- Channels — ongoing inbound transfers from customers, sent to a static address scoped to a single currency across any supported network.
- Payment Links — one-off inbound transfers using a single-use URL with a fixed amount, currency, and network.
Crypto moves out of wallets through Payment Links only. When creating an outbound Payment Link, the destination address can be:
- selected from a saved Contact (a previously verified individual or entity),
- entered manually as a one-time address, or
- left blank, with the hosted Payment Link URL sent to the recipient to populate.
Approvals sit above outbound flows. Configure withdrawal policies separately for the UI and the API to enforce dual control or amount-tiered sign-off before any withdrawal executes.
Wallets
A wallet is a collection point for funds. Each wallet is denominated in a single currency — either fiat (e.g. EUR, USD) or crypto (e.g. USDC, USDT). The wallet's currency is the currency funds settle in.
Wallets are network-agnostic. A wallet can receive and send any supported cryptocurrency on any supported network; BEEM handles the routing and conversion. If the incoming or outgoing asset differs from the wallet's currency, the conversion happens automatically at the time of the transaction.
Every Payment Link and every Channel deposit address is linked to a specific wallet. That link determines where funds collect and which currency they settle in.
Channels
A channel is a static crypto deposit endpoint, scoped to a single currency (for example, USDT). Channels form part of BEEM's Crypto Payments offering — they are how merchants accept inbound crypto from their customers.
When a channel is created, BEEM supplies the network-specific addresses for that currency automatically. A USDT channel, for example, exposes addresses across every network where USDT is supported, so a customer can send on whichever network they prefer.
Each channel is linked to a wallet. Funds received via any of the channel's network addresses land in that wallet. If the wallet's currency differs from the channel's currency, BEEM converts the deposit automatically.
Channels remain open at all times. Use them when a customer needs a stable, reusable destination to send crypto to over time.
Payment Links
A payment link is a single-use URL for moving a specific amount of crypto into or out of a wallet. Each link is created with three required fields:
- Amount — the value to transfer.
- Currency — the crypto asset (for example, USDT or USDC).
- Network — the blockchain network the transaction settles on.
Once defined, a payment link is used in one of two ways:
- Deposit — BEEM generates a one-time address for the link. The counterparty sends the specified amount to that address, and funds land in the linked wallet.
- Withdrawal — the recipient opens the link and provides the wallet address where they want to receive funds. BEEM sends the specified amount from the linked wallet to that address.
Use payment links for one-off transactions where the counterparty doesn't need an ongoing destination.
Choosing between Channels and Payment Links
Both Channels and Payment Links accept crypto deposits, but they serve different patterns.
| Channel | Payment Link | |
|---|---|---|
| Lifespan | Persistent | Single-use |
| Direction | Deposit only | Deposit or withdrawal |
| Currency | Scoped to a single currency; all supported networks available | Specific currency and specific network defined per link |
| Amount | Open-ended | Fixed amount per link |
| Address | Stable, reusable | Generated per link (deposit) or supplied by the recipient (withdrawal) |
| Typical use | Customer repeatedly sends to the same destination | One-off transaction shared as a URL |
If you're not sure which to use, please ask your Customer Relationship Manager
Contacts
Contacts are pre-saved withdrawal destinations. A contact stores the details required to send funds out — such as a crypto address — so the same destination can be reused across transactions without being re-entered.
Each contact is either an individual or an entity, with the relevant identifying information attached. When you initiate a withdrawal, reference an existing contact rather than supplying destination details inline.
Approvals
Approvals are sign-off rules that gate withdrawals before they execute. Configure approval policies separately for withdrawals initiated through the BEEM UI and through the API.
For each surface, choose one of three policies:
- Don't require approval — withdrawals execute immediately.
- Require approval for all transactions — every withdrawal needs sign-off, regardless of amount.
- Require approval for transaction ranges — define amount tiers, each with its own number of required approvers. For example, withdrawals up to USD 20 might require zero approvers, while anything above might require one or more.
Approval conditions apply to all wallets and are evaluated in your account's base currency. Each withdrawal that requires sign-off moves through one of four states: Pending, Approved, Rejected, or Expired.

