Managing Tender Types

Bead supports multiple tender types, including digital wallets, crypto rails, and alternative payment methods. Tender types are managed across multiple levels of the platform, with inheritance and overrides designed to balance commercial configuration with terminal-level flexibility.

This page explains how tender types are configured, inherited, and customized during partner onboarding and terminal setup.

How Tender Types Are Determined

Tender types are determined across three layers.

Level	Purpose
Partner	Defines which tender types are commercially available
Merchant	Inherits available tender types from the partner
Terminal	Enables or disables specific tender types per terminal

Most integrators will interact primarily with the terminal layer, but it is important to understand how configuration flows down from the partner level.

Partner-Level Configuration

At the partner level, Bead enables a set of supported tender types based on commercial agreements, rates and fees provided during partner onboarding, and supported payment rails for that partner.

This configuration is managed by Bead and determines the universe of tender types that merchants and terminals can access. Partners do not need to explicitly configure tender types at this level via API.

Merchant-Level Inheritance

When a merchant completes an application, they automatically inherit all tender types enabled for their partner.

This ensures merchant pricing aligns with approved tender types, unsupported tender types cannot be accidentally enabled downstream, and merchant setup remains simple and consistent.

Merchant-level tender types are not typically modified directly.

Terminal-Level Configuration

The terminal is where tender types are most commonly customized.

Using the add terminal or edit terminal endpoints, you can enable non-default tender types, disable tender types for specific terminals, and tailor payment methods based on device, channel, or use case.

This allows a single merchant to support different payment experiences across terminals.

Example Use Cases

Enable Bitcoin Lightning for in-store terminals only. Bitcoin Lightning can be enabled on in-store terminals while remaining disabled for online or mobile terminals.

Enable Klarna for eCommerce terminals. Klarna can be enabled only on terminals used for online checkout.

Disable non-required tender types. If a terminal should support a narrow set of payment methods, unsupported tender types can be excluded.

API Interaction

Tender types are managed as part of terminal creation and terminal updates.

Relevant endpoints include add terminal and edit terminal.

For full request and response examples, refer to the Terminal Management documentation. https://developers.bead.xyz/entity-management/terminal-management

Common Questions

Do I need to set tender types during merchant onboarding? No. Merchant onboarding inherits tender types automatically from the partner configuration.

Can merchants have different tender types across terminals? Yes. Tender types can be customized per terminal.

Will unsupported tender types appear in the API payload? Unsupported tender types will not be available for activation if they are not enabled at the partner level.

What happens if new tender types are added later? New tender types enabled at the partner level become available for future terminal configurations.

Recommended Integration Pattern

Complete partner onboarding and tender enablement. Onboard merchants normally. Configure tender types explicitly during terminal creation. Adjust tender types using edit terminal as needed.