# 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)