Accepting Bitcoin and Litecoin While Pricing in Dollars

The problem stablecoins do not have

A USDT invoice for $50 asks for 50 USDT. There is nothing to convert and nothing to argue about.

A Bitcoin invoice for $50 asks for some fraction of a bitcoin, and that fraction changes every second. If the price moves between the moment you show a number and the moment the customer sends it, someone absorbs the difference.

Rate locking

The fix is to fix the rate when the invoice is created and keep it for the whole life of that invoice. The customer sees one number, sends exactly that number, and it matches.

The rate is stored with the invoice, so the fee and the reported amount are all computed from the same figure. Fetching a fresh rate at settlement time would mean the amount the customer already sent no longer matches what the system expects.

• The rate is captured once, at invoice creation
• It never changes while the invoice is open
• Fee is charged on the USD value, not on the coin amount
• The callback reports USD, so shop code does not need to know about conversion

Who takes the price risk

Between creation and payment, the price can move. Because the amount is fixed in coin, you receive a coin quantity whose dollar value may be slightly above or below the invoice.

Keeping invoice windows short limits this. An invoice open for fifteen minutes carries far less risk than one open for two hours, which is the real argument for a shorter expiry rather than any technical constraint.

Precision matters more than it looks

Rounding the coin amount too coarsely is a silent leak. Round a Bitcoin amount to six decimal places and each step is worth about eight cents at recent prices — on a $10 order that is nearly one percent, more than most gateway fees.

Amounts should be carried at the chain's own precision, not at whatever looked tidy. Bitcoin has eight decimals; use them.

What your server should read

The callback reports the amount in USD, the amount actually sent on chain, and the locked rate. Credit the USD figure. Keep the coin amount for reconciliation against a block explorer.

This keeps existing shop code working unchanged: it reads the same amount field it always did, and never has to learn that a payment arrived in a different currency.