docs: choose BTCPay for payments

docs/architecture/adr-0001-payment-processor-selection.md

@@ -0,0 +1,30 @@
+# 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)