#madmark_subscription-multiple-udates

1 messages · Page 1 of 1 (latest)

compact viperBOT
storm jasperBOT
#

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.

compact viperBOT
#

👋 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/1216768475826225164

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

storm jasperBOT
graceful stratus
#

Hi there 👋 can you tell me more about what you're seeing? Were both payments from that one Subscription?

gleaming wave
#

Checking

graceful stratus
gleaming wave
#

Hmm yeah okay so we had a bug where ad blockers were stopping our api from finishing a check before allowing certain actions. I'm still confused on exactly how this occured though

#

We allow people to skip their trial/upgrade their account straight away if they need more credits than their trial gives them or current month gives them, which is why billing cycle anchor would have been set to now

#

Oh wait did this guy just subscribe today?? I must have misread

graceful stratus
#

Unfortunately, seeing the requests you made to us is the extent of the insight that I have here. I likely can't offer much guidance on why that call was made twice. Yes, depending on timezones, this was done today/yesterday.

gleaming wave
#

What about this customer, same thing? cus_PiIcqnDQUJZLtk

graceful stratus
#

Wait, that's the same Customer ID?

gleaming wave
#

checking

#

Oh sorry i pasted wrong

#

cus_PhpEfsSmnb5gIJ

graceful stratus
#

Yup, looks like the same thing.

storm jasperBOT
gleaming wave
#

Hmm okay still struggling to figure out why it's happening though, especially because i thought this happened after i fixed the bugs we had but it looks like it just happened in the last 24 hours

cinder spade
#

Hi 👋

I'm jumping in as my colleague needs to do

#

Just so I'm on the same page, I"m seeing the two requests here as causing new invoices for the full billing period

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

gleaming wave
#

Hello! I'm trying to figure out whats happening after they start their trial? Thats the part i'm confused about... it seems like they have two charges, one states the trial ended the other doesn't

#

Yeah can you see the past conversation by the way

cinder spade
#

Whatever is triggering these update requests is passing trial_end: "now"

#

That's coming from your integration. The second request doesn't end the trial because the first one already ended it

gleaming wave
#

But why is the second request causing an entire new charge?

cinder spade
#

Because it is also resetting the billing cycle anchor to now and passes proration_behavior: "none"

gleaming wave
#

Got it! Okay this makes sense now. I obviously have to do some fixes on our integration, but just in general do you have any suggestions on the backend for how to stop this from happening if a user somehow requests it?
Also, what would be the easiest way to search and see if any other customers have done this? I originally searched for two subscriptions but this is obviously just one subscription with a resetting anchor

#

We do want people to be able to skip their trial (so they can get more credits if they've enjoyed the trial)

cinder spade
#

Well the first part would be to check if the subscription is in a free trial. If not, you wouldn't try to end it.

#

That way the customer could only make this request once

gleaming wave
#

Ah of course

cinder spade
#

If you look in the previous_attributes section, you will see the status changed from trialing to active

#

So what you could do in your integration is, if the user is attempting to end their free trial, check to make sure the subscription you are about to update has a status of trialing

#

If it already has a status of active your front-end could just let them know it's already active so they don't trigger a new invoice

gleaming wave
#

Great

#

I guess my search question doesnt make sense actually, because since its not double subscriptions, its just a matter of looking at recent payments since we dont have that many to look at anyway

cinder spade
#

It would be kind of tough to search for. But the way we see what is happening is we are looking for multiple requests to update the same subscription in short periods of time.

#

So I saw two requests to
/v1/subscriptions/sub_xxxx

where the ID of the subscription (sub_xxxx) was the same

#

That looked odd so from there I dig in deeper.

gleaming wave
#

Okay

cinder spade
#

Another way you could do this is to look through the Events List API specifically for customer.subscription.updated events

#

Then flag any customer & subscription IDs that were modified close to the same time