Help us improve
Share bugs, ideas, or general feedback.
From stripe-test-mcp
Simulates Stripe subscription billing cycles using test clocks to verify renewals, recurring invoices, and correct charges in test mode.
npx claudepluginhub hideokamoto/stripe-testing-mcp-toolsHow this skill is triggered — by the user, by Claude, or both
Slash command
/stripe-test-mcp:stripe-billing-cycle-testThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Standard procedure for validating that a subscription bills correctly on its
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
Standard procedure for validating that a subscription bills correctly on its next cycle by simulating time with a Stripe test clock. All steps run against Stripe test mode only (the MCP rejects live keys).
The steps below are strictly ordered. A customer can be attached to a test clock only at creation time, so the clock must exist before the customer, and the customer before the subscription.
Create the test clock.
Tool: create_stripe_test_clock
frozen_time (required): Unix timestamp in seconds for the starting
time.name (optional): a label to find it later.test clock id for the next steps.Create a customer attached to that clock.
Tool: create_stripe_test_customers
test_clock: the id from step 1.number: keep it at most 3 (max 3 customers per clock).payment_method_id (optional but recommended): attach a test payment
method (for example pm_card_visa) so the renewal invoice can be paid
instead of staying open. Confirm against the Stripe docs which test
payment method fits the card behavior you want.Create the subscription.
Tool: create_stripe_test_subscription
customer: the id from step 2.items: array of { price, quantity }. The price must be a recurring
price id from your test data.proration_behavior (optional): create_prorations, none, or
always_invoice.payment_method_id (optional): the same test payment method.Advance the clock to the next billing date.
Tool: advance_stripe_test_clock
test_clock_id: the id from step 1.frozen_time: a Unix timestamp (seconds) after the current frozen
time. Advance is forward-only; you cannot move a clock backward. Pick a
time just past the subscription's current_period_end to cross the
renewal boundary.Wait for the clock to settle, then verify.
advance_stripe_test_clock reports the clock status once, in its
response text. Advancing is asynchronous. This MCP server does not
expose a tool to retrieve or re-poll the clock, so you cannot
programmatically watch it transition to ready.advancing, either wait a few seconds before
proceeding, or ask the user to confirm the clock has settled in the
Stripe Dashboard (test mode) before continuing.frozen_time is always a Unix timestamp in seconds (not milliseconds).metadata.generator = stripe-testing-tools-mcp. The MCP cannot search customers by this tag, but it helps you locate them in the Stripe Dashboard or CLI; record the returned ids for programmatic cleanup.stripe-test-data-lifecycle skill.stripe-test-clock-constraints skill.