Bitcoin or USDC Checkout: Pick the Rail by Invoice Timing
If you are searching bitcoin or usdc checkout, you already know both rails exist.
The remaining question is not “which coin is better?”
It is: which rail belongs on this invoice, given how you bill.
Quick answer: Due-date and net-terms invoices need USDT or USDC enabled. Bitcoin is not used on due-date invoices. Immediate countdown invoices can take BTC, stables, or both. You create one USD-priced invoice; the buyer pays with any method you enabled, on /pay/:id.
If you already picked the rail and need the implementation page, stop here:
This page is only the timing decision.
The split that actually matters
| Invoice timing | Bitcoin | USDT or USDC |
|---|---|---|
Immediate countdown (expiresAfterMinutes 1–1440) | Yes | Yes |
Due date + grace (dueAfterDays 1–60, grace 0–90) | No | Required |
That pairing is in the Checkout docs, not a preference. Due-date invoices require an enabled USDT or USDC payment method. Bitcoin payment methods are only used for immediate invoices.
Volatility is a real merchant concern. It is not the rule that decides the rail.
Due-date / net terms → enable USDT or USDC
Use due-date timing when the invoice should stay payable through a due date and a grace window — net-7, net-30, a client bill that is not a 20-minute cart.
Documented bounds: dueAfterDays 1–60, gracePeriodDays 0–90. There is no live countdown. The invoice stays payable until dueAt + gracePeriodDays, then it expires.
Bitcoin does not participate on that invoice. If you only enabled a Bitcoin method, you do not have a due-date rail.
Enable USDT and/or USDC before you create the net-terms invoice. Then create the invoice. Do not wait until the buyer opens /pay/:id to discover the only method is BTC.
Immediate countdown → Bitcoin, stables, or both
Use immediate timing for a standard checkout clock.
expiresAfterMinutes must be between 1 and 1440. The hosted page shows the countdown. The buyer pays before payableUntilAt, or the invoice expires.
On that clock, you can enable:
- Bitcoin only — unique address from your xpub, quoted in BTC against the USD amount
- USDT / USDC only — dollar-stable settlement on the networks you turned on
- Both — one invoice; the buyer picks
Pick Bitcoin when the buyer is Bitcoin-native and you will live with a BTC quote that moves until they broadcast. Pick stables when you want the paid amount to stay a dollar. Enable both when you do not want to guess.
One USD invoice, buyer picks on /pay/:id
Each invoice is one USD payment request. Minimum amountUsd is 0.01.
You do not choose the coin on a standard invoice create. The dashboard methods become paymentOptions[]. Send the buyer to https://fincobra.com/pay/:id. They use any enabled method that exists on that invoice.
That is why timing has to be decided first. A due-date invoice will not grow a Bitcoin option because the buyer prefers BTC. An immediate invoice will only show the methods you actually enabled.
Networks and where the funds land
| Network | Assets | Settlement |
|---|---|---|
| Bitcoin | BTC | Unique invoice address derived from your Bitcoin xpub (ypub / zpub also accepted) |
| Ethereum mainnet | USDT, USDC | Wallet-contract or address-transfer → your Ethereum payout wallet |
| Solana | USDT, USDC | Connected wallet pays your Solana recipient wallet |
| Arbitrum One | USDC only | Wallet-contract or address-transfer → your Arbitrum payout wallet |
| Base | USDC only | Wallet-contract or address-transfer → your Base payout wallet |
No USDT on Arbitrum or Base.
Funds go to the wallets you configured. FinCobra records volume for billing; it does not hold a merchant balance you later withdraw.
Bitcoin or USDC checkout when both rails are on
Enable both when your default invoices are immediate and your buyers are mixed.
Then a $49.99 invoice can be paid in BTC or USDC (or USDT) without a second create. That is the whole point of one USD invoice and a hosted /pay/:id page.
Do not enable Bitcoin as a “nice extra” if your real billing is due-date. It will not appear on those invoices. Enable the stablecoin method that due-date actually uses.
If most invoices are net terms and a few are 20-minute carts, enable stables for the book, and add Bitcoin only if those immediate carts need it.
What this page is not choosing
Say the boundaries once.
- No Lightning. There is no LN invoice. If the job is sats over Lightning, this is the wrong product.
- No fiat bank settlement. Funds land in your crypto wallets. There is no “get paid in USD to the bank” path.
- No Shopify app. Hosted invoices and the Checkout API. Not a cart adapter.
- No any-token catalog. Not native ETH. Not Tron. Not Polygon. Coinbase Business lists Polygon for USDC pay-ins; FinCobra does not. Our EVM set is Ethereum, Arbitrum One, and Base, with USDC-only on the last two.
Those are other articles, or other products.
Enable the methods, then create the invoice
- Decide the invoice timing you actually use (immediate clock vs due date).
- Enable the methods that timing allows (stables for due-date; BTC and/or stables for immediate).
- Point wallets: Bitcoin xpub; EVM payout wallets; Solana recipient wallet.
- Create the USD invoice and send the buyer to
/pay/:id.
Checkout billing is Free Start on the first $1,000 of paid invoice volume, then 0.5% of paid volume, billed monthly in arrears. Unpaid invoices do not count.
If that is the model — hosted invoice, your wallets, documented rails — book a live walkthrough and configure your own wallets. Docs: configuration, invoices, billing.
If you already know you only want Bitcoin, use the own-wallet Bitcoin page. If you already know you only want stables, use the USDT/USDC Ethereum page.
Do not turn this URL into a second how-to for either query.