#paul_subscription-testclock

1 messages ยท Page 1 of 1 (latest)

short scaffoldBOT
#

๐Ÿ‘‹ Welcome to your new thread!

โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

๐Ÿ”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1219790474450309212

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

frozen hamletBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

agile flame
#

paul_subscription-testclock

crude juniper
#

Hello

agile flame
#

๐Ÿ‘‹ Hey @crude juniper ! I understand you say you have no Event id but you must have something relevant I can use to help you such as an exact Subscription id, an exact Invoice id, etc. that explains what you are trying to do

crude juniper
#

sure

#

sub id

#

sub_1Ow8KUJ4ILijjURS4RZ9TouT & sub_1Ow8JmJ4ILijjURSOh1JJa87

agile flame
#

looking

crude juniper
#

Thanks!

agile flame
#

Okay so TestClocks can be tricky to grasp. So can you first explain exactly what you are doing and then what isn't happening and what you are seeing in the API?

crude juniper
#

Sure

#

My ultimate goal is to simulate a billing_reason where the value is subscriptino_cycle if I remember correctly. Then I created 2 subscriptions: one which is supposed to go through (used the 4242 card), and another one which is supposed to be declined (used the 4000) card. I looked at the requests log for my webhook, and not one clock triggered a request

agile flame
#

Okay sorry I'm going to be a bit nitpicky because I'm missing a lot of crucial information to help you right now. Let's ignore the webhook entirely for a sec.
The first step is to explain what you are doing to the Subscription exactly and then what the result is that is different from what you expect.

I'm a developer so I help with code-related questions. I assume you are doing a set of steps to end up in the state you want. But I'm seeing some Dashboard clicks on those and not sure I follow what you are doing end to end as the developer. Can you try and share your end to end reproduction script for example?

crude juniper
#

Well, repro for what exactly?

agile flame
#

For what you have been trying to do for a couple hours that you are stuck on

crude juniper
agile flame
#

for example the first Subscription you shared is associated with a TestClock that you seem to have created in the Dashboard and I don't see you advancing time

#

No TestClocks can be done fully in code, that's what I do. The Dashboard works fine too but it's important to understand what you are trying to do.
Give me a few minutes to write something

crude juniper
#

Sure

agile flame
#

My understanding is that you want to simulate a case where a future Invoice on a Subscription suddenly fails a payment after having previous Invoices working fine.

If so, here's what I'd do as a developer

  1. Create a TestClock set to say 2024-03-01 00:00:00 UTC
  2. Create a Customer on that TestClock
  3. Create a Subscription on that Customer with the pm_card_visa PaymentMethod so that it's paid successfully
  4. Advance the TestClock to 2024-04-02 00:00:00 UTC
  5. Wait for the time advancement to finish (write a for loop that polls).
  6. Confirm the latest Invoice for April 1st - May 1st is paid
  7. Update the Customer's default PaymentMethod to pm_card_chargeCustomerFail
  8. Advance the TestClock to 2024-05-02 00:00:00 UTC
  9. Wait for the time advancement to finish (write a for loop that polls).
  10. Confirm the most recent Invoice's payment failed
#

So first when you read all of this, does it make sense?

crude juniper
#

Only partly

#

what polls?

#

I thought stripe sends a request to my webhook

agile flame
#

You writing real code to do this. Can you read PHP code?

crude juniper
#

only python and node

#

unfortunately

agile flame
#

All good was just asking because I have end to end PHP scripts for this

#

But in node you write const testClock = await stripe.testHelpers.testClocks.advance( 'clock_1Mr3I22eZvKYlo2Ck0rgMqd7', { frozen_time: 1680199613, } ); to advance a TestClock right?

crude juniper
#

I'm not familiar with this API, but I can look it up

agile flame
#

Ah so you have been doing all of this by hand in the Dashboard?

crude juniper
#

Exactly

#

I have just re-read the docs for test clocks, and it's possible I misunderstood something

#

At the time T1 when I set the clock, does it have to be after the subscirption billing cycle or it can be any time where T1> T0+ 2 Hours (which is what I did )?

agile flame
#

it's kinda neither

#

Today is March 19. Let's say it's 16:54 for both of us (not sure where you live)

#

If I create a TestClock, by default it will be pinned to that exact time.

#

Now if you and I talk for 10 minutes, it will be March 19 17:04 at that point. But for the TestClock it is still March 19 16:54. And the Subscription that is associated with it is "stuck" at that exact second of the day.

#

What you can do is tell us "hey that TestClock, advance the time to April 2nd 15:43 please" and we will do that. and as we advance the time in our test environment for that TestClock we also look at all the objects in that TestClock and advance the time for those too one by one

#

So imagine you have a Subscription that is set to renew on May 1st at 00:00. Without a TestClock you'd have to wait 12 days to test this logic
With TestClock you tell us "advance the time please" and we pretend we're in the future

#

Not sure how clear this is to you

crude juniper
#

No, that was clear

agile flame
#

And so I think you forgot to "advance" the time

crude juniper
#

So, since the subscription ought to renew on May 1st at 00:00, I should advance the clock to that time

#

Okay, let me tell you how I've been trying to test this: Accept Payment with ECE -> create customer -> create subscription -> go in the Dashboard and click Run Simulation -> input the date the subscription would have to rebill the customer -> click advance time. Then, there is an Advance Time button that prompts me to again select a date.

#

Did I get that right?

agile flame
#

Yes but if I were you I would bypass all of those manual flows and do it with code end to end

crude juniper
#

Yes, it can get repetitive

#

But what's the deal with the Curent Time + 1 Hour?

agile flame
#

not entirely sure what you mean by that

crude juniper
#

Previously, I've been told I can just advance the clock to that time & the webhook will be touched (or I understood wrong?)

agile flame
#

I mean you can advance the TestClock to a certain time, and if that certain time is past the Subscription's current_period_end then it will trigger a new cycle yes

crude juniper
#

I've been told I can advance the clock to this DateTime + 1 Hour

#

I understand

#

Thanks a lot for your time, hope it's gonna work now!

agile flame
#

when testing I'd do one day not just one hour

#

but yes

crude juniper
#

Thanks, thats helpvul

#

Okay, now seems to work as expected

#

Although I'm not sure why the payment_succeeded didn't retry (my server's down so they both got a 404)

agile flame
#

you can click on each one and see their status

crude juniper
#

Yes, they all 404d'

agile flame
#

then it'll be retried, Events are retried async

crude juniper
#

Alright, got it

#

One more question if I may: are there any best practices when a payment fails?

#

Or should I just let stripe handleeverything through retries?

agile flame
#

There are a lot of things you can do so it depends a bit on various factors. We (Stripe) will retry automatically every X days (depends on various things) so letting us do things is a good idea.
Additionally we can send an email to the customer to come and change their card details for example which helps. You can also use the CustomerPortal

https://docs.stripe.com/billing/revenue-recovery/smart-retries is likely a good start

crude juniper
#

Thanks a lot for your time, will look into it!

agile flame
#

Happy to help ๐Ÿ™‚