FX rates

Rate locking

When you call POST /orders/ with input_currency, B4bit Pay returns in the response:

• rate — price of the crypto in USDC at that moment.
• expected_input_amount — crypto amount equivalent to expected_output_amount (in fiat).

The rate is locked during the order’s validity window. If the crypto price rises or falls afterwards, it does not affect the amount the customer must pay.

Internal settlement in USDC

Note

B4bit Pay’s public documentation mentions “automatic conversion to USD”, but the technical implementation settles internally in USDC (a stablecoin 1:1 backed by USD).

The fiat_amount and received_amount fields in the Payment schema are nominally in the order’s fiat currency; internally the balance is stored in USDC. For the merchant, the practical outcome is the same.

Conversion flow

1. The customer pays X in crypto (for example 0.001 BTC).
2. B4bit Pay converts to USDC at the market price at the time of confirmation.
3. The USDC is credited to the merchant’s balance.
4. The merchant withdraws the balance in the crypto of their choice (can be BTC again, USDT, DAI, etc.).

Accounting implications

• The fiat_amount of an order is what you charge the customer.
• The balance in the dashboard is always expressed in USD (1:1 equivalent to USDC).
• For tax reports, use fiat_amount as the sale value; use rate and received_amount for the crypto detail.

Rate source

The rate used by B4bit Pay is based on liquid reference markets (it is not the spot price of a single exchange). This reduces one-off distortions but may differ slightly from the CoinMarketCap price at the same second.

What NOT to expect

• No automatic hedging against volatility after the order is created. If the customer takes time to pay and the crypto price rises, you receive less crypto; if it falls, more. expected_input_amount is calculated only once.
• No automatic reverse conversion on refunds. Refunds are handled manually and the exchange rate may be different. See refunds.