Testland
Browse all skills & agents

stripe-subscription-billing-test-author

Builds test suites for Stripe recurring-billing flows: trial-to-paid conversion, proration on plan upgrade and downgrade, dunning on failed renewal, cancel and reactivation, and the full subscription webhook event matrix (invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted, invoice.paid). Uses Stripe Billing test clocks (POST /v1/test_helpers/test_clocks) to time-travel through billing cycles without calendar delay. Distinct from stripe-test-cards-and-webhooks (one-time PaymentIntents) and payment-flow-test-author (idempotency + replay robustness). Does not cover single-event CLI replay or handler idempotency testing (see payment-flow-test-author for those). Use when authoring tests for subscription or recurring-billing integrations.

Install with skills.sh (any agent)

npx skills add testland/qa --skill stripe-subscription-billing-test-author
View source

stripe-subscription-billing-test-author

Overview

Subscription billing is distinct from one-time payments. A customer's card is charged on a schedule, trials expire, plans change mid-cycle, and payments fail weeks after signup. Per docs.stripe.com/billing/testing (opens in new window), Stripe's sandbox is feature-complete for billing objects: subscriptions, invoices, trials, and retry schedules all work against test data.

The key tool for deterministic subscription testing is the Stripe Billing test clock, which lets you fast-forward a frozen simulation through days, weeks, or months without waiting. Per docs.stripe.com/api/test_clocks (opens in new window), a test clock is created at a frozen_time and advanced with POST /v1/test_helpers/test_clocks/{id}/advance, triggering all billing events that would have fired in the elapsed interval.

This skill walks through five recurring-billing scenarios end to end.

Lifecycle states to test

Per docs.stripe.com/billing/subscriptions/overview (opens in new window), subscriptions move through:

StateMeaning
trialingTrial active; no payment collected yet
activeGood standing; payment collected
past_dueLatest invoice unpaid; smart retries running
unpaidRetries exhausted; access decision pending
canceledTerminal; billing stopped
pausedTrial ended without payment method attached

Each transition fires one or more webhook events. Tests must assert both the subscription status and the correct event sequence.

Step 1 - Create a test clock

Per docs.stripe.com/api/test_clocks (opens in new window), create a test clock frozen at a known epoch before creating any billing objects:

const clock = await stripe.testHelpers.testClocks.create({
  frozen_time: Math.floor(new Date('2025-01-01T00:00:00Z').getTime() / 1000),
  name: 'billing-suite-run',
});

Attach the customer to the clock at creation time:

const customer = await stripe.customers.create({
  email: 'tester@example.com',
  test_clock: clock.id,
  payment_method: 'pm_card_visa',  // 4242 4242 4242 4242
  invoice_settings: { default_payment_method: 'pm_card_visa' },
});

Advance time with:

await stripe.testHelpers.testClocks.advance(clock.id, {
  advances_to: Math.floor(new Date('2025-01-08T00:00:00Z').getTime() / 1000),
});
// Poll until clock.status === 'ready' before asserting

Always poll GET /v1/test_helpers/test_clocks/{id} until status is ready before asserting subscription state; events are asynchronous.

Step 2 - Trial-to-paid conversion

Per docs.stripe.com/billing/testing (opens in new window), the recommended flow:

// Freeze clock at Jan 1
const sub = await stripe.subscriptions.create({
  customer: customer.id,
  items: [{ price: PRICE_ID }],
  trial_end: Math.floor(new Date('2025-01-08T00:00:00Z').getTime() / 1000),
});
expect(sub.status).toBe('trialing');

// Advance to Day 5 - trial_will_end fires 3 days before trial ends
await stripe.testHelpers.testClocks.advance(clock.id, {
  advances_to: toEpoch('2025-01-05'),
});
await waitForClockReady(clock.id);
// Assert: customer.subscription.trial_will_end webhook fired

// Advance past trial end (Day 8)
await stripe.testHelpers.testClocks.advance(clock.id, {
  advances_to: toEpoch('2025-01-09'),
});
await waitForClockReady(clock.id);

const updated = await stripe.subscriptions.retrieve(sub.id);
expect(updated.status).toBe('active');

Webhook events to assert per docs.stripe.com/billing/testing (opens in new window):

Clock positionEvent
Day 5customer.subscription.trial_will_end
Day 8invoice.created, invoice.finalized, invoice.paid
Day 8customer.subscription.updated (status: trialing -> active)

Step 3 - Proration on upgrade/downgrade

