At a glance
| Decision | Practical answer |
|---|---|
| Start here | Use a hosted flow for supported receiving needs; evaluate self-hosting when operational control justifies maintenance. |
| Choose deliberately | Assign responsibility for upgrades, monitoring, callbacks and recovery before operating a server. |
| Main tradeoff | Free software is not a zero-maintenance payment business. |
Running payment software yourself gives you operational control and operational work. Using a hosted interface delegates some of that work, but does not answer who controls the receiving funds. Choose hosting and custody separately.
This article covers the operating-model decision in the merchant payment series. For signing authority and withdrawal conditions, read custodial versus non-custodial receiving.
Three practical starting points
| Approach | Suitable question to ask | Work you still own |
|---|---|---|
| Direct wallet address | Do both sides already understand the amount, asset and network? | Customer instructions, receipt checking and order records |
| Hosted payment link or POS interface | Does the product supply the request and feedback the sale needs? | Configuration, access protection, order matching and exception handling |
| Self-hosted payment system | Do we need operational control or custom behavior enough to maintain it? | Deployment, updates, infrastructure, monitoring, backups and integrations |
A provider-hosted page can receive to a merchant-controlled wallet. Self-hosted software can also connect to a custodial service. Neither axis should be inferred from the other.
Start with a failure you can manage
For a small market stall, a useful question is what the cashier does if a customer says a payment completed but no notification appeared. A product with a clear receipt view can be more valuable than a highly configurable stack nobody at the counter can operate.
For an online shop, ask what happens when a callback is delayed or duplicated. Your system must keep order state consistent and avoid delivering twice. Hosting the payment server yourself does not automatically build that order logic. Read callbacks versus redirects.
Inventory the self-hosted work
Write down who is responsible for each task before choosing a deployment:
- Keeping the payment application and dependencies updated.
- Supplying reliable network/RPC or node access where the chosen system requires it.
- Protecting credentials, signing permissions and operational endpoints.
- Backing up configuration and necessary state, then testing restoration.
- Monitoring failed or uncertain payments and reconciling results.
- Maintaining callback integrations and the business's order records.
BTCPay Server's documentation is a useful primary source for one self-hosted option. Its Bitcoin and Lightning workflows have their own requirements; they should not be presented as identical to a hosted USDC link.
Count the total cost of ownership
A free software license does not remove infrastructure or staff time. A hosted service fee does not automatically mean the service supplies every workflow your business requires. Compare the actual responsibilities and estimate the time needed to maintain the chosen arrangement.
Use the payment cost worksheet for transaction-related components, then add hosting, maintenance and support as a separate operational budget. Avoid assigning an invented hourly saving to a product without evidence.
Keep the product boundary clear
Current PayIn QR/Link is a hosted USDC receiving product. PayIn Open is a separate self-hosted gateway with its own operating and integration requirements. An Open API example is not evidence that the hosted product exposes the same endpoint, feature or pricing arrangement.
Use current product documentation for the hosted flow and the Open overview when assessing that independent system. Verify the version and documentation for the system you actually run.
A decision exercise
Write down the next ten sales you expect: their approximate value, customer wallets, whether they occur at a counter, required confirmation, and how fulfillment is recorded. Then assign an owner for configuration, exceptions and recovery.
If a hosted tool supplies those specific needs and you do not need a custom backend, it may be a manageable starting point. If integration or deployment control is essential and you can operate the system, evaluate self-hosting. If the only need is an agreed transfer between knowledgeable parties, an address may be enough.
The provider comparison helps compare named services. The payment-link versus address guide explains the extra context a merchant-facing tool can add.