## TL;DR

Stripe test clocks let you fast-forward time for test customers so trials end, invoices finalize, and renewals fire on demand. Create a test clock, attach the customer with frozen time, then advance the clock past trial_end or the invoice date. Webhooks fire as if real time passed, so your dunning, provisioning, and proration logic gets exercised. Delete the clock when done; test-clock customers cannot move to live mode, so keep them quarantined in test flows.

## The query

```text
Stripe test clocks: simulating trial end and invoice finalization
```

## Use this when

- Testing trial-to-paid conversion without waiting weeks
- Simulating invoice finalization and renewal webhooks
- End-to-end billing flow tests in Stripe test mode

## Not for

- Production billing behavior (test clocks are test mode only)
- Load or performance testing (use a different harness)

## Steps

1. Create a test clock with the current time frozen and attach your test customer to it.
   Expected output: The customer is pinned to the clock's time.
2. Create the subscription with a trial on that customer.
   Expected output: The trial runs on clock time, not wall time.
3. Advance the clock past trial_end and watch invoice.created, invoice.finalized, and payment events fire.
   Expected output: Your handlers run exactly as they would in production.
4. Advance again to simulate renewals, dunning retries, and proration boundaries.
   Expected output: Multi-cycle behavior is verified in minutes.
5. Delete the test clock and its customers when the test run finishes.
   Expected output: No frozen-time customers leak into other tests.

## Variant phrasings

### Stripe test clock simulate trial end

### fast forward time Stripe billing test

### Stripe test clock invoice finalized

## Root cause

Test clocks virtualize time per customer because billing logic is time-driven and waiting 30 days per test cycle does not scale. Advancing the clock replays the same state machine production uses, so the coverage is faithful.

## Edge cases

- A customer can only be on one clock; plan test isolation accordingly
- Clocks advance forward only, and large jumps can trigger many events at once; advance in stages

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gVwNSxlbfvNIKAQFPUdTjQ