Quickstart
Install to your first verified USDT invoice.
Six steps to stand up BitSettle inside BTCPay Server the right way: dedicated endpoints, watch-only receive modes, allowlisted rails, and a small test invoice you can trace back to chain data before you raise volume. For the full reference, read the developer docs.
The setup path
Six steps, in order.
Each step is gated by the one before it. Work top to bottom. The goal of the whole sequence is a single test payment whose settlement detail you can verify end to end.
- 01
Install the plugin
In BTCPay Server, open Settings > Plugins > Available Plugins, install BitSettle USDT, and restart the server. The technical plugin identifier remains BTCPayServer.Plugins.USDt.
- 02
Configure production endpoints
Add dedicated RPC, chain API, or Solana endpoints before accepting meaningful volume. Public defaults are acceptable only for quick smoke tests.
- 03
Choose a receive mode
Use manual address pools, EVM account xpub mode, or Solana owner-address pools. Never paste seed words, private keys, or signing keys into BitSettle.
- 04
Enable the rails
Turn on only the exact chains the store wants to accept. Confirm contract or mint allowlists, decimals, and confirmation policies before checkout goes live.
- 05
Create a test invoice
Generate a small invoice, confirm that the checkout displays the intended network and destination, and send only the exact USDT asset on that network.
- 06
Verify settlement details
Review the BTCPay invoice admin details for network, destination, amount, txid, confirmations, and settlement state before increasing volume.
The shape of it
What a configured rail does.
Once the steps above are done, every payment follows the same path: your customer pays on the network they chose, BitSettle watches the chain, and settlement lands in a wallet only you control, with no custody in between.
01
Your customer pays
From any of 9 networks, whatever wallet they already hold.
CustomerThey scan a code and pay in Bitcoin or dollars (USDT) from whatever wallet or exchange they already use.
YouA fresh receiving address is generated per invoice on the network they chose, with no key material on the server.
02
BitSettle watches
We verify the payment on-chain. We observe; we never hold.
CustomerThe payment is verified on-chain in seconds to minutes. No card form, no account sign-up, no middleman to approve it.
YouTransfers are matched against allowlisted contracts, mints, and decimals, then settled only once your confirmation policy is met.
03
Lands in your wallet
Settlement goes straight to a wallet only you control.
CustomerYour invoice marks paid and you're done. The funds are already in your control.
YouBitSettle never holds, custodies, or signs. Settlement goes directly to the wallet you configured. We watch; you own.
Before you raise volume
What a correct setup makes visible.
Don't scale a rail you can't verify. A finished BitSettle configuration surfaces each of these for every invoice. Confirm them on your test payment first.
- A fresh receiving address reserved for every invoice.
- Contract and mint allowlists instead of fragile symbol-only matching.
- Address pools, EVM account xpub mode, and per-network receive configuration.
- Network-specific confirmation, commitment, and block-hash checks.
- Clear settlement detail for every payment: network, txid, destination, and confirmation state.
Rather not run it yourself?
We host, configure, and monitor the whole stack.
Skip the setup entirely. Early members get priority onboarding and a managed BitSettle stack: dedicated RPC, rail health, and settlement, tuned for you.