Per docs.stripe.com/billing/subscriptions/prorations (opens in new window), a mid-cycle plan change generates a credit for unused time on the old price and a charge for remaining time on the new price. Preview before applying:

const prorationDate = Math.floor(Date.now() / 1000);

// Preview the upcoming invoice to verify proration amounts
const preview = await stripe.invoices.createPreview({
  customer: customer.id,
  subscription: sub.id,
  subscription_details: {
    items: [{ id: sub.items.data[0].id, price: NEW_PRICE_ID }],
    proration_date: prorationDate,
  },
});

// Verify credit (negative) and debit (positive) line items exist
const credit = preview.lines.data.find(l => l.amount < 0);
const debit  = preview.lines.data.find(l => l.amount > 0);
expect(credit).toBeTruthy();
expect(debit).toBeTruthy();

// Apply at the same proration_date to lock the amounts
await stripe.subscriptions.update(sub.id, {
  items: [{ id: sub.items.data[0].id, price: NEW_PRICE_ID }],
  proration_date: prorationDate,
  proration_behavior: 'create_prorations',  // default
});

Per docs.stripe.com/billing/subscriptions/prorations (opens in new window), proration_behavior options are:

ValueEffect
create_prorationsCreates proration items; billed on next invoice (default)
always_invoiceCreates proration items AND immediately invoices
noneNo proration; full new price on next cycle

Downgrade test: pass a lower-priced plan as NEW_PRICE_ID and assert the credit line item is larger than the debit line item.

Step 4 - Dunning on failed renewal

Per docs.stripe.com/billing/testing (opens in new window), use test card 4000 0000 0000 0341 to trigger payment failure on an active subscription. Per docs.stripe.com/billing/revenue-recovery/smart-retries (opens in new window), Smart Retries can be configured for up to 8 attempts within a 2-month window; invoice.payment_failed fires on each failed attempt with attempt_count and next_payment_attempt fields.

// Attach a card that will decline on recurring collection
const failMethod = await stripe.paymentMethods.attach('pm_card_chargeDeclinedInsufficientFunds', {
  customer: customer.id,
});
await stripe.customers.update(customer.id, {
  invoice_settings: { default_payment_method: failMethod.id },
});

// Advance past the renewal date
await stripe.testHelpers.testClocks.advance(clock.id, {
  advances_to: toEpoch('2025-02-02'),  // One day past renewal
});
await waitForClockReady(clock.id);

const invoice = await getLatestInvoice(sub.id);
expect(invoice.status).toBe('open');

const sub2 = await stripe.subscriptions.retrieve(sub.id);
expect(sub2.status).toBe('past_due');
// Assert invoice.payment_failed was received with attempt_count >= 1

Webhook sequence on failed renewal:

EventKey field to assert
invoice.payment_failedattempt_count, next_payment_attempt
customer.subscription.updatedstatus: past_due

Test recovery: attach a valid payment method, then call stripe.invoices.pay(invoice.id) and assert invoice.paid fires and subscription returns to active.

Step 5 - Cancel and reactivation

// Cancel at period end (access persists until billing cycle closes)
await stripe.subscriptions.update(sub.id, { cancel_at_period_end: true });
const canceling = await stripe.subscriptions.retrieve(sub.id);
expect(canceling.cancel_at_period_end).toBe(true);

// Advance past period end
await stripe.testHelpers.testClocks.advance(clock.id, {
  advances_to: toEpoch('2025-02-02'),
});
await waitForClockReady(clock.id);

const canceled = await stripe.subscriptions.retrieve(sub.id);
expect(canceled.status).toBe('canceled');
// Assert: customer.subscription.deleted webhook fired

// Reactivation: create a new subscription (canceled is terminal)
const reactivated = await stripe.subscriptions.create({
  customer: customer.id,
  items: [{ price: PRICE_ID }],
});
expect(reactivated.status).toBe('active');

Per docs.stripe.com/billing/subscriptions/overview (opens in new window), canceled is a terminal state; reactivation means creating a fresh subscription, not updating the canceled one.

Step 6 - Webhook event matrix

Per docs.stripe.com/billing/testing (opens in new window), the full set of events your handler must process:

EventTriggerRequired handler action
customer.subscription.createdNew subscriptionRecord subscription ID + status
customer.subscription.trial_will_end3 days before trial endNotify customer
customer.subscription.updatedAny status or plan changeSync local subscription record
customer.subscription.deletedCancellation takes effectRevoke access
invoice.createdInvoice generated at renewalFinalize within 72 hours
invoice.finalizedInvoice ready for collectionLog for audit
invoice.paidPayment succeededProvision or extend access
invoice.payment_failedPayment attempt failedNotify customer; track attempt_count
invoice.payment_action_required3DS required on renewalPrompt re-authentication

