Settlement defines what the merchant actually receives after a payment is accepted

A customer payment and a merchant settlement are related, but they are not the same event. The customer chooses an asset and network at checkout. The merchant then needs funds in a usable form, at a known location, under a known timing policy.

A settlement model answers four operational questions. Which asset will the merchant hold? Will funds remain inside a payment account or move to an external wallet? When will the movement occur? Which fees, rates, and transfer records determine the net amount?

The answer may be simple. A Bitcoin payment can settle as Bitcoin into an internal merchant balance. It may also be converted into USDT and later withdrawn in a daily batch. Both flows begin with one payment, but they create different treasury, liquidity, fee, and accounting outcomes.

Payment acceptance, blockchain finality, and settlement must remain separate concepts

Payment systems often use the word “settled” too loosely. A transaction may be visible on a blockchain and later confirmed by the network. It may then be accepted, credited internally, or transferred to an external wallet. These are different milestones.

En BIS payments glossary treats settlement risk as the risk that settlement does not occur as expected. In blockchain payments, that risk can appear after acceptance when conversion, internal crediting, withdrawal, or destination transfer fails.

Legal settlement finality is also distinct from protocol finality. The BIS report on distributed ledger technology explains legal finality as the point where a transfer becomes irrevocable and unconditional under the applicable framework. A merchant settlement policy still needs to define the operational moment when funds become usable.

Every settlement design has three independent dimensions

Settlement models are easier to understand when they are separated into three dimensions. The first dimension is asset transformation. The second is the location of funds. The third is timing. These choices can be combined instead of treated as competing products.

A merchant can therefore receive same-asset internal settlement, converted internal settlement, same-asset external settlement, or converted scheduled settlement. The model name should describe all relevant dimensions.

Same-asset settlement preserves the asset paid by the customer

In a same-asset model, the merchant receives the same asset that satisfied the payment request. A customer pays BTC and the merchant receives BTC. A customer pays USDT on an accepted network and the merchant receives USDT.

This model avoids a conversion step. It also preserves the merchant’s exposure to the original asset. The financial result depends on the asset price after acceptance, the destination network, and any later decision to convert or withdraw.

Same-asset does not mean same-network flexibility. A token received on one network cannot be treated as identical operational liquidity on another. Network-specific balances, withdrawal fees, address rules, and treasury destinations still matter.

Converted settlement separates the customer’s payment choice from the merchant’s treasury asset

Converted settlement changes the received asset into a defined target asset. The customer may pay BTC, ETH, or another supported asset while the merchant receives a stablecoin or another preferred cryptocurrency. In broader industry models, conversion may also end in fiat.

The conversion can happen at payment acceptance, after a balance threshold, or later through a manual treasury action. These moments create different price and liquidity exposure. A rate locked near acceptance reduces open volatility, but requires available liquidity and clear conversion pricing.

Stablecoin settlement can improve unit-of-account consistency, but it does not remove every risk. The business must still consider issuer exposure, redemption access, supported networks, liquidity, and depegging risk. For example, the Circle Mint documentation shows that stablecoin-to-fiat redemption is a separate operational process with account and banking requirements.

Internal settlement credits a merchant balance without creating an external transfer for every payment

Internal settlement records funds inside the payment platform’s account system. The accepted payment increases the merchant’s available balance, but no separate blockchain withdrawal is required at that moment.

This model reduces the number of external transactions. It can also make small payments more economical, because several accepted payments can accumulate before one withdrawal. Internal balances support later conversion, payouts, refunds, or treasury allocation without moving funds for each order.

The trade-off is operational dependence on the platform balance. The merchant needs accurate balance visibility, access controls, withdrawal policies, and a clear understanding of when an internal credit becomes available. Internal settlement also requires strong ledger controls because the platform record becomes the immediate source of operational truth.

De OxaPay Account Balance API provides programmatic balance visibility. That balance can support treasury decisions before an external transfer is initiated.

External settlement transfers funds to a merchant-controlled wallet or another approved destination

External settlement moves funds out of the payment account. The destination may be a self-custody wallet, an institutional custodian, an exchange account, or another approved treasury address.

