@fantastic.dev/better-stripe 0.20.0 → 0.20.1

package/CHANGELOG.md

@@ -14,6 +14,12 @@
 - Remove internal tracker references from public documentation and add a
   regression check that prevents their reintroduction.
 
+## [0.20.1](https://github.com/FantasticDevHQ/better-stripe/compare/v0.20.0...v0.20.1) (2026-10-15)
+
+### Documentation
+
+- record live saved-card verification and sandbox setup ([#178](https://github.com/FantasticDevHQ/better-stripe/issues/178)) ([18d8b30](https://github.com/FantasticDevHQ/better-stripe/commit/18d8b30cd739c90e68508bd4d119297dc219da5c))
+
 ## [0.20.0](https://github.com/FantasticDevHQ/better-stripe/compare/v0.19.0...v0.20.0) (2026-10-15)
 
 ### Features

package/README.md

@@ -49,7 +49,7 @@ claim primitives alone do not enforce a minimum.
 
 ## Status
 
-**Version**: `0.20.0` <!-- x-release-please-version --> (pre-1.0). API may change between minor versions until 1.0.
+**Version**: `0.20.1` <!-- x-release-please-version --> (pre-1.0). API may change between minor versions until 1.0.
 
 Used in production by its authors. Webhook pipeline is covered by unit tests and a live E2E harness (`npm run e2e:webhooks`) that fires real Stripe-signed events and asserts the ledger.
 
@@ -1649,6 +1649,23 @@ Creation and browser confirmation are not settlement proof. Customer-account
 operations require Accounts v2 support in the sandbox or merchant account; the
 [customer preview guide](docs/accounts-v2-preview.md) explains eligibility.
 
+#### Live sandbox verification, 2026-10-15
+
+The public intent APIs and `SaveCard` passed real Stripe test-mode verification
+at commit `332d49c`, merged in [PR #166](https://github.com/FantasticDevHQ/better-stripe/pull/166).
+Browser 3DS failure, retry on the same SetupIntent, and successful authentication
+passed. A card saved for `off_session` use then succeeded on a later PaymentIntent;
+all successful test payments were refunded. Provider checks also covered customer
+ownership, redisplay permission, idempotent retries and declines.
+
+The initial `non_connect_platform_accounts_v2_access_blocked` error was resolved
+by enabling Connect in the intended Connect test sandbox. The browser flow used
+`2026-09-30.endive`; separate API checks also passed on `2026-09-30.preview`.
+This does not establish customer-only preview eligibility for another account.
+See the [sandbox setup findings](docs/accounts-v2-preview.md#connect-sandbox-setup-findings-2026-10-15),
+[authentication and reuse results](docs/react-workflows.md#live-authentication-and-reuse-results-2026-10-15),
+and [uploaded screenshots and provider records](https://github.com/FantasticDevHQ/better-stripe/pull/166#issuecomment-6185124292).
+
 ## Component history and currency summaries
 
 See the [read contract guide](docs/read-contracts.md) for reactive product, price and payout

package/docs/accounts-v2-preview.md

@@ -16,7 +16,7 @@ enable the account feature or extend BetterStripe's supported-version list.
 
 ## Enable the sandbox feature first
 
-In the intended sandbox, the account owner must enable **Reusable payment
+For a non-Connect merchant, the account owner must enable **Reusable payment
 methods for Global Payouts** under **Account previews and features**. If the toggle
 is unavailable or disabled, check account-owner permissions and request access
 using Stripe's form. A disabled toggle alone does not identify the cause. This also enables Stripe's
@@ -28,6 +28,44 @@ Accounts and changes how Stripe-hosted integrations create customers. Review
 Stripe's limitations and migration behavior before changing any live account.
 See [Stripe's customer Account guide](https://docs.stripe.com/accounts-v2/use-accounts-as-customers).
 
+## Connect sandbox setup findings, 2026-10-15
+
+Saved-card setup verification initially encountered
+`non_connect_platform_accounts_v2_access_blocked` while creating a
+customer-configured Account. Changing between the supported GA and preview
+request versions did not resolve the account eligibility block.
+
+For the Connect integration under test, enabling Connect in the existing
+standalone test sandbox resolved the block. We used Stripe CLI `1.53.1` and its
+`tools` plugin `0.15.0`. With an authenticated CLI profile for the intended
+sandbox, replace `YOUR_SANDBOX_PROFILE` with its profile name:
+
+```sh
+stripe --project-name YOUR_SANDBOX_PROFILE tools enable_connect --json
+```
+
+Confirm the profile points to the intended standalone sandbox before running it.
+The tool enables Connect in that sandbox and is idempotent. Its help states that
+live accounts and sandboxes controlled by another platform are not eligible.
+Inspect `stripe tools enable_connect --help` for the installed version's behavior.
+See Stripe's [sandbox guide](https://docs.stripe.com/sandboxes) and
+[Connect guide](https://docs.stripe.com/connect).
+
+After enablement, customer-account provisioning, SetupIntent authentication and
+later saved-card payments passed with test credentials. The browser flow used
+`2026-09-30.endive`; separate API checks passed on `2026-09-30.preview` in the
+same Connect-enabled sandbox. These results do not prove non-Connect preview
+eligibility. A merchant using customer-only Accounts must follow the preview
+setup above rather than enabling Connect merely to bypass the block. Neither
+BetterStripe nor a different request version enables Stripe account features.
+
+The [live verification evidence](https://github.com/FantasticDevHQ/better-stripe/pull/166#issuecomment-6185124292)
+contains screenshots and sanitized provider records. The
+[React guide](react-workflows.md#live-authentication-and-reuse-results-2026-10-15)
+records authentication and reuse outcomes. Successful test payments were refunded,
+unfinished intents canceled, saved test cards detached and fixture products/prices
+archived. No live account configuration or live payment was part of these checks.
+
 ## Configure one client and its webhook route
 
 ```ts

package/docs/react-workflows.md

@@ -609,6 +609,37 @@ Existing `AddCardForm` and `PaymentMethods` tokenization/attach integrations rem
 available. Tokenization plus attachment does not complete SetupIntent or SCA
 verification.
 
+### Live authentication and reuse results, 2026-10-15
+
+The public `SaveCard` workflow and `BetterStripe.createSetupIntent` /
+`BetterStripe.createPaymentIntent` methods were exercised against real Stripe.js
+and Stripe test APIs at commit `332d49c`, merged in
+[PR #166](https://github.com/FantasticDevHQ/better-stripe/pull/166).
+The Connect-enabled sandbox used `2026-09-30.endive` for browser confirmation.
+Separate API checks also passed on `2026-09-30.preview`.
+
+| Check                                                                | Observed result                                                                                                                                                                       |
+| -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Explicit consent and repeated provisioning with the same request key | Off-session setup accepted; retries returned the same intent.                                                                                                                         |
+| Card `4000000000003220`, failed 3DS challenge then retry             | A retryable authentication error appeared. Retrying the same SetupIntent and completing 3DS succeeded. Stripe SetupAttempts recorded both outcomes.                                   |
+| Card `4000002500003155`, setup then later off-session payment        | 3DS setup succeeded with `usage: "off_session"` and `allow_redisplay: "always"`. The saved method belonged to the expected V2 customer; the later payment succeeded and was refunded. |
+| Later off-session reuse of card ending `3220`                        | Stripe returned `authentication_required`. Successful setup does not guarantee every later payment can avoid authentication.                                                          |
+| API decline and payment retry checks                                 | Decline returned `card_declined` / `requires_payment_method`; same-key payment provisioning returned the same intent.                                                                 |
+
+Use these public test card numbers only in a Stripe test payment form, with a
+future expiration and test CVC. Use Stripe's test PaymentMethod IDs for API tests.
+See [Stripe's testing guide](https://docs.stripe.com/testing#regulatory-cards).
+
+[Uploaded screenshots and provider records](https://github.com/FantasticDevHQ/better-stripe/pull/166#issuecomment-6185124292)
+show the challenge, retryable failure and successful reuse. No continuous video
+was recorded. Test payments were refunded and disposable fixtures cleaned up.
+The test used a local ownership fixture for the host callback. It verifies package
+orchestration and actual provider authentication, not production application
+authentication, redirect-return recovery, webhook delivery or Dojo's saved-card UI.
+Consumer applications still need to verify their own authenticated adapters and saved-card UI.
+See [sandbox setup findings](accounts-v2-preview.md#connect-sandbox-setup-findings-2026-10-15)
+for the account eligibility requirement.
+
 ## Component history and currency summaries
 
 See the [read contract guide](read-contracts.md) for reactive product, price and payout

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fantastic.dev/better-stripe",
-  "version": "0.20.0",
+  "version": "0.20.1",
   "description": "A Convex component for Stripe V2 Accounts API integration.",
   "keywords": [
     "stripe",