Replace Helcim integration with WooCommerce Stripe

README.md

@@ -101,39 +101,34 @@ After that, the starter site's content and Customizer settings persist in
 the database like any other WordPress content — a redeploy or a fresh
 `deploy.sh` run doesn't touch it or need to repeat it.
 
-### Payments: Helcim (preauth/capture)
+### Payments: WooCommerce Stripe (authorize/capture)
 
-The Helcim gateway is a **custom `WC_Payment_Gateway`** shipped inside
-`bookstore-core` (`Payments\HelcimGateway`, built directly against
-HelcimPay.js) — not the off-the-shelf `helcim-commerce-for-woocommerce`
-plugin, which `deploy.sh` deliberately does not install (it only
-supports immediate charges; see design doc Appendix B). Checkout
-authorizes (holds) the card; the charge only actually happens once the
-supplier order succeeds (`Order\SupplierOrderJob`) — see that class and
-`Payments\HelcimClient`'s docblocks for the full sequence.
+Deployment installs and activates the official `woocommerce-gateway-stripe`
+extension and enables its **Issue an authorization on checkout, and capture
+later** setting. Stripe owns card collection, Checkout Block integration,
+webhooks, authorization, capture, and cancellation; `bookstore-core` never
+handles card data or Stripe API credentials.
 
-The gateway needs a Helcim **sandbox API token**, which isn't something a
-public API can hand out, so it's a one-time manual step per environment:
+Set `STRIPE_MODE`, `STRIPE_PUBLISHABLE_KEY`, `STRIPE_SECRET_KEY`, and (when
+available) `STRIPE_WEBHOOK_SECRET` in `.env.<environment>`, then deploy. The
+deploy script writes them to gitignored Docker secret files and configures the
+official gateway without printing the credentials. Stripe stays disabled when
+either API key is missing. Use test keys until checkout, webhooks, capture, and
+cancellation have been exercised end to end.
 
-1. Sign up for a free Helcim account.
-2. Helcim dashboard → **Integrations → API Configuration** → create an API
-   token.
-3. Put it in `HELCIM_API_TOKEN` in `.env.<environment>`, then re-run
-   `make deploy ENV=<environment>`.
+For manual API-key connections, create a Stripe webhook endpoint for
+`https://<store-host>/wc-api/wc_stripe`, subscribe it to the events recommended
+by the WooCommerce Stripe settings screen, and place its `whsec_...` signing
+secret in `STRIPE_WEBHOOK_SECRET`. The workflow has seven days from checkout
+to capture an online card authorization. Manually entered keys do not provide
+Stripe-to-WooCommerce payment-method synchronization or every feature of the
+OAuth connection.
 
-`deploy.sh` writes the token to a gitignored secrets file the same way it
-already does for `HARDCOVER_API_TOKEN` (see `secrets/<env>/` above), and
-`Payments\HelcimGatewayConfig::ensure_configured_from_env()` seeds the
-gateway's WooCommerce settings (sandbox mode, disabled by default — a
-human still enables it at checkout once ready) the first time it finds a
-token. **Until a token exists, `Payments\HelcimClient` runs in fake
-mode** — every preauth/capture/reverse call returns a synthetic approved
-response instead of hitting the real API, so the whole checkout ->
-preauth -> fraud review -> supplier order -> capture/reverse flow is
-testable end-to-end without one (same pattern as the synthetic
-`gutenberg_test` supplier). Go-live (switching from sandbox to Helcim's
-live environment) is a deliberate manual step on the settings screen,
-not something this repo automates.
+An authorized Stripe order arrives as **On hold**. `Order\SupplierOrderJob`
+runs the local fraud extension point, confirms the distributor order, and
+then changes the order to **Processing**, which makes the Stripe extension
+capture the authorization. A distributor failure changes the order to
+**Cancelled** so Stripe releases the hold, then routes it to **Needs Review**.
 
 ### Admin access restriction (production)
 
@@ -212,11 +207,11 @@ with a bigger `--limit` continues forward instead of rescanning. Pricing
 
 ## Checkout + order engine (Week 3, payment flow revised)
 
-A synchronous pre-authorization supplier/margin recheck runs right
-before the card is held (`Order\CheckoutRecheck`, price/margin only —
-never charges anything). The custom Helcim gateway (see "Payments:
-Helcim" above) then holds the card and, once the fraud check
-(`Payments\FraudCheck`) passes, moves the order to `bsc-authorized`
+A synchronous supplier/margin recheck runs right before payment
+(`Order\CheckoutRecheck`, price/margin only — never charges anything).
+The official WooCommerce Stripe extension then holds the card and its
+On-hold transition runs the fraud check (`Payments\FraudCheck`) before
+moving the order to `bsc-authorized`
 (held, not charged). `Order\SupplierOrderJob` picks it up from there:
 submits to the supplier, and only on success **captures** the hold (the
 card is actually charged for the first time here) before moving to