> For the complete documentation index, see [llms.txt](https://developers.bead.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.bead.xyz/reference-guide/payment-flows/choosing-tender-types-by-payment-environment.md). # Choosing Tender Types by Payment Environment Tender types should be selected based on the payment experience, fulfillment timing, and the amount of customer or staff patience available in the flow. Some tenders are appropriate for fast, real-time checkout. Others are better suited to invoices, high-ticket purchases, ecommerce orders, or payment flows where fulfillment naturally happens later. This guide helps integrators decide which tender types to enable for a merchant, location, terminal, or payment flow. ### Overview Not every tender type is a good fit for every payment environment. When deciding which tenders to enable, consider: * whether the customer is physically present * whether goods or services are delivered immediately * whether the merchant can wait before releasing goods * whether staff can explain a pending payment state * whether the payment amount is high enough to justify extra operational handling * whether the customer can leave the payment screen before final completion * whether the integration can track final payment status asynchronously In general: | Environment | Best tender behavior | | ------------------------------- | ----------------------------------------------------------------------------------- | | Fast in-person checkout | Real-time or near-real-time completion | | High-touch physical commerce | Near-real-time tenders, plus selected slower tenders when staff can manage the wait | | Ecommerce with later shipment | Real-time tenders and asynchronous tenders | | Invoices and service payments | Real-time tenders and asynchronous tenders | | Instant digital delivery | Real-time or near-real-time completion only | | High-ticket delayed fulfillment | Broader tender support, including BTC (on-chain) when appropriate | ### Tender timing categories For integration planning, tender types can be grouped by expected customer experience. #### Real-time or near-real-time tenders These tenders are generally appropriate when the customer is expected to wait in the payment flow until the final result is available. Examples may include: * Bitcoin Lightning * USDC network tenders * supported wallet app tenders * other tenders that normally complete in a short customer-facing window These tenders are usually appropriate for: * retail checkout * service counters * pickup counters * digital checkout * invoices * ecommerce * payment links #### Longer-running tenders BTC (on-chain), meaning Bitcoin on-chain, should be treated as a longer-running tender. BTC (on-chain) can be appropriate when the merchant does not need to release goods or services immediately. It is less appropriate when the customer is standing at a counter waiting for immediate delivery. When BTC (on-chain) enters `processing`, the transaction has been detected and is underway, but it should not be treated as final until the payment reaches `completed`. ### Physical payment environments Physical environments require special care because the customer, merchant staff, and goods are often all present at the same time. #### Fast in-person checkout Examples: * quick-service retail * convenience checkout * event concessions * low-ticket service counters * busy lines Recommended tender approach: | Tender type | Recommendation | | ---------------------- | -------------------------------------- | | Near-real-time tenders | Recommended | | BTC (on-chain) | Usually not recommended | | Asynchronous tenders | Avoid unless staff has a clear process | Fast checkout environments usually should not enable BTC (on-chain) by default. The customer experience can become confusing if the transaction remains in `processing` while the customer is waiting for goods. In this environment, the best tenders are the ones that complete quickly enough for the customer and staff to stay in the same flow. #### High-touch physical commerce Examples: * jewelry stores * luxury retail * high-end electronics * collectibles * art sales * large-ticket specialty retail Recommended tender approach: | Tender type | Recommendation | | ---------------------- | ------------------------------- | | Near-real-time tenders | Recommended | | BTC (on-chain) | Appropriate in selected cases | | Asynchronous tenders | Appropriate with staff training | BTC (on-chain) can be reasonable in high-touch environments when the purchase amount is high enough and the merchant can explain the payment process. For example, a jewelry store may be comfortable allowing a customer to initiate a BTC (on-chain) payment while staff continues the sales process. The merchant should still wait for `completed` before releasing the goods. Use BTC (on-chain) here only when: * staff understands the payment state * the customer can wait or leave and return * the merchant has a policy for pending payments * goods are not released until payment completion #### Vehicle sales and deposits Examples: * vehicle deposits * motorcycle or boat deposits * down payments * reservation fees * dealership invoices Recommended tender approach: | Tender type | Recommendation | | ---------------------- | ------------------------------------------------ | | Near-real-time tenders | Recommended | | BTC (on-chain) | Good fit for deposits and delayed next steps | | Asynchronous tenders | Good fit when operational workflow supports them | BTC (on-chain) can work well for deposits or payments that do not require immediate vehicle release. For example, a customer may place a deposit using BTC (on-chain), and the merchant can wait for the payment to complete before finalizing paperwork, holding inventory, or releasing the vehicle. BTC (on-chain) is less appropriate when the payment is required immediately before the customer drives away with the vehicle. #### Service businesses with pickup later Examples: * auto repair invoices * equipment repair * custom fabrication * dry cleaning or tailoring * repair shops Recommended tender approach: | Tender type | Recommendation | | ---------------------- | -------------------------------- | | Near-real-time tenders | Recommended | | BTC (on-chain) | Good fit when paid before pickup | | Asynchronous tenders | Good fit | BTC (on-chain) is often a good fit when the customer pays before arriving. For example, a customer may pay a car repair invoice from home. The BTC (on-chain) payment can enter `processing`, and by the time the customer arrives to pick up the vehicle, the merchant may have received final confirmation. In these flows, the customer does not need to remain on the payment screen until final completion. The integration should confirm that the transaction is underway and then notify the merchant or customer when payment reaches `completed`. ### Digital and online payment environments Digital environments can support more tender types because the customer often does not need to receive goods or services immediately. The key question is whether fulfillment happens now or later. #### Ecommerce with later shipment Examples: * physical goods shipped later * online retail * specialty goods * marketplace orders * custom orders Recommended tender approach: | Tender type | Recommendation | | ---------------------- | -------------- | | Near-real-time tenders | Recommended | | BTC (on-chain) | Good fit | | Asynchronous tenders | Good fit | BTC (on-chain) can work well for ecommerce when the order does not ship immediately. The recommended flow is: 1. Customer chooses BTC (on-chain). 2. Customer sends the payment. 3. Payment moves to `processing`. 4. Customer is shown that the transaction has been detected. 5. Customer can leave the payment screen. 6. Merchant waits for `completed`. 7. Order is released for fulfillment after completion. The customer should not be forced to stare at the payment page until the final status is reached. Instead, the integration should show an order confirmation or pending payment screen and rely on webhooks or status checks for the final result. #### Digital goods and instant access Examples: * downloadable files * white papers * software license keys * online courses with immediate access * account upgrades * gated content * API credit purchases Recommended tender approach: | Tender type | Recommendation | | ---------------------- | ---------------------------------- | | Near-real-time tenders | Recommended | | BTC (on-chain) | Usually not recommended | | Asynchronous tenders | Avoid unless access can be delayed | BTC (on-chain) is usually a poor fit for instant digital delivery. The merchant should not grant access when the payment is only `processing`. If the customer expects immediate access, a long-running tender creates a poor experience and may increase support volume. BTC (on-chain) may still be used if the integration clearly communicates that access will be granted only after payment completion. However, if immediate access is the core experience, faster tender types are usually a better fit. #### Subscription or account-based services Examples: * account renewals * SaaS subscriptions * membership fees * service credits * account top-ups Recommended tender approach: | Tender type | Recommendation | | ---------------------- | -------------------------------------------------------- | | Near-real-time tenders | Recommended | | BTC (on-chain) | Good fit when access does not need to change immediately | | Asynchronous tenders | Good fit with account-state handling | BTC (on-chain) can work for subscriptions and account payments when the integration can hold the account state as pending until payment completion. For example, a user may renew an annual account. The system can show “payment pending confirmation” and activate the renewal after the payment reaches `completed`. Avoid BTC (on-chain) if the user must receive instant access, instant credits, or immediate quota increases. ### Invoice and payment link environments Invoices are one of the best environments for broader tender support because payment completion does not always need to happen in the same session. #### Business invoices Examples: * B2B invoices * professional services * wholesale payments * milestone payments * retainers Recommended tender approach: | Tender type | Recommendation | | ---------------------- | -------------- | | Near-real-time tenders | Recommended | | BTC (on-chain) | Good fit | | Asynchronous tenders | Good fit | BTC (on-chain) is often appropriate for invoice payments because the merchant can reconcile payment completion asynchronously. The integration should: * show that payment was detected when the status reaches `processing` * keep the invoice in a pending state * mark the invoice as paid only after `completed` * notify the merchant or payer when the payment is complete #### Consumer invoices Examples: * repair invoices * medical or dental invoices * home services * deposits * reservations Recommended tender approach: | Tender type | Recommendation | | ---------------------- | --------------------------------------- | | Near-real-time tenders | Recommended | | BTC (on-chain) | Good fit when service delivery can wait | | Asynchronous tenders | Good fit | BTC (on-chain) can work well for consumer invoice payments when there is a natural gap between payment and fulfillment. For example, a customer can pay from home before arriving to pick up goods or receive services. ### Decision framework Use this decision framework before enabling BTC (on-chain) or another longer-running tender. #### Step 1: Is the customer waiting in person? If yes, be cautious with BTC (on-chain). BTC (on-chain) may still be appropriate if the environment is high-touch, high-ticket, or operationally prepared for a longer wait. #### Step 2: Are goods or services delivered immediately? If yes, use tenders that complete quickly. Do not release goods or grant access while a BTC (on-chain) payment is only `processing`. #### Step 3: Can fulfillment wait? If fulfillment can wait, BTC (on-chain) may be a good fit. Examples include ecommerce shipment, invoice payment, service pickup, deposits, and high-ticket sales where staff can manage the experience. #### Step 4: Can the integration handle asynchronous completion? If using BTC (on-chain), the integration should be able to: * detect `processing` * show customer-facing pending payment messaging * store the payment reference * listen for webhooks or check status * update the merchant order or invoice when the payment reaches `completed` * prevent fulfillment before completion If the integration cannot support asynchronous completion, BTC (on-chain) should not be enabled. ### Recommended tender fit matrix | Payment environment | BTC (on-chain) fit | Recommended handling | | ---------------------------------- | ---------------------: | -------------------------------------------------------------------------------------- | | Fast retail checkout | Poor | Use near-real-time tenders only. | | Busy service counter | Poor | Avoid tenders that may leave the customer waiting. | | Jewelry or luxury retail | Good in selected cases | Staff should explain the payment state and wait for completion before releasing goods. | | Auto dealer deposit | Good | Treat as pending until payment reaches `completed`. | | Auto repair invoice before pickup | Good | Let the customer pay before arrival and confirm completion before release. | | Ecommerce with later shipment | Good | Allow customer to move on after `processing`; ship after `completed`. | | Digital download | Poor | Avoid unless delivery can be delayed. | | Software license for immediate use | Poor | Prefer near-real-time tenders. | | Subscription renewal | Conditional | Use if the account can remain pending until completion. | | B2B invoice | Good | Reconcile asynchronously through webhooks or status checks. | | Reservation or deposit | Good | Confirm final status before guaranteeing fulfillment. | ### Customer messaging guidance When using BTC (on-chain), set expectations clearly. #### When payment is still waiting for funds Use language like: ``` Waiting for BTC payment. Send the exact amount shown to the payment address. This page will update when the transaction is detected. ``` #### When payment reaches `processing` Use language like: ``` Payment detected. Your BTC payment is now processing on the Bitcoin network. This can take several minutes. You do not need to keep this page open. ``` #### When fulfillment is delayed Use language like: ``` Your payment is pending confirmation. The merchant will complete your order once the BTC payment is confirmed. ``` #### When goods cannot be released yet Use language like: ``` The transaction has been detected, but payment is not complete yet. The merchant can release the goods once the payment reaches completed status. ``` ### Merchant operations guidance Merchants using BTC (on-chain) should have an operational process for pending payments. Recommended operational states: | Merchant state | Bead payment status | Meaning | | ------------------------- | ----------------------------------------- | -------------------------------------------------- | | Awaiting payment | `created` or equivalent pre-funding state | Customer has not yet sent funds. | | Payment detected | `processing` | BTC transaction is underway but not final. | | Paid | `completed` | Payment is complete and fulfillment may proceed. | | Payment failed or expired | Failed, expired, or canceled final state | Merchant should not fulfill without a new payment. | For physical environments, staff should know: * what `processing` means * that `processing` is not final approval * whether the customer may leave and return * how the customer will be notified * when goods may be released For digital environments, systems should know: * whether to hold the order * whether to show pending payment status * when to grant access * how to notify the customer * how to retry or recover if payment does not complete ### Integration guidance When building tender selection into a checkout or payment flow: 1. **Filter tenders by environment**\ Do not show every tender everywhere. Match tender options to the merchant’s operational model. 2. **Use terminal or location context**\ A physical terminal may need a different tender set than a virtual terminal for the same merchant. 3. **Use amount context**\ Slower tenders may make more sense for high-ticket payments than low-ticket payments. 4. **Use fulfillment context**\ If fulfillment is delayed, broader tender support is usually reasonable. If fulfillment is immediate, prioritize fast tenders. 5. **Use customer messaging by tender**\ BTC (on-chain) needs different messaging than near-real-time tenders. 6. **Use webhooks or status checks**\ Long-running payment flows should not depend on the customer keeping a browser tab open. 7. **Fulfill only after final status**\ Treat `completed` as the fulfillment trigger. ### BTC (on-chain) guidance BTC (on-chain) is best understood as a longer-running Bitcoin on-chain tender. Use BTC (on-chain) when: * the merchant can wait for payment completion * the customer does not need immediate delivery * the integration can support asynchronous confirmation * the payment amount or merchant preference justifies the additional wait * staff or system messaging can clearly explain the pending state Avoid BTC (on-chain) when: * the customer is waiting in a fast checkout line * the merchant must release goods immediately * the product is a digital good delivered instantly * the system cannot hold fulfillment until payment completion * the customer experience depends on immediate final approval When BTC (on-chain) reaches `processing`, the recommended experience is: 1. tell the customer the payment has been detected 2. explain that Bitcoin on-chain confirmation may take several minutes 3. move the customer to an order, invoice, or status page 4. notify the merchant or customer when the payment reaches `completed` 5. fulfill only after `completed` ### Practical examples #### Example 1: Fast retail checkout A customer is buying a low-ticket item in a busy store. Recommended tender setup: * Enable near-real-time tenders. * Do not enable BTC (on-chain) by default. * Avoid payment methods that require staff to monitor a long pending state. Why: The customer expects to pay and leave. A longer BTC (on-chain) confirmation window may create line delays and staff confusion. #### Example 2: Jewelry store A customer is purchasing a high-value item. Recommended tender setup: * Enable near-real-time tenders. * Consider enabling BTC (on-chain). * Train staff to explain pending confirmation. * Release goods only after `completed`. Why: The ticket size and high-touch service model may justify a longer payment process. #### Example 3: Ecommerce order with shipping A customer buys a physical product online that will ship later. Recommended tender setup: * Enable near-real-time tenders. * Enable BTC (on-chain) if the merchant accepts asynchronous confirmation. * Put the order into pending payment confirmation when BTC (on-chain) is `processing`. * Ship only after `completed`. Why: The customer does not need immediate physical delivery, so the payment can complete before fulfillment. #### Example 4: Digital white paper A customer buys a downloadable report and expects immediate access. Recommended tender setup: * Enable near-real-time tenders. * Avoid BTC (on-chain) unless the download can be delayed. * Grant access only after `completed`. Why: BTC (on-chain) may leave the customer waiting, and access should not be granted while the payment is still `processing`. #### Example 5: Auto repair invoice A customer pays a repair invoice from home before picking up their vehicle. Recommended tender setup: * Enable near-real-time tenders. * Enable BTC (on-chain) if the shop supports pending payment workflows. * Notify the shop when payment reaches `completed`. Why: The transaction can process before the customer arrives, making BTC (on-chain) a reasonable option. ### Recommended default policy Use this as a default tender-selection policy: | Flow type | Default BTC (on-chain) policy | | -------------------------------------- | ----------------------------------------------------------- | | Fast physical checkout | Disabled | | High-ticket physical checkout | Optional | | Luxury or high-touch physical checkout | Optional | | Ecommerce with shipment | Enabled if merchant supports pending orders | | Invoice payments | Enabled | | Service pickup payments | Enabled when paid before pickup | | Instant digital goods | Disabled | | Immediate account access | Disabled unless access can remain pending | | Deposits and reservations | Enabled if final confirmation is required before commitment | ### Summary Tender selection should follow the customer experience and fulfillment model. BTC (on-chain) is not a bad tender type. It is a tender type that requires the right environment. It works best when: * payment confirmation can happen asynchronously * the merchant can wait before fulfillment * the customer does not need to remain on the payment screen * the integration uses webhooks or status checks * the merchant releases goods or services only after `completed` It works poorly when: * the customer expects immediate goods * staff cannot manage a pending state * the product is delivered instantly * the integration cannot hold fulfillment Use fast tenders for fast checkout. Use BTC (on-chain) where delayed confirmation fits the business process. ### Related pages * [Why do BTC (on-chain) payments take longer?](/faqs-and-troubleshooting/payments-faqs/why-do-btc-on-chain-payments-take-longer.md) * [Payment Statuses](/payments/payment-statuses.md) * [Payment Webhooks](/payments/payment-webhooks.md) * [Create Payment](/payments/create-payment.md) * [Crypto Wallet Flow and Amounts](/payments/crypto-wallet-flow-and-amounts.md) * [Crypto Tender Types](/reference-guide/enumerations-and-schemas/tender-types.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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/reference-guide/payment-flows/choosing-tender-types-by-payment-environment.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.