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:
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:
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:
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:
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:
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:
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:
Customer chooses BTC (on-chain).
Customer sends the payment.
Payment moves to
processing.Customer is shown that the transaction has been detected.
Customer can leave the payment screen.
Merchant waits for
completed.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:
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:
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:
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
processingkeep the invoice in a pending state
mark the invoice as paid only after
completednotify 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:
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
processingshow 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
completedprevent fulfillment before completion
If the integration cannot support asynchronous completion, BTC (on-chain) should not be enabled.
Recommended tender fit matrix
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:
When payment reaches processing
processingUse language like:
When fulfillment is delayed
Use language like:
When goods cannot be released yet
Use language like:
Merchant operations guidance
Merchants using BTC (on-chain) should have an operational process for pending payments.
Recommended operational states:
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
processingmeansthat
processingis not final approvalwhether 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:
Filter tenders by environment Do not show every tender everywhere. Match tender options to the merchant’s operational model.
Use terminal or location context A physical terminal may need a different tender set than a virtual terminal for the same merchant.
Use amount context Slower tenders may make more sense for high-ticket payments than low-ticket payments.
Use fulfillment context If fulfillment is delayed, broader tender support is usually reasonable. If fulfillment is immediate, prioritize fast tenders.
Use customer messaging by tender BTC (on-chain) needs different messaging than near-real-time tenders.
Use webhooks or status checks Long-running payment flows should not depend on the customer keeping a browser tab open.
Fulfill only after final status Treat
completedas 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:
tell the customer the payment has been detected
explain that Bitcoin on-chain confirmation may take several minutes
move the customer to an order, invoice, or status page
notify the merchant or customer when the payment reaches
completedfulfill 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:
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
Last updated