31 lines
1.8 KiB
Markdown
31 lines
1.8 KiB
Markdown
# ADR-0001: Use BTCPay Server as the primary payment processor
|
|
|
|
## Status
|
|
Accepted
|
|
|
|
## Context
|
|
- The product requires crypto invoice checkout with manual subscription renewal.
|
|
- `merchant noKYC` is a hard requirement.
|
|
- `crypto-to-crypto noKYC` is desirable, but it does not replace the merchant-side requirement.
|
|
- Hosted processors can offer a usable API surface, but they also introduce AML/KYC escalation risk, payout holds, and custodial exposure.
|
|
- The product already targets operator-managed infrastructure, so an additional self-hosted payment component is operationally acceptable.
|
|
|
|
## Decision
|
|
Use `BTCPay Server` as the primary payment processor.
|
|
|
|
Keep the application payment adapter provider-agnostic, but treat hosted processors as non-default alternatives that require an explicit policy change.
|
|
|
|
## Rationale
|
|
- `BTCPay Server` is self-hosted and non-custodial, which fits the hard `merchant noKYC` requirement better than hosted processors.
|
|
- A self-custody path materially reduces the risk that a payment provider freezes merchant balances after receiving suspicious funds.
|
|
- The API and webhook model is sufficient for invoice creation, status reconciliation, and callback handling.
|
|
- The operational tradeoff is acceptable because the product already assumes server-managed infrastructure.
|
|
|
|
## Consequences
|
|
- Deployment must account for a self-hosted BTCPay stack and its persistent data.
|
|
- Payment operations now include wallet, backup, and reconciliation responsibilities that a hosted processor would otherwise absorb.
|
|
- Later support for hosted processors remains possible through the shared payment adapter contract, but they are out of policy unless the `merchant noKYC` requirement changes.
|
|
|
|
## References
|
|
- [payment-provider-selection.md](/home/sirily/nroxy/docs/ops/payment-provider-selection.md)
|