Prompts

Add Bachs one-time payments to this app. Inspect its framework, authentication,
order records, and payment code first. Reuse those conventions. Ask for the
item, currency, or fulfilment decision if missing.

For a Node.js or TypeScript server, use the official SDK for checkout and
webhooks.constructEvent for signature verification. Read its supported methods
and release instructions at https://github.com/bachsdev/bachs-node and
https://github.com/bachsdev/bachs-nextjs-saas/tree/main/vendor.
Check the installed version; npm 0.0.1 is only a placeholder. Do not reimplement
the SDK transport. For another server language, use the documented API.

Read:
https://docs.bachs.io/guides/checkout/checkout-sessions.md
https://docs.bachs.io/guides/webhooks/overview.md
https://docs.bachs.io/build/use-cases/digital-products.md
https://docs.bachs.io/guides/webhooks/events/collection-succeeded.md
https://docs.bachs.io/guides/idempotency.md

Use https://sandbox-api.bachs.io with BACHS_API_KEY on the server. Explain
dashboard setup, including products and webhook events.

Create checkout on the server with product_cart and our order reference.
Choose prices and product IDs on the server. Save the checkout ID and expected
amount and currency with the order, then redirect to checkout_url. For local testing, omit checkout return URLs; if configured, they must be public.

Verify X-Bachs-Signature-V2 on the raw body before parsing JSON, including
timestamp tolerance and every v1 signature. Fulfil once on checkout.completed
or collection.succeeded, whichever arrives first, after retrieving the checkout
and matching it to the order, amount, and currency. Store event IDs durably; make
fulfilment and event completion atomic or recoverable. Return 5xx on handling
failure. The success page reads our order state and handles a delayed webhook;
visiting it never marks an order paid.

Keep secrets server-side and amounts as decimal strings. Persist an
Idempotency-Key for each write operation. Reconcile an uncertain write before
retrying with the same key and unchanged request.

Test success, unsuccessful checkout, a bad signature, duplicate delivery, and
failed processing followed by redelivery. Report what you actually ran, what
I must configure, and how to complete a real sandbox checkout. Read linked
docs for missing details; do not invent API behavior.

Add Bachs subscriptions to this app. Inspect its authentication, database,
access checks, and billing code first. Reuse them. Ask for missing plan details
or the access policy during payment recovery.

For a Node.js or TypeScript server, use the official SDK for products,
checkout, customer portal sessions, and webhooks.constructEvent. Read
https://github.com/bachsdev/bachs-node and the package instructions at
https://github.com/bachsdev/bachs-nextjs-saas/tree/main/vendor.
Check the installed version; npm 0.0.1 is only a placeholder. Keep persistent
keys and business state in our app; handle SDK outcomeUnknown by reconciling.
For another server language, use the documented API.

Read:
https://docs.bachs.io/build/use-cases/saas-subscriptions.md
https://docs.bachs.io/guides/webhooks/overview.md
https://docs.bachs.io/guides/idempotency.md

Use https://sandbox-api.bachs.io and server-side BACHS_API_KEY. Omit checkout return URLs for local testing; configured redirects must be public. Explain how
to create recurring products in the dashboard or API, configure portal settings,
and forward the five webhook events named in the use case.

Map a plan key to a product ID on the server. Create checkout with product_cart,
customer, billing_currency, and metadata.user_id. Recurring checkout starts the
subscription; there is no create-subscription endpoint. If the user already
has access, direct them to manage billing.

Verify X-Bachs-Signature-V2 on the raw body, with timestamp tolerance and all
v1 signatures. From customer.subscription.created, updated, and deleted, save
the customer ID and full subscription state against our user. Deduplicate
durably and prevent older events overwriting newer state, including concurrent
deliveries. Commit state and event completion together; return 5xx on failure.

Decide access from stored state, including trialing, active, past_due, and
cancellation. The success page only reads that state. Create each portal
session on the server for the signed-in user's own customer ID. Check the
documented portal settings and cancellation defaults.

Keep secrets server-side and amounts as decimal strings. Persist one
Idempotency-Key per write operation; reconcile uncertain writes before retrying.

Test activation, duplicate and out-of-order events, failed handling followed by
redelivery, renewal failure, and cancellation at period end. Report tests
actually run, remaining setup, and real sandbox checkout steps. Read linked
docs for missing details; do not invent behavior.

Review this codebase's Bachs payment integration before we go live. Do not
change any code.

First read:
https://docs.bachs.io/go-live.md
https://docs.bachs.io/guides/webhooks/overview.md
https://docs.bachs.io/guides/checkout/checkout-sessions.md
https://docs.bachs.io/guides/idempotency.md

Then read our integration: checkout, webhook handling, success or return pages,
billing or portal routes, and configuration.

Report each problem with its file and line, ordered by risk, with one sentence
on why it matters and what correct code does. Check at least:
- secret keys or webhook secrets that could reach the browser, logs or the
  repository
- prices, amounts or product IDs taken from the client
- amounts sent as numbers instead of decimal strings with a currency
- orders fulfilled or access granted anywhere other than verified webhook
  handling
- a payment fulfilled without matching it to our order, amount and currency
- webhook bodies parsed before the signature is checked, a missing timestamp
  check, or only the first v1 signature checked
- missing protection against duplicate or out-of-order webhook events
- 4xx responses returned when our own handling fails (Bachs does not retry
  them)
- POST or PATCH requests without a persisted Idempotency-Key
- requests the Bachs docs say are invalid
- sandbox URLs, keys or secrets that must change for production

Then list anything you could not check and why. Do not describe this review as
a sandbox test.