docs: payment provider options for worldwide sales (D49, open)

docs/decisions.md

@@ -50,3 +50,4 @@ Format: ID, date, decision, why. Add new entries at the bottom; do not rewrite h
 - **D46 (2026-10-21) ControlPlane v1 is an operator-only admin API behind one admin key, built with EF Core on the existing tables.** Why operator-only: tenants are created by an operator in v1 (`tenancy-and-limits.md`), and the customer login (Cognito, P2-3) and portal API come later; building self-service now would delay launch. Why a single key in a header: simplest thing that is safe over HTTPS, compared in constant time on hashes, disabled (503) when not configured so an unconfigured deployment can never be open; the key lives in Secrets Manager/environment, never in the repo. It is intended for a handful of operator actions, and moving to Cognito groups later does not change the routes. Why EF Core here (D43): this is CRUD over five tables with checks and transactions, off the hot path; the context maps only the columns it uses and never generates schema. Secrets and API keys are returned exactly once. Business rules enforced in the API: plan must exist, endpoint cap per plan, a plan change below the endpoint count is refused, URLs pass the same SSRF validator the Dispatcher uses. Every state change is logged with tenant and object ids, never with keys or secrets. Cache invalidation is not built: changes show up within the 30 s cache TTL, which is acceptable for operator-driven changes; add explicit invalidation if a faster suspend is needed. API/secret *rotation* of endpoint secrets is not included (D45 note).
 - **D47 (2026-10-21) The developer site, docs and purchase flow are Phase 5 (S-1..S-15), built last; we will not claim "end-to-end encrypted" unless it is built.** Owner asked for a docs website with menus, interactive tools and sample code in many languages, plus the plan purchase flow, and for customers to feel confident about encryption. Why last: it describes behavior that must be finished and stable, and sample code is only trustworthy if CI runs it against the real system (S-5, S-12). Why a separate repo: same reasoning as the portal (D27), different release rhythm, and the OpenAPI document published from this repo keeps the reference in step with the code. Why the careful encryption wording: the platform has to read events to route and deliver them, so the accurate claim is TLS in transit, encryption at rest everywhere and signed deliveries; overstating it would damage trust and may be misleading. Real end-to-end encryption (customer-held keys) is offered as a possible later feature (S-14) because it trades away replay and inspection. Payment provider and prices are owner decisions (Razorpay or Stripe, plan numbers) needed before S-9.
 - **D48 (2026-10-21) Customer-held end-to-end payload encryption is out of scope; the security page describes only TLS in transit, encryption at rest and signed deliveries.** Owner said to skip the end-to-end encryption part. This removes S-14 from Phase 5. The wording rule from D47 stays: the site must not call the service "end-to-end encrypted", only state what the system does. It can be reopened later as a separate feature.
+- **D49 (2026-10-21) OPEN: payment provider for worldwide sales (needed only for S-9, built last).** Owner asked whether the gateways accept international payments. Findings (web research 2026-10-21, vendor claims unverified): **Razorpay** accepts foreign cards in about 135 currencies but activation is on request, fees reported at up to ~3% + 18% GST, and whether an Indian merchant can settle in USD must be confirmed with them; **Stripe India** supports international payments (IEC required, INR payouts, 3D Secure) but the India program is invite-only; **merchant of record (Paddle, Dodo Payments)** becomes the legal seller and handles foreign VAT/sales tax, at roughly 5% + $0.50 per transaction (Paddle), no figures published for Dodo. Recommendation: a merchant of record for the first worldwide customers (no foreign tax registration, no foreign entity), Razorpay if mostly Indian customers or lower fees matter. Decide when starting S-9; questions for the owner: company or individual, customer mix, willingness to pay ~5%. Sources are in the PR description.

docs/roadmap.md

@@ -69,7 +69,7 @@ Owner request: one website where developers learn the product and where customer
 | S-6 | **Interactive pieces:** "Try it" request console with the reader's test key, live signature verifier (paste a payload, secret and headers), event type / payload builder, delivery simulator that shows a retry timeline for the chosen plan, copy-paste snippets that fill in the reader's own key | L | uses a sandbox tenant, never production data | S-4 |
 | S-7 | **Guides:** receiving webhooks safely (HTTPS, signature check, replay protection with the timestamp, fast 2xx, queue and process later), handling retries and duplicates, testing locally with a tunnel, going to production checklist, migration from other providers | M | | S-3 |
 | S-8 | **Security & trust page (accurate!):** what is encrypted and where (see "Encryption claims" below), SSRF protection, signing, key handling, data residency (`ap-south-1`), retention, sub-processors, incident contact, status page | M | claims reviewed against the code before publishing | S-1 |
-| S-9 | **Pricing page and purchase flow:** plan comparison from the `plans` data, sign up, pick a plan, pay, receive the API key; upgrade/downgrade/cancel; invoices and tax (GST) | L | needs the payment provider decision (Razorpay or Stripe, India-friendly) and the pricing numbers (D42); a billing/subscription service is its own work: webhooks from the provider to the ControlPlane to change plans | S-1, P2-3 |
+| S-9 | **Pricing page and purchase flow:** plan comparison from the `plans` data, sign up, pick a plan, pay, receive the API key; upgrade/downgrade/cancel; invoices and tax (GST) | L | needs the payment provider decision (see D49: Razorpay, Stripe India (invite-only), or a merchant of record such as Paddle or Dodo Payments) and the pricing numbers (D42); a billing/subscription service is its own work: webhooks from the provider to the ControlPlane to change plans | S-1, P2-3 |
 | S-10 | **Self-service signup in ControlPlane** replacing operator-created tenants (v1 is operator-only, D46), email verification, abuse controls | L | risky (auth) | P2-3 |
 | S-11 | **Changelog, status page, support/contact, API versioning and deprecation policy** | S | | S-1 |
 | S-12 | **Docs quality gates in CI:** link check, snippets compile and run, OpenAPI diff fails the build if the reference is stale, spell check | M | | S-4, S-5 |