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

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