Settlement rail
EARLY ACCESSGetting paid belongs in your self-custody plan.
You hold the keys to your savings. Apply the same question to your revenue: who can move it after the customer pays? We scope a receive-only settlement setup around open BTCPay Server.
At a glance
EARLY ACCESSThe decision before the work.
Who this is for
For a business that wants to receive Bitcoin into a setup it controls and can take responsibility for wallet security, reconciliation, exceptions, and support.
What the assessment gives you
A payment-flow map, receiving and signing responsibilities, proposed integration scope, and the acceptance tests needed before taking customer payments.
What is separate
Early access. Compatibility and implementation availability are assessed individually. This is not a promise that a particular asset, network, or shop integration is ready.
A 60-minute strategy session is $2,000 by card or $1,750 via BitSettle. Written assessment within 24 hours after the session. Further professional fees are quoted afterward. The amount paid credits professional fees for services retained within 30 days after the session.
See an illustrative exampleIllustrative working example
The payment that needs a human decision.
A merchant invoices for a service and a customer sends less than the requested amount after the invoice window closes. This is an illustrative operational sequence, not a live checkout demonstration.
Starting facts
The invoice identifies the asset, network, amount, and payment window. A transaction is observed. That observation does not by itself authorize fulfillment or a refund.
What still needs an answer
The merchant must confirm the transaction, amount, network, and policy for late or incomplete payments. A refund requires its own recipient check and signing decision.
Follow the work and the responsibilities
Invoice and receiving setup
Record the invoice and observed payment separately. On the normal path, apply the agreed confirmation rules before reporting settlement to the business system.
Merchant operations
For an underpayment or late payment, pause automatic fulfillment and follow the agreed policy. Keep the original invoice and the decision together in the record.
Technical review
Treat a wrong-network payment as an exception requiring assessment. Do not mark it settled or promise recovery because a transaction hash exists.
Wallet signer
Authorize any refund separately after checking the recipient, asset, network, and amount. The receive-only integration does not receive private keys to do this.
The next decision. Test the successful payment and each exception before accepting customer funds. Decide who responds when a payment cannot safely be treated as complete.
After the initial work
Wallet backups, monitoring, reconciliation, refunds, and incident response need explicit owners. Hosting and support terms are agreed separately from the strategy session.
Routes, requirements, and practical work
Get paid into a wallet you control.
A payment button is the beginning. Your business also needs an invoice it can reconcile, a clear release rule, and someone responsible when a payment arrives late or on the wrong network. Our settlement work brings those decisions together. BitSettle remains in early access; availability and the exact deployment are confirmed before any implementation is agreed.
From checkout to a reconciled payment.
A merchant checklist for receiving Bitcoin or USDT: wallet ownership, invoice rules, customer instructions, testing and operating handoff.
Read the guide Payment operationsThe asset, the network and the invoice.
Understand token identity, confirmations, invoice exceptions and refund control before accepting Bitcoin or USDT.
Read the guideExplore this service5 sections
Start with how your business gets paid.
A consultancy collecting a few large invoices has different needs from a store shipping hundreds of orders. The first needs reliable payment identification, confidentiality and a clear handoff to its accountant. The second also needs automated order status, a fulfilment hold, customer support and a process for duplicate or partial payments. A payment system should reflect that difference.
We map the customer journey, average invoice size, operating currencies, existing checkout and people who approve refunds. The resulting scope identifies what should be automated and what should remain a deliberate human decision. It also records whether your customers actually want to spend Bitcoin or USDT. Adding a payment method that nobody uses creates work without solving a business problem.
Separate payment detection from control of funds.
The receiving model is straightforward: the customer sends to an approved destination, the system checks the payment, and the business retains control of its wallet. Watching an address does not require the private key that spends from it. Public receiving information still deserves protection because it can reveal commercial activity.
Implementation scope covers wallet compatibility, destination verification and recovery responsibilities. Bitcoin on-chain, Lightning and token payments do not have identical security models. A Lightning node may hold spending authority and needs its own liquidity, backup and access plan. We do not apply a blanket watch-only claim to every possible deployment.
| Responsibility | Business decision |
|---|---|
| Receiving wallet | Who controls the keys and can recover access? |
| Payment confirmation | What evidence allows the order to be released? |
| Refund | Who verifies the request and signs a separate payment? |
| Records | How does the invoice match the ledger and accountant’s export? |
What a settlement scope contains.
Checkout and invoices
Define the order reference, quoted asset, expiry, receiving destination and customer instructions. Connect payment status to the existing order process only after the relevant platform has been checked. A list of available integrations is not proof that your own checkout has been tested.
Network selection
Enable only the asset and network combinations approved for that deployment. Confirm the exact token contract or mint, confirmation policy and customer wallet behavior. Similar symbols and familiar address formats do not make different networks interchangeable.
Operations and reporting
Agree who monitors availability, handles exceptions, maintains software and produces the records your accountant needs. Multi-store reporting, dedicated infrastructure, white-label presentation or conversion arrangements require an explicit scope and a verified provider path.
Compare the whole cost of receiving money.
The useful comparison is between your current bill and a written implementation proposal. Include percentage processing charges, fixed transaction costs, currency conversion, withdrawals, network fees, hosting, support and staff time. If an option removes a percentage fee but adds a fixed operating cost, the benefit depends on your actual volume. It is not automatically cheaper at every scale.
Our assessment also looks at cash-flow delays, refund workload and the cost of an incorrect fulfilment decision. A manual wallet can be adequate for a very small business; a custodial provider may supply services you still need. We quote professional implementation and ongoing support separately in writing. No setup price, subscription tier or saving is implied by this page.
One invoice before a wider rollout.
A sensible acceptance check follows one order from creation to accounting. Confirm what the customer sees, trace the payment to the intended wallet, check the confirmation state and reconcile the final amount. Then examine an expired invoice, an incomplete payment and a duplicated notification. The process should stop safely when evidence is missing.
The merchant-onboarding guide below turns that review into a practical checklist. The payment-risk guide explains the distinction between an issuer, a network, a wallet and an invoice. Early access starts with a scoped review of your business and the available implementation, followed by a written decision on what can proceed.
Before you decide
Common questions.
Does accepting Bitcoin remove refund obligations?
No. The payment rail and the underlying sale are separate. A confirmed transaction does not decide a contractual dispute or remove obligations under applicable law. A refund is a separately authorized outgoing payment.
Can I enable every network shown in the technical material?
Only after the exact asset, receiving method and implementation have been checked. The deployed checkout determines what a customer may send; a research table is not an activation promise.
Will you ask for my seed phrase?
No. Do not send seed phrases, private keys or wallet backups through an inquiry form. Any deployment involving signing authority requires a separate, explicit security design.
The mechanic
The invoice is ours to configure. The wallet stays yours.
Separate invoicing, observation, and signing. They do not need the same permissions.
Your customer receives an invoice
An invoice identifies the amount, the asset and network, and the payment window. The checkout should make those choices explicit before any funds move.
The payment reaches your receiving setup
For on-chain Bitcoin, BTCPay Server can derive receive addresses from a public key without receiving your private key. The chosen wallet configuration matters.
The system observes the result
Payment status and a payment record are different from permission to spend. We define confirmation handling and what happens when an invoice expires or the amount differs.
You control outgoing transactions
Signing and refunds remain with you under the agreed receive-only scope. Lightning and any hosted wallet require a separate review of permissions and key custody.
Before integration
Agree the boundaries. Then connect the rail.
The configuration brief
- What you sell, how invoices are created, and which store or workflow needs a payment result.
- The exact assets and networks enabled for your setup, with receiving addresses checked.
- Who holds each credential, which permissions it grants, and how access is revoked.
- How exceptions, refunds, accounting exports, backups, and support are handled.
The boundary
- Do not send us seed phrases or private keys.
- The rail is not a bank account or an automatic conversion promise.
- An invoice marked paid does not make an irreversible payment reversible.
- The professional fee is quoted in writing after the session. Network and third-party costs are identified separately.
Plain talk
Control comes with work to do.
Self-custody changes who is responsible. It does not remove operational risk.
- A wrong address or wrong network can make a payment unrecoverable. The checkout must specify both.
- An invoice can be underpaid, overpaid, late, or unresolved while a network is slow. An exception policy is part of the setup.
- USDT adds issuer risk. If enabled, it must be assessed separately from native Bitcoin.
- Your receiving configuration, backup discipline, and access controls matter more than a non-custodial label.
- If you can run and maintain BTCPay Server yourself, you may not need our coordination. The software is open source.
The first deliverable
A payment map you can inspect.
The session starts with the current payment path. We identify the points where someone else can hold funds, the credentials that can authorize spending, and the operational work a different arrangement would create.
The written assessment sets out the proposed scope and the tests that need to pass. Implementation is a separate engagement. Early access is not an assurance that every requested integration is available.
Start with the payment path
Show us how you get paid.
Bring the business model and the current checkout. The first question is who controls the funds, followed by what it takes to operate a different arrangement.
$2,000 by card. $1,750 via BitSettle.
The amount paid is credited toward professional fees for services retained within 30 days after the session.