---
title: "Testing subscriptions with Stripe Test Clocks and Workbench"
description: "Stripe subscriptions require testing scenarios that unfold across billing cycles, and the post presents Test Clocks and Workbench as no-additional-cost test-mode tools for doing so without waiting real time. It provisions three monthly recurring product tiers, creates a test clock with a Unix Epoch FrozenTime, and attaches newly created customers and subscriptions to that clock using the Stripe .NET SDK. Advancing the clock by one month updates time-dependent objects, allowing Workbench Inspector logs and events such as invoice.created and customer.subscription.updated to be examined alongside payment and subscription state. A second simulation attaches pm_card_chargeCustomerFail, makes it the default payment method, and advances to the next billing period. The resulting failed invoice, canceled subscription, and customer.subscription.deleted cancellation_details show how these tools reveal the events and properties an integration should test."
---

# Testing subscriptions with Stripe Test Clocks and Workbench

[Stripe](https://yomu.fyi/company/stripe) · Cecil Phillip · Oct 14, 2024

**Type:** Tutorial

## Summary

Stripe subscriptions require testing scenarios that unfold across billing cycles, and the post presents Test Clocks and Workbench as no-additional-cost test-mode tools for doing so without waiting real time. It provisions three monthly recurring product tiers, creates a test clock with a Unix Epoch FrozenTime, and attaches newly created customers and subscriptions to that clock using the Stripe .NET SDK. Advancing the clock by one month updates time-dependent objects, allowing Workbench Inspector logs and events such as invoice.created and customer.subscription.updated to be examined alongside payment and subscription state. A second simulation attaches pm\_card\_chargeCustomerFail, makes it the default payment method, and advances to the next billing period. The resulting failed invoice, canceled subscription, and customer.subscription.deleted cancellation\_details show how these tools reveal the events and properties an integration should test.

## Context

Recurring subscription billing cycles can span weeks or months, making time-dependent behavior difficult to trigger on demand and observe during integration validation.

## Approach / What changed

Use Stripe Test Clocks in test mode to advance customer and subscription state to selected future dates, then use Workbench to inspect logs, events, errors, and object properties. The examples create clocks, customers, and subscriptions with the Stripe .NET SDK, then simulate both successful and failed monthly payments.

## Takeaways

- A test clock is created with a name and Unix Epoch FrozenTime, can move only forward after creation, and must be attached to newly created customers for the simulation.
- Advancing a clock by one month can produce billing events including invoice.created and customer.subscription.updated, while Workbench exposes the associated activity and event properties.
- Using pm\_card\_chargeCustomerFail as the default payment method produces a failed invoice and canceled subscription; customer.subscription.deleted cancellation\_details identifies inability to collect payment.

**Tags:** [Monitoring](https://yomu.fyi/topic/monitoring), [Reliability](https://yomu.fyi/topic/reliability), [Testing](https://yomu.fyi/topic/testing)

- Source: [Stripe](https://stripe.dev/blog/testing-subscriptions-with-stripe-test-clocks-and-workbench)
- Source URL: https://stripe.dev/blog/testing-subscriptions-with-stripe-test-clocks-and-workbench
- Ingested by Yomu: 2026-08-28T08:56:31.094Z

[Read original post](https://stripe.dev/blog/testing-subscriptions-with-stripe-test-clocks-and-workbench)