Test subscription lifecycles with test clocks
HTML-код
- Опубликовано: 4 июл 2024
- In this episode, you'll learn how to move objects through time in test mode.
Test clocks make it easier to test your Billing integration and make sure it behaves as designed. When you use test clocks you simulate the forward movement of time in test mode, which causes resources, like Subscriptions, to change state and trigger webhook events. This means that, e.g., you don’t have to wait a year to see how your integration handles a payment failure for a quarterly or annual renewal.
Presenter
CJ Avilla - Developer Advocate at Stripe - / cjav_dev
Resources
API Reference: stripe.com/docs/api/test_clocks
Documentation: stripe.com/docs/billing/testi...
Table of contents
00:00 Introduction
00:58 Create a new test clock
01:46 Attach the test clock to a customer
03:05 Create a subscription
03:58 Advance a subscription in time
06:02 Test a future subscription cancellation
06:24 Delete a test clock
06:41 Recap
Support
If you have a question, please feel free to reach out to our support team on Discord at stripe.com/go/developer-chat
Updates
Sign up to stay updated with developer news: go.stripe.global/dev-digest
Feedback
If you have any feedback about this or other episodes, let us know: forms.gle/VjNqzRhotM2snYo88
#Stripe #Payments
I love stripe API, very well done!
This is great for long testing sessions
Why can't we just stimulate time with existing subscriptions? Like 'stimulate when payment failed' etc. Takes a lot of confusion/burden off.
I don't see how this helps test my integration, since I can't attach it to existing objects. This just seems to test Stripes ability to charge cards and renew subscriptions.
Great idea but I wonder if it could improve a bit - unless I got it completely wrong. But I wonder if, in the future, we could associate an existing customer/subscription to the clock . To test webhooks properly, I want to simulate going forward of an existing subscritpion - with discounts, without discounts, at the end of the coupon, etc... Can I still do this with the current system?
Hey Sofia! Thanks for watching. Support for attaching test clocks to existing objects is something we’d like to add. No news to share, yet. Thanks for the valuable feedback!
@@cjav_dev We are still waiting for this feature. It will ease our development effort. We are changing webhook post values manually and posting them back to our endpoint which is extra work and not reliable as advancing clock.
yeah I'm definitely missing something, I don't see how this is even helpful unless I could attach it to existing customers. Otherwise, I'm just testing Stripes ability to do Stripe things, and it has nothing to do with my integration
Hi Hector-you can go through this page stripe.com/docs/testing where you can learn how to simulate payments and test out various scenarios in test mode.
How to simulate when payment failed ?
Very useful to see the test clocks created via the endpoints rather than the dashboard. I did notice that using test clocks to simulate failed payments ('Send emails to customers to update failed card payment methods' in Settings->Subscriptions and emails in the dashboard) resulted in no emails being sent even when the test payments show up as failed in the dashboard. Do test clocks only trigger webhook events but not Stripe email notifications?
Hey there! 👋 Yes in test mode webhook events are triggered but not email notifications. Email notifications are only triggered in live mode.
I tried it but it seems to me that webhooks events are not triggered....I mean I set up a simulation with a daily subscription with the frozen time set to current date time. Then I set up 2 webhooks listeners in my app: one for the subscription update event, another for the subscription deleted event. I updated by an api call the subscription to set to be canceled at the end of the (billed) period. This action correctly triggered a subscription update webhook event. I finally moved forward the frozen time of just a little bit more than one day. The subscription turned its status to "canceled" but no webhook event was fired...do you know why? I expected both the subscription update and deleted, instead I received nothing....
How to test the payment failure using stripe test clock ?
Hi there-when you use test clocks, you simulate the forward movement causing Billing resources, like Subscriptions, to change state and trigger webhook events. By doing this you can see how your integration handles a payment failure. For more, please see here: stripe.com/docs/billing/testing/test-clocks#setup-simulation.
@@StripeDev But the test clocks from stripe dashboard does not let me add the "Card Declined" case card as payment method.
Can you email us at support@stripe.com with more on your integration so we can better understand how you are using these features? We can offer further support on this there! Thanks.
Is it possible to reduce first billing cycle price when creating a stripe recurring price?
Only 2 intervals is horrible. I'm trying to test renewal (1st interval), failed renewal(2nd interval), grace period with past_due of 7 days and transition to cancelled after. I cant have all tests in one go, have to split them to be able to test past due... horrible constraint. It should be at least 3 intervals, 6 or 10 would be better.
Is it possible to make changes to resources (eg. update subscription) after advancing the clock and then advancing the clock again ?
Hi there. You can follow these steps:
1. Created a subscription with a test clock
2. Advanced the clock
3. Updated the subscription
4. Advanced the clock again
Let us know if it worked!
@@StripeDev Following these steps I keep getting the error: StripeRateLimitError with message "Test clock advancement underway - cannot perform modifications" whenever I try to modify (update/delete) a subscription after the first clock advancement.
When advancing a clock, the `status´ of the clock will be set to `advancing´ as explained here: stripe.com/docs/api/test_clocks/advance
You need to wait for the status to be ready before making changes to the subscription.
To know when the status becomes ready, you could listen to the webhook event `test_helpers.test_clock.ready´or poll the clock status: stripe.com/docs/billing/testing/test-clocks#monitor-changes
If you are only running a quick test, a more straightforward approach (but less robust) would be to simply add a few seconds delay before updating the subscription to give the time to the clock to move to the ready status.
@@StripeDev Worked like a charm, thanks! Both great feature and video btw :)
Great news and thank you for the feedback!
the idea is good but execusion is 0, and its 101% useless unless you link it to an existing subscriptions, we run e2e tests and it make sense to link it to running test-subscription that are linked to a running app, not to manually waste the time....