# Testing & launch

> Deployment status updated 27 September 2026. See [Testing & launch](https://dashboard.atlaspay.sh/docs/testing) for verified checks and remaining acceptance work. Email sending is disabled.

Server-side integrations with explicit payment confirmation and safe retries.

## Test and live mode

Use Settings → Workspace mode, or the switch on Stripe Connect, to choose an environment. Test and live data are separate. Switching to live starts separate business verification; it does not convert test accounts, cards, API keys, subscriptions or payments. Live mode involves real money once Stripe enables the merchant's capabilities. The browser clears open forms when switching modes.

Use `ap_test_` keys for integration tests and `ap_live_` keys for production. Your key selects the API environment. Keep the mode query on buyer checkout links and return URLs. Embedded card entry must use a matching Stripe publishable key and connected account. Never use Stripe test cards against live mode.

## September 27 production activation

The Fly bot now uses the Atlas Pay Worker and checkout subdomain, with its original state volume retained. Credentials were verified from the running machine. The bot suite has 31 passing tests, including test/live checkout links.

The checkout signing secret is configured on both frontend and Worker. Embedded wallet Elements is enabled. Dedicated card-only Connect parent configurations are installed in test and live Stripe accounts. A real sandbox Elements session accepted the configuration and manual-capture mode; it was expired without payment, and its signed expiry webhook reached the production database. Database migrations through 0022 are applied.

Email sending remains disabled by choice. Full native-client acceptance, connected-account eligibility, issuer challenges, subscription renewals and real bank payouts still require their own checks. Historical acceptance records below describe the environments tested at those dates.

## September 10 bot onboarding update

The simplified bot flow has 30 passing bot tests; the full Worker suite has 191 passing tests, including 10 new onboarding cases. New merchants confirm country and open Stripe directly, with no chat email questionnaire or separate web signup. Linked web workspace details are reused; existing Stripe accounts resume. Public return pages guide merchants back to the bot without declaring verification complete.

Tests cover authenticated account actions, country validation/locking, account reuse, single-use URL isolation, failed browser opening, legacy chat-state recovery, public-return tampering and processor-error redaction. The return page was visually inspected on desktop and expired-link recovery at 390 × 844. Stripe API responses are explicit fixtures in these tests, not completed real onboarding. At that checkpoint the Fly bot and Cloudflare account pointed to different Worker hosts. The September 27 deployment resolved that mismatch; native-client Stripe test-mode acceptance remains outstanding. See `docs/BOT_ONBOARDING_2026-09-10.md` in the repository.

## September 9 checkout security update

The database backup/rehearsal passed and production D1 migrations through 0012 were applied with all six pre-existing users preserved and no foreign-key violations. The security suite now covers signed request context, body/cookie/path binding, stale/forged headers, atomic concurrent issuance limits, privacy retention, 3DS/CVC/postal and Radar review capture gates, Elements ownership/mode conflicts, real Stripe webhook signature verification, and mode isolation. See [Checkout & security](https://dashboard.atlaspay.sh/docs/payment-security).

Actual Stripe test API checks accepted Elements setup and connected-account card-only manual-capture sessions. Browser testing used isolated local D1 and real Stripe test responses, not mocked payment UI. It verified card setup and redisplay, insufficient funds, failed and successful 3DS, a hold before delivery, full capture through the delivery endpoint, cancellation/release through the cancellation endpoint, and duplicate callbacks without another payment. A real capture test exposed Stripe's rejection of `final_capture` for ordinary single-capture intents; the integration now omits that option. Cached processor idempotency conflicts are held for reconciliation rather than changing keys automatically. `docs/CHECKOUT_ACCEPTANCE_2026-09-09.md` records the evidence and remaining gates.

These checks do not certify real WordPress/Wix stores, every issuer/country, comprehensive VPN detection, native Atlas clients, production load capacity or PCI compliance. DNS, Vercel environment activation and Connect parent card configuration were subsequently completed. Connected-account Radar policies and merchant eligibility still need account-specific acceptance.

## Local checks are not payment certification

Automated tests use isolated databases and explicit processor fixtures to exercise authorization, ownership, amount precision, idempotency, signatures, and integration contracts. Production handlers do not substitute mocked transactions for real Stripe responses.

Passing these checks does not prove a live WordPress/Wix installation, local payment-method eligibility, production capacity, or payout readiness. Record your actual results and environment; do not describe planned tests as completed.

## Store acceptance checklist

-   Valid, invalid, expired, revoked, and wrong-mode API keys; missing permission and cross-workspace resource access.
-   Zero-, two-, and supported three-decimal currencies; tax/shipping/discount totals; minimum/maximum processor amounts.
-   Successful, declined, canceled, expired, and asynchronous payments. A return page must never mark an unpaid order paid.
-   Duplicate requests, network timeouts, changed bodies under the same idempotency key, and retries across a process restart.
-   Tampered/stale webhook signatures, duplicate events, reversed event order, receiver downtime, and event-feed recovery.
-   Full refund, multiple partial refunds, retry of the same refund, pending/failed refunds, and attempts to over-refund.
-   Secret rotation, key expiry, low-traffic scheduled jobs, and recovery of outstanding transactions after revocation.

## Catalog and order acceptance

Run `npm run test:catalog` for CSV/price parsing and `npm --prefix backend test` for real local D1 migrations and isolated processor fixtures. The catalog/order suite covers scope and tenant isolation, owner/origin checks, dry-run imports, full-batch rollback, pagination, stale edit versions, immutable checkout prices, idempotency/reference conflicts, settled-payment verification, refund/dispute holds, duplicate fulfillment, and event recovery. These are automated fixture checks, not completed live-card or shipping tests.

Before release, exercise the dashboard against the deployed database: create and edit a product; import 50 valid rows; reject an existing SKU without partial changes; complete a Stripe test checkout for a physical product; reconcile shipping details and `order.paid`; deliver duplicate callbacks without duplicate shipping; record tracking; refund in Stripe and verify the order hold. Test cards, authentication challenges, merchant eligibility, inventory and tax integration still need dedicated end-to-end acceptance.

## Buyer wallet acceptance

The isolated wallet suite exercises buyer-only access, consent and origin checks, setup ownership, mode separation, immutable order claims, card cloning, retry-after-response-loss, private Checkout URL isolation, payment/fulfillment verification, revocation and scheduled cleanup. Bot tests cover verified-private-chat requirements, safe order links and the absence of money-moving calls from buyer commands. Production code uses D1 and Stripe, not these test fixtures.

The September 9 Elements acceptance above covers actual setup, redisplay, 3DS success/failure, insufficient funds, capture and release on one connected account. Still exercise a second connected account, generic declines, interrupted checkout, card removal during an open payment, refunds/disputes and external callback recovery. See the [wallet launch checklist](https://dashboard.atlaspay.sh/docs/wallet). Production load and soak tests remain unperformed.

## Subscription acceptance

The subscription suite has 19 passing local Workers/D1 tests with explicit Stripe, authentication and Resend fixtures. It covers consent and changed offers, buyer/mode isolation, idempotent enrollment and response-loss recovery, private portal ownership, reminders, expiring one-use bot links, notification visibility, stale invoice failure suppression, email configuration and verification gates, resend-safe retries, expired idempotency windows, stale reminder suppression, and concurrent email leases.

Use [the subscription launch checklist](https://dashboard.atlaspay.sh/docs/subscriptions) for real Stripe test-clock, portal, Resend deliverability and native Atlas client acceptance. No real recurring charge or email was sent during this local implementation. A Resend accepted response is not proof of inbox delivery.

## Delivery and authorization acceptance

The Worker suite includes delivery and checkout-security checks using real D1 migrations and transitions with isolated Stripe responses: full-amount manual capture, durable delivery evidence, original-account scoping, duplicate and changed retries, delivery/cancel races, lost capture/cancellation responses, release versus refund, least-privilege scopes, ownership/mode checks, mismatched amounts/customers/metadata, missing shipping, expired/unknown holds, processing, configuration gates, read-only reconciliation, interrupted outbox recovery, stale event snapshots and legacy policy preservation.

Actual Stripe test authorization/capture, 3DS and release passed in the September 9 acceptance. Connect parent configuration inheritance was verified in the sandbox on September 27. Issuer expiry and actual carrier/delivery-bot acceptance are still required. See the [delivery launch checklist](https://dashboard.atlaspay.sh/docs/delivery). No live charge, live release, production load test or soak test was performed for this change.

The production build and targeted lint passed. Desktop/mobile browser checks with isolated account/payment boundaries verified explicit hold consent, secure confirmation, authorized/delivered/processing/paid/canceled/expired/review labels, removal of repeat-pay controls while a payment is in progress, status-error recovery, no horizontal overflow, and matching Markdown copy/download. Mobile and desktop screenshots were visually inspected. The documentation/MCP suite and all 14 bot tests also passed.

## Load, soak & operational readiness

Run load tests against an isolated test environment, never a live merchant payment account. Measure request rate, error rate, p50/p95/p99 latency, D1 errors, callback queue age, retry counts, and Stripe rate-limit responses. Include a sustained soak and recovery from receiver outages. Agree on targets before the run; retain the duration, concurrency, test version, and raw results.

The callback worker currently attempts at most 20 deliveries each minute. That is a preview capacity limit, not a high-volume guarantee. Size delivery capacity and add monitoring/replay tooling before increasing merchant traffic.

## Live-launch gates

1.  For new installations, apply all migrations in order and deploy the Worker API, then publish the frontend docs and proxy. Configure the shared checkout context secret, wallet and delivery payment-method configurations and trusted delivery credentials, and the subscription portal/Resend settings before enabling subscription email. Do not enable the UI against an older backend.
2.  Register the required Stripe Connect snapshot events, including asynchronous checkout results, refund updates, `charge.refunded`, and `charge.dispute.created/updated/closed`. Verify signature secrets and scheduled delivery. The registration script updates the matching endpoint's event subscriptions; it is not run by the frontend build.
3.  Complete a published-site end-to-end test on each supported store platform. Reconcile order, processor payment, refund, and callback records.
4.  Confirm merchant-country eligibility and live Stripe Connect capabilities. Test-mode restrictions must be deliberately reviewed before changing configuration.
5.  Set up monitoring, support ownership, recovery procedures, and key-rotation reminders. Obtain marketplace approvals separately if distributing publicly.

---

Source: [Atlas Pay — Testing & launch](https://dashboard.atlaspay.sh/docs/testing)

Prepared by Kyle Campbell