Trigger these in CI using the Stripe CLI:

stripe trigger invoice.payment_failed
stripe trigger customer.subscription.updated

Per docs.stripe.com/stripe-cli (opens in new window), forward webhook events to a local handler during development:

stripe listen --forward-to http://localhost:3000/webhooks/stripe

Running

npm test -- --testPathPattern=billing

For integration tests that drive test clocks:

STRIPE_TEST_KEY=sk_test_... npm test -- --testPathPattern=billing/integration

CI integration

jobs:
  billing-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
      - run: npm ci && npm test -- --testPathPattern=billing
        env:
          STRIPE_TEST_KEY: ${{ secrets.STRIPE_TEST_KEY }}
          STRIPE_WEBHOOK_SECRET: ${{ secrets.STRIPE_WEBHOOK_SECRET }}

Test-clock tests do not require stripe listen because they drive the Stripe API directly without local webhook forwarding. Signature verification tests do need STRIPE_WEBHOOK_SECRET.

Anti-patterns

Anti-patternWhy it failsFix
setTimeout to wait for trial endFlaky and slow in CIUse test clock + waitForClockReady
Asserting subscription state before clock is readyRace condition; events not yet firedPoll GET /v1/test_helpers/test_clocks/{id}
Reusing a test clock customer across test casesShared state leaks between scenariosCreate a fresh clock + customer per scenario
Canceling and immediately reusing as activecanceled is terminalCreate a new subscription for reactivation
Skipping invoice.paid handlerAccess provisioned on subscription create, not paymentProvision only after invoice.paid
Omitting proration_date from preview AND update callsTiming skew makes amounts disagreeUse the same epoch timestamp for both
Testing only invoice.payment_failed onceSmart Retries fires multiple times with growing attempt_countTest at least two retry cycles

Limitations

References

Related skills

payment-flow-states-reference

Pure-reference catalog of payment lifecycle state machines across Stripe, Adyen, PayPal, and Braintree: canonical states (created / requires_action / processing / succeeded / requires_capture / canceled / failed), authorisation vs capture, asynchronous webhook states, refund / dispute / chargeback transitions, and the 3-D Secure (EMVCo 3DS 2.x) frictionless / challenge flow paths with per-gateway 3DS test cards (references/3ds-flows.md). Use when designing tests for payment flows, auditing state-handling code, or covering a 3DS round-trip; this is the state model, not a builder - to author suites on it use payment-flow-test-author (refunds, disputes, webhook replay).

payment-flow-test-author

Build-an-X workflow that authors the full payment-flow test suite in three phases: the refund matrix (full / partial / multiple-partials / over-refund / already-refunded, per-gateway APIs for Stripe, Adyen, PayPal, Braintree), the chargeback / dispute suite (Visa + Mastercard reason codes, evidence submission windows, won / lost / accepted dispositions), and webhook replay + recovery via gateway-native simulators (Stripe CLI trigger / resend, Adyen Customer Area resend, PayPal Webhook Simulator, Braintree sampleNotification). Driven by the state model in payment-flow-states-reference. Use when building refund, dispute, or payment-webhook-robustness coverage for a payment integration; for generic (non-payment) webhook receiver testing use webhook-delivery-tester in the qa-notifications plugin.

payment-gateway-sandboxes

Wraps the vendor-generic payment-gateway sandbox pattern - test credentials, sandbox base URLs / environment switches, deterministic test-card matrices, and gateway-native webhook simulators - with per-gateway references for Adyen test mode, PayPal Sandbox, and Braintree sandbox. Use when testing code integrated with Adyen, PayPal, or Braintree; for Stripe use stripe-test-cards-and-webhooks (one-time payments) or stripe-subscription-billing-test-author (recurring billing).

stripe-test-cards-and-webhooks

Wraps Stripe API testing patterns: test-mode initialization, the canonical test cards (4242 success; 4000 0000 0000 0002 declined; 4000 0027 6000 3184 3DS challenge per the 3DS flows reference in payment-flow-states-reference), the Stripe CLI webhook flow (`stripe listen --forward-to`), the Stripe CLI fixture commands (`stripe trigger payment_intent.succeeded`), and the webhook signature verification (Stripe-Signature header + HMAC-SHA256). Use when testing Stripe-integrated code.