Try → Scenarios
22 scripted demos covering shopper, merchant, and support flows. Each scenario maps to BRD (Business Requirements Document, our product spec) acceptance criteria and shows per-surface readiness. Every "open" link is labelled by fidelity — live app, recorded walkthrough, or design mockup — so you always know what you're opening.
Live/prototype links open behind the shared preview password (bc-blueprint).
Shopper flows
6
scenarios
Merchant setup
8
scenarios
Merchant ops
6
scenarios
Support ops
2
scenarios
gift-subscription
US-6.1Shopper buys a subscription as a gift; recipient claims via email link and the subscription is created against their account, not the buyer's.
Expected: Recipient receives email with claim link; clicking it creates the subscription against the recipient's customer record. First charge is deferred until recipient claims.
pause-resume
US-18.3 · US-10.5Customer pauses an active subscription (with or without a resume date). Auto-resume cron fires when the resume date arrives; manual resume snaps the next charge to the original anchor day.
Expected: Pause clears the upcoming charge; if a resume date is set, the cron flips the subscription back to active at 00:00 UTC on that date. Manual resume reschedules the next charge for the original day-of-month anchor.
free-trial
US-5.5Subscription configured with a trial period; first charge is suppressed until trial end. Cancellation during trial creates no charge.
Expected: Subscription created with status='trialing'; first charge scheduled for trial_end_at. Cancellation before trial_end results in zero charges; if the stored PM is invalid at trial-end, dunning kicks off.
update-payment-method
US-19.1 · US-19.6Self-serve PM update via the customer portal. Per-subscription or apply-to-all options.
Expected: New payment method tokenized via BC's stored-instruments vault; subscription's payment_method_id is updated atomically. 'Apply to all subscriptions' updates the customer's full subscription list atomically.
portal-magic-link-auth
US-17.1 · US-17.2 · US-17.4Customer requests a passwordless magic link from the storefront login page. The link mints a portal session JWT; the subscriber lands directly on their subscription detail page with no BC account password required.
Expected: Customer receives a time-limited magic link. Clicking it creates a portal session and redirects to /portal/subscriptions/:id with pause, skip, and payment-method actions available.
dsar-consent
US-28.1 · US-28.2 · US-28.3Customer opts out of marketing consent or requests full erasure of their subscription data. The Worker logs the request to an immutable audit trail, cancels active subscriptions, and retains charge records for the legally required period, then confirms receipt.
Expected: Consent or erasure request lands in the immutable audit log within 200ms. Erasure cascade cancels active subscriptions, marks the customer record deleted, and retains charge rows under a legal 7-year hold — all in one atomic transaction.
app-onboarding
US-1.1 · US-1.5First-touch experience for a merchant who's just installed bc-subscriptions. Welcome screen, setup checklist, and registration health check.
Expected: Merchant completes the checklist; app reports healthy registration with all required scopes granted. Subscription products can now be enabled.
processor-onboarding
US-2.1 · US-2.2 · US-2.7Merchant lands on Settings → Payment after install and connects either Stripe (by key entry) or BC Payments (one-click auto-detect). The Setup Checklist item flips from pending to active once a connection is established. Capture timing preference is also set here.
Expected: Processor connection row appears in the Connected processors panel with an 'active' badge. Setup Checklist item processor_connected flips from pending (red) to complete (green). Capture timing preference is persisted.
plan-copy
US-4.5Merchant on the plan-edit page picks 'Copy to products', selects one or more target products via multi-select, and runs the copy. Conflict detection flags target products that already have a same-interval plan; the merchant decides per-product to overwrite or skip.
Expected: Copy operation creates one new plan row per non-conflicting target product, mirroring the source plan's interval, pricing, options, and eligibility config. Conflicting targets are reported with the existing-plan id so the merchant can resolve manually.
deactivation-flow
US-4.4Merchant clicks 'Deactivate plan' on a product's plan panel; modal presents three radio choices — stop new signups, end all subscribers at next cycle, cancel all subscribers immediately. Each choice has distinct customer-impact semantics; merchant confirms after reading the impact summary.
Expected: Selected deactivation choice runs to completion: stop_new flips the plan to refuse new signups (existing subscribers untouched); end_at_next_cycle marks the plan paused and clears next-charge dates on all subscriptions; cancel_immediately atomically cancels every subscription and audit-logs each. NOTE: only stop_new calls a real backend (pausePlan) today; end_at_next_cycle and cancel_immediately are visual-only placeholders pending backend implementation — Demo Scene 6 instructs operators to hover-only, not click, on the stubbed choices.
enable-subscriptions-on-product
US-4.1 · US-5.1Merchant picks an existing BC product, opens the subscription panel, and configures one or more billing intervals + pricing rules. After save, the product is shoppable as a subscription.
Expected: Product appears in storefront with subscription widget rendered on the PDP. Shopper can pick subscribe-once vs subscribe-and-save.
plan-design
US-5.2 · US-5.4Merchant configures pricing strategy (fixed vs catalog-follow), available intervals (weekly / monthly / quarterly), and how plans compare in the storefront UI.
Expected: Pricing strategy applied across the merchant's subscription catalog. Storefront PDP renders the comparison view if multi-plan; single-plan products show the simpler subscribe CTA.
eligibility-rules
US-4.3 · US-26.2 · US-26.10Rules engine determines which products / variants are subscribable: by category, by custom field, by explicit include/exclude lists. Storefront widget hides on ineligible products automatically.
Expected: Rules saved and enforced. Audit tool shows which products are eligible / ineligible and why. Widget hides on ineligible products with no shopper-visible error.
storefront-widget-config
US-8.4 · US-8.5Widget colors, CSS variables, copy A/B variants, and which BC theme regions to render in.
Expected: Widget renders with merchant-chosen colors / copy variants. CSS variables make it themable without code changes.
merchant-dashboard
US-21.1Single-pane-of-glass for the merchant: active sub count, MRR, dunning queue size, exception queue size, top-of-funnel trends.
Expected: Merchant sees state-of-business in <10s. Clickable cards drill into the relevant detail surface (sub list, exception queue, dunning queue).
exception-queue
US-21.3Out-of-stock, invalid-plan, order-creation-failure, chargeback — all surface as exceptions the merchant resolves manually.
Expected: Exceptions grouped by type + severity. Merchant clicks into an exception, sees full context (subscription, customer, error), and marks resolved with a reason code.
subscription-list-bulk
US-21.4 · US-21.5 · US-22.4Merchant searches/filters the subscription list (by status, customer, product, date range), shares filtered URLs to teammates, and runs bulk actions (skip / pause / cancel) on selected sets.
Expected: Filter URL is shareable + reproducible. Bulk action runs against the filtered set with a confirmation modal; all actions audit-logged.
dunning-policy
US-11.1 · US-11.7Configure how many retry attempts, the cadence between retries, when to send emails, and the terminal action (cancel vs leave-past-due).
Expected: Policy saved; new charge failures follow the new retry cadence. Existing in-flight dunning runs aren't disrupted.
subscription-charge-flow
US-10.1 · US-10.2 · US-10.3 · US-10.5 · US-10.6End-to-end view of one charge cycle as the merchant experiences it: an active subscription's next_charge_at is reached, the scheduler picks it up on its 5-minute tick, the charge fires through the connected processor with an idempotency key, and the upcoming-charges view recomputes from the anchor date. Pause shifts the entire schedule; resume snaps back to the original anchor.
Expected: Scheduler tick fires within 5 minutes of next_charge_at; the charge transitions processing → succeeded; the subscription's next_charge_at is recomputed from the anchor date (no month-end drift); the upcoming-5-charges view reflects the new schedule. Pause shifts every upcoming row by the pause duration; resume restores the original anchor cadence.
notification-templates
US-23.1 · US-23.2Customize the transactional emails customers receive (subscription created, charge succeeded, payment failed, etc.). Template editor + variable substitution + preview.
Expected: Templates saved with substitutions like {{ customer.first_name }} and {{ subscription.next_charge_at }}. Preview shows realistic rendered output. Send-test feature delivers to a chosen address.
merchant-manual-subscription-create
US-22.1Support agent creates a subscription on behalf of a customer who called in. Subscription is created against the customer's existing stored payment method; immediate first charge is opt-in.
Expected: Subscription created against the chosen customer + product + plan; admin can optionally charge first interval immediately or wait for the scheduled date.
cs-impersonate
US-22.3 · US-22.5 · US-22.6CS agent opens an impersonation session to see the exact portal experience the customer sees — without touching the customer's credentials. Every action the agent takes is tagged with their operator_id in the immutable audit log.
Expected: Agent sees the subscriber portal as the customer, with a visible support-session banner. All writes are tagged operator_id=agent in the audit log, not the customer. Session expires after 30 minutes of inactivity.
Source: apps/demos/scenarios.json — read natively at build time; the per-surface readiness and demo links above come straight from it.