# Managing Tender Types Bead supports multiple tender types, including crypto rails, digital wallets, and alternative payment methods. A terminal’s `tenderTypes` show which approved payment methods are available for use on that terminal. Tender enablement is established upstream through onboarding, pricing, approval, and provider enrollment. Entity Management then reflects that approved tender set through the merchant, location, and terminal records. Use this page to understand how tender types flow into terminal configuration, how to verify what is currently active on a terminal, and when a tender change requires onboarding or operational support rather than a terminal-only update. ### Tender enablement vs. terminal configuration Tender enablement and terminal configuration are related, but they are not the same thing. Tender enablement is the process of approving a merchant to accept a payment method. This is driven by the merchant application, commercial terms, pricing, provider requirements, and approval status. Terminal configuration controls how the already-approved tender set is reflected or narrowed for a specific terminal, channel, or payment experience. A terminal should not be treated as the primary place to enroll a merchant into a new tender type. If a tender type was not part of the merchant’s approved application, pricing, and provider setup, adding it at the terminal level may trigger additional enrollment flows, provider requirements, or operational review. In production, those changes are normally coordinated through the ISO, boarding integrator, or Bead support team. ### How tender types are determined Tender availability flows through several layers. | Layer | Purpose | | ----------------------- | ------------------------------------------------------------------------------------------------------- | | Onboarding and approval | Captures the merchant’s requested services, pricing, supporting information, and approval requirements. | | Partner configuration | Defines the tender types commercially available for a partner program. | | Merchant configuration | Represents the tender types the merchant is approved to accept. | | Location configuration | Reflects the tender types available for a merchant location. | | Terminal configuration | Reflects or narrows the approved tender set for a specific terminal or payment experience. | Most payment integrators interact with terminal and payment APIs, but the tender types available there depend on the merchant’s upstream approval and configuration. ### How tender types get set Tender type enablement is primarily an onboarding function. A typical flow works like this: 1. A merchant application is submitted with the services, fees, and pricing information for the tender types the merchant is intended to accept. 2. The application is reviewed and approved. 3. Required provider enrollment or activation is completed for the applicable tender types. 4. Entity Management creates or updates the merchant, location, and terminal records with the approved tender set. 5. The terminal reflects the tender types that are active for that merchant and location. This means the terminal record is an important source of truth for what is currently available, but it is not the source of approval for new tenders. ### Verifying tender types on a terminal To see which tender types are currently active on a terminal, retrieve the terminal: `GET /Terminals/{terminalId}` The response includes a `tenderTypes` array showing the tender types available for that terminal. Use this endpoint when validating a payment integration, troubleshooting why a tender is not appearing, or confirming which payment methods can be offered for a specific terminal. If a tender type is missing from the terminal response, do not assume it can be added as a simple terminal edit. First confirm whether the merchant, location, and provider setup are approved for that tender type. ### Partner-level configuration At the partner level, Bead enables the tender types that are commercially available for the partner program. This configuration is based on commercial agreements, supported payment rails, provider availability, rates, fees, and other onboarding requirements. Partners do not normally configure tender types directly through terminal APIs. The partner configuration defines the universe of tender types that can become available to merchants and terminals downstream. ### Merchant-level configuration At the merchant level, tender types reflect what the merchant is approved to accept. When a merchant completes onboarding and approval, the merchant record is configured with the appropriate tender types based on the application, pricing, and provider setup. Merchant-level tender types are not typically changed ad hoc. Adding a new tender type may require updated pricing, provider enrollment, additional review, or a merchant update process. ### Location-level configuration Locations can reflect the tender types available for a specific merchant location. In most cases, a location follows the merchant’s approved tender configuration. Where supported, location configuration can help represent differences between business locations, sales channels, or operational setups. A location cannot make an unavailable tender type available if the merchant has not been approved and configured for that tender type. ### Terminal-level configuration A terminal represents a specific payment endpoint or payment experience. Terminal `tenderTypes` can be used to reflect or narrow the approved tender set for that terminal. For example, a merchant may have multiple terminals for different use cases, such as in-store checkout, eCommerce checkout, mobile checkout, or a specific hosted payment flow. Terminal configuration can be used to: * Verify which tender types are active on a terminal. * Limit a terminal to a subset of approved tender types. * Create different payment experiences across terminals. * Exclude tender types that are not relevant for a specific channel or use case. Terminal configuration should not be used to enroll a merchant into a tender type that was not approved through onboarding, pricing, and provider setup. ### Example use cases #### Support a narrower in-store payment experience A merchant may be approved for several tender types, but an in-store terminal may only need to support a subset of those methods. The terminal can be configured to reflect only the tender types relevant to that in-store flow. #### Support a different eCommerce payment experience A merchant may use a separate terminal for online checkout. That terminal can reflect tender types appropriate for the eCommerce flow, as long as those tender types are already approved for the merchant and location. #### Verify a terminal before creating payments Before creating payments against a terminal, retrieve the terminal and review the `tenderTypes` array. This confirms which tender types are active for that terminal. #### Add a newly approved tender later If a merchant is later approved for an additional tender type, Bead or the boarding integrator may need to complete the required approval, provider, and configuration steps before the tender can be used on terminals. ### API interaction Tender types appear in terminal creation, terminal updates, and terminal retrieval. Relevant endpoints include: * `GET /Terminals/{terminalId}` * `POST /Terminals` * `PUT /Terminals/{terminalId}` Use `GET /Terminals/{terminalId}` to verify the tender types currently active on a terminal. When creating or updating a terminal, any provided `tenderTypes` should be understood as operating within the merchant and location’s approved tender set. If `tenderTypes` are omitted during terminal creation, Bead applies the default or inherited tender configuration for the location. For full request and response examples, refer to the Terminal Management documentation. ### Relationship to payment requests Payment requests may also include tender type selection depending on the payment flow. Passing `tenderTypes` on a payment request does not enable a new tender type for the merchant or terminal. It only narrows or directs the payment experience to tender types that are already available for the merchant, location, and terminal. If `tenderTypes` are omitted from the payment request, Bead can use the available tender configuration for the terminal and hosted payment experience. ### Common questions #### How do I verify which tender types are active on a terminal? Use `GET /Terminals/{terminalId}`. The response includes a `tenderTypes` array showing the tender types currently available on that terminal. #### Do I need to set tender types during merchant onboarding? Tender type approval is handled through the merchant onboarding, pricing, and provider setup process. Integrators should make sure the merchant application and commercial setup reflect the tender types the merchant is expected to accept. #### Can merchants have different tender types across terminals? Yes. Terminals can reflect different subsets of the merchant’s approved tender types. For example, one terminal may support a narrower in-store payment experience while another supports an online checkout flow. #### Can I enable a new tender type by editing a terminal? Not by terminal configuration alone. If the merchant is not already approved and configured for that tender type, additional onboarding, pricing, provider enrollment, or operational support may be required. #### What happens if a tender type is missing from the terminal response? Treat the tender type as unavailable for that terminal. Confirm whether the merchant and location are approved for that tender type before attempting to update the terminal. #### What happens if new tender types are added later? After the required approval and configuration steps are complete, newly approved tender types can be reflected in merchant, location, and terminal configuration. ### Recommended integration pattern 1. Complete merchant onboarding and tender approval. 2. Confirm the merchant, location, and terminal records have been created. 3. Use `GET /Terminals/{terminalId}` to verify active tender types. 4. Create or update terminals only within the approved tender set. 5. Use payment-level `tenderTypes` only to narrow or direct the payment experience. 6. If a tender type is missing, coordinate through the ISO, boarding integrator, or Bead support team before treating it as a terminal-only configuration change. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://developers.bead.xyz/entity-management/terminal-management/managing-tender-types.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.