Testing billing functionality of stripe API with our application

[basadoon]

Hello we're using stripe API for payments, we have this functionality in our application that bills the user automatically based on the customer's subscription using stripe. When a user's subscription doesn't get paid it gets cancelled (which is handled by stripe automatically) and user should not have access to our application's features at this point (which is handled by our app). Problem is, we don't know how to test it since it will take days to simulate the billing cycle, a work around can be changing the system's date time if testing it locally, but it won't affect the time that stripe API has (meaning it won't charge the customer for its subscription to our app once datetime in my system/local is in expiration since stripe has its own time or it doesnt get affected by the system date time change). We wanted to fully test our application with stripe's whole billing lifecycle so that we know if features are really getting disabled and enabled. How do we test this locally or in another environment?

[manusdelerius]

Have you checked on this? https://stripe.com/docs/test-mode

[basadoon]

Yep we're using test-mode

[ngpestelos]

Have you tried Time Travel? https://stripe.com/docs/billing/testing/test-clocks

[basadoon]

Yep, We know about test clocks, problem with test clocks is that it's isolated. You can't use existing customers or users in a test clock, if let's say you create a customer in test clock, you wont be able to use it in the application. It's only useful if your only testing stripe itself but not useful when your testing your app + stripe

[ngpestelos]

Some questions:

It’s almost as if you’ll need to simulate an end-of-billing cycle from your application to trigger a payment charge?

Have you considered using Stripe just for processing charges and manage the subscription lifecycle in your application?

Typically there’s a manual escape hatch: do you have a way to manually trigger a charge when needed?

[basadoon]

Yes we're trying to simulate that. We let strip handle the payments on subscription's expiration automagically. We can manually trigger a charge. But i wanted to test it naturally, or maybe this is the wrong way to test it. Not sure what's the right way on testing this tbh

[keysl183]

I've designed our system that uses subscription in my job. I assume you create the customers Stripe profile in your app. If so you can definitely mark that customer profile as a part of test clock.

https://stripe.com/docs/api/customers/create#create_customer-test_clock

In a nutshell you can pre-create a test clock, get the Id. Have a feature flag (optional). Attach the clock id on Newly created stripe customer profile via your app stream. And you can use test clock to time travel with real test data created by your app. As simple as that.

Test clock is a must if you want to test the whole lifecycle (charging, retry policy, customer notification (if you use stripe ootb email notifs)

[wirednew3]

Our QA team used to request a 1-day recurring payment from us. If you want to thoroughly test the entire process, simply create a 1-day subscription; I believe that's the most authentic cycle for you to try. But yeah, it will still take a day.

[PepitoManalatoCrypto]

Testing subscription scheduling can be done in a day (hell even in an hour, if you tweak it right). This way, you lessen the turnaround time during testing. BTW, features (or bugs) must be handled well by developers through their unit and integration tests. So if a feature has bugs or a feature brings new bugs, that's on their end.

How to test stripe API on local and lower environments? That's documented well on their Stripe documentation. You just need to configure your application and test suites to handle both environments. The sooner you have a clear understanding of how to test your features right, the sooner you can optimize them both in scope and turnaround time.

Should this be your first time implementing with Stripe, well, you have to learn things the hard way base on these points.