This model increases direct control over assets, but it introduces an additional transaction lifecycle. The payout must be created, checked, broadcast, confirmed, and reconciled. Address validation, asset-network compatibility, network fees, and withdrawal status become settlement controls.

OxaPay exposes separate endpoints for generating payouts, retrieving payout information, and reviewing payout history. The payout status table helps merchant systems map transfer progress into operational states.

Scheduled settlement controls when accumulated funds move

Scheduled settlement delays an external transfer until a defined time or condition. Common policies include daily settlement, weekly settlement, minimum-balance thresholds, maximum-balance sweeps, or manual treasury approval.

Scheduling can reduce transaction count and network costs. It also improves treasury predictability. However, it increases the amount held inside the settlement account and delays external availability. The policy must therefore balance liquidity, custody exposure, fees, and operational workload.

Scheduled payout models are common across payment infrastructure. Stripe’s payout schedule documentation illustrates the general pattern: funds accumulate in a balance and move according to a separate timing rule. Crypto systems add network fees, asset routes, and blockchain confirmation to that pattern.

Most production systems use a hybrid settlement model

Settlement choices are rarely all-or-nothing. A merchant may keep stablecoins internally for working liquidity, withdraw Bitcoin to long-term custody, and convert volatile assets before a daily external payout.

The settlement policy should be explicit at the asset-network level. One global rule may be unsuitable because fees, confirmation behavior, liquidity, and treasury demand differ across routes.

The correct settlement model is determined by net usability, not gross payment value

A merchant does not operate on the amount displayed at checkout. It operates on the net amount available after payment fees, conversion costs, network fees, withdrawal fees, and timing effects.

Immediate external settlement may maximize direct control, but create many network transactions. Internal or scheduled settlement may reduce transfer cost, but increase platform balance exposure. Converted settlement may simplify treasury value, but add price execution and liquidity dependence.

The business should model both normal and stressed conditions. A route that is efficient during low fees may become uneconomic during congestion. A stablecoin route that looks liquid may become difficult to redeem in a specific jurisdiction or banking window.

De OxaPay página de precios provides the platform fee context, while network and conversion costs still depend on the selected route and transaction conditions.

A settlement record must preserve the full transformation from accepted payment to usable funds

Settlement is incomplete when funds move but the financial record cannot explain the movement. Every settlement should connect the original payment, settlement asset, destination, rate, fees, status, and final amount.

Settlement status must remain separate from payment status

A payout failure does not make the original customer payment unpaid. It creates a settlement exception. The system should preserve the accepted payment while retrying, rerouting, or returning funds to an available balance.

Settlement states commonly include queued, processing, confirming, completed, failed, and canceled. Every retry must be idempotent. A repeated instruction must not create a second external transfer. Conversion failures also need a defined fallback, such as retaining the original asset or moving the case to review.

Conversion records should be independently queryable. OxaPay provides a Swap Request endpoint y Historial de intercambio for executing and reviewing asset conversions.

Different business models require different settlement policies

The best model is the one that makes funds usable for the business without creating hidden exposure. Customer preference matters at checkout. Treasury and operating requirements determine settlement.

OxaPay components can support different settlement combinations

OxaPay separates payment collection, internal balances, conversion, and payouts into distinct operational capabilities. This allows merchants to compose a settlement policy instead of treating payment acceptance and external withdrawal as one action.

Merchants should still define their own treasury policy. The platform provides execution and visibility, while the business decides target assets, destination controls, reserve levels, timing, and approval limits.

Choose settlement by answering seven operational questions

1. Which assets does the business need for expenses, reserves, refunds, and payouts?
2. How much volatility can remain open after payment acceptance?
3. Which balances should remain internal, and which must move to external custody?
4. How quickly must funds become externally available?
5. Which transaction size makes an external transfer economically reasonable?
6. What approval, allowlisting, and retry controls protect settlement transfers?
7. Which records prove the accepted amount, conversion, fees, destination, and final net amount?

Primary references and implementation resources

• BIS glossary of payment and settlement terms
• BIS: Distributed ledger technology in payment, clearing, and settlement
• Bitcoin Developer Guide: Payment Processing
• Circle Mint: stablecoin minting and redemption
• Stripe: managing payout schedules
• OxaPay Account Balance API
• API de intercambio de OxaPay
• API de pago OxaPay