#shawn_api

1 messages ¡ Page 1 of 1 (latest)

cold mothBOT
#

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

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

keen cobalt
muted wing
#

Yes, i see

#

but you have proration and stuff like that.

#

We want to charge full price, and then tag on 30 days. If you scour the internet, or ask chatgpt, the simple answer seems to be no.

#

We've been trying to get our 20K subscriptions transferred to stripe after pan migration, and now daily day-to-day things aren't easily done.

#

I will check your documentation again, but from what our team has seen, and also all the documentation, we did not find an immediate answer.

#

Your documentation is on easy stuff, yes we understand that, if you look at our traffic, you'll see we have been extensively been testing and now migrating live customers. Probably 10k test subscriptions, with 100 of thousands of api requests to ensure safety. Because of the issues, we now have to migrate small batches to live

#

However, day to day items of customer care items are very hard, with schedule subscriptions and such

#

Let me ask this simple question.

#

User is on subscription 1, monthly. 20 out of 30 days.
User wants to pay immediately for 3 year. How do we charge the FULL amount, then the new 3 year subscription gets the 10 days remaining from monthly? Is this possible?

#

If not, what are our options that programatically and logically make sense? It seems scheduled subscription of 10 days trial at the end of their subscription, which is nasty in itself.

keen cobalt
#

For the payment itself I would do that separate from any Subscription; I'd likely use a one-off Invoice or a Payment Intent, then after the payment was successful I'd adjust the Customer's balance accordingly.

muted wing
#

yes, but that credits future payments, so next payment maybe credited.

keen cobalt
#

And adjust their Subscription accordingly.

muted wing
#

that means less amount

#

we want a fixed charge, but extend time, not reduce the next charge.

keen cobalt
#

Right, but all of those future payments would come out of their balance, they wouldn't be paid by the Customer.

muted wing
#

Yes, again, that would reduce a payment.

keen cobalt
#

Not sure I understand. This is a fixed charged with extended time? Can you provide more speciifc details about why this won't work?

muted wing
#

We aren't trying to maximize the money, but I'm just wondering that's the only solution

#

Okay, let's create this scenario:

Today is Jan 1.

  • Let's say user wishes to pay $100 for a 2 year plan, billed immediately. Call it product_2_year.
  • They are currently on a 1 year plan called product_1_year and it ends on Mar 1st.

How would we handle this so they always get charged $100.

  • We know that today, Jan 1, we should charge the user $100 dollars.
  • They should be charged 2 years later on Jan 1, however...
    Since they have 2 months left on their existing subscription (the 1 year plan), we should extend their payment date to Mar 1st, 2 years later, so they pay $100 after 2 years and 2 months.
keen cobalt
#

Can you clarify what you mean by "How would we handle this so they always get charged $100."?

muted wing
#

Whenever an invoice is created for the subscription, it should be $100, We don't want to change this dollar amount. Not because we trying to keep a higher amount, but because questions arise when billing amounts are not what is expected.

keen cobalt
#

Gotcha. So I think I'm confused about why prorations don't address this issue for you? If you update the Subscription from the current state to the new two year plan our prorations should credit them for the existing time. You can also either adjust the billing cycle anchor or add a free trial period if needed to make the billing happen exactly when you want it to.

muted wing
#

Yes, so we need to use free trial right?

#

Wait, doesn't proration change the value amount?

#

Like because you still have 2 months left, they will change the amount of $100 -> say $87.50 because you get credited.

keen cobalt
#

The value amount? I don't understand what you mean, sorry.

#

Backing up a bit, have you tried these scenarios in test mode? It would be helpful if you could point me to a speciifc test Subscirption that's not working the way you want to I can examine what you're trying and advise from there.

muted wing
#

If we change the current state to the two year plan:
#1. Can we trigger a payment immediately of $100,
#2. The next invoice for the schedule is also $100.

#

We haven't handled this case and left customers waiting.

#

I am trying to figure out how to do this.

#

Another issue is these are migrated accounts also, that actually don't even have a subscription on stripe.

keen cobalt
#

So, to clarify, you haven't tried to do any of this in test mode?

muted wing
#

We are trying to invoice for a subscription, and then adjust the length to be longer.

#

It's my colleague that has tested, now that he's so badly burnt by the migration process, I must take over some processes.

#

I will do some testing now, we have 350 customers in various queues currently to process manually and every day this increases by about 100. We just migrated to stripe yesterday....

keen cobalt
#

I'm sorry the migration hasn't gone well, but for something like this with this level of complexity the first step is to experiment in test mode and get it working exactly the way you want there first.

muted wing
#

okay, just to say that we aren't lightweights

#

I write most of the frontend setup of new subscriptions, that is 100% fine

#

We have checkout sessions, discounts, product lookup, like 15 Objects handled, and webhooks, I wrote that. embedded stripe forms all that is working.

keen cobalt
#

I didn't intend to suggest you were "lightweights" or anything of the sort, I'm just attempting to explain the best path forward for you.

muted wing
#

It's the edge cases, that are killing us.

#

Yah, no issues.

#

okay, well now time to process 250 subscriptions by hand.... customer care handling. I will play with stripe

#

There is something wrong with your documentation

keen cobalt
#

It would be much more useful, for example, if you could point me to a specific test mode Subscription that's doing most of what you want but isn't quite doing everything you want, then I could look at that specific situation and provide much more useful help.

#

Right now, though, things are too high-level and vague, and it sounds like there's a lot of things you haven't attempted or experimented with for this particular issue.

muted wing
#

Yeah, the only issue is the methods we know of are only using trial period to extend a subscription by a fixed number of days

#

which is silly.

#

but you probably already know that.

keen cobalt
#

I'm not sure what you mean by that being the only way, or why doing that is silly.

muted wing
#

That leads to a whole bunch of issues, where we have to turn off "trial emails" and hook up webhooks, because you can't turn of trial emails per subscription, it's global.

#

It seems like the only way to extend a subscription for edge cases.

#

we don't want to pause either that screws with some other code

keen cobalt
muted wing
#

yes

#

but if we do that they won't get charged!

#

they get charged 2 months later.

#

no?

keen cobalt
#

Again, I don't know what that could mean because I can't see what you're doing/trying in test mode.

muted wing
#

Dude, you just said put them on $0 price AT THE BEGINNING

#

that means, they won't get charged until the phase changes to the paid subscription.

keen cobalt
#

Right, I also mentioned numerous times earlier that you could charge them using a separate one-off Invoice or Payment Intent.

muted wing
#

Yes, we could do that, but then it's not attached to the subscription

keen cobalt
#

I can't stress enough that having a specific example in test mode would make things a lot easier.

muted wing
#

Then we have to schedule the real subscription later.

keen cobalt
#

There are too many variables and factors to talk about this at a high-level without seeing a specific, working example in test mode.

muted wing
#

Okay. thanks.

#

I'll test on the weekend then.

#

And you can see my account right, and the subscriptions and customers etc

#

I'm almost 100% sure stripe can't do what we say easily. This is a thorn in the system, it's been stated scheduled subscriptions, trials at the end of the subscription etc.

keen cobalt
#

Yes, once you've tried things in test mode you can provide Subscription IDs and whatnot to us here and we can then see them on our end and help you further.

muted wing
#

All of which are just work arounds to the system limitation.

#

yeah sorry for being an ass and dumping crap

#

we've been working on stripe integration for 3 months.

#

I'll set up some specific cases and come back with actual test subscriptions then.

#

Thank you for being patient with me, your service is great. I'm being a bad customer.

#

And you're 100% correct, you need to see a specific case.

keen cobalt
muted wing
#

Yes, we;ve been using them too

#

we had several test runs, of 100s and I think 1000s of test subscription transfers and changes.

#

Also 20,000

#

okay, thanks for listening. I feel better. Have a great day.

#

You can close this and mark as resolved, Ill start a new question later when I have specific cases in our test system.

keen cobalt
#

Happy to help, good luck with your testing and if you need anything else let us know!

muted wing
#

Yes, thanks, and also, we aren't testing, we have to migrate 25K customers, done 150... (started production migration yesterday). We have a couple hundred subscriptions being added/modified daily; customer care, marketing/revops is being backlogged terribly with customer requests and ongoing promotions.

#

we are doing batches of 150 (not me, another couple colleagues)

keen cobalt
#

I understand you're under a lot of pressure to do this fast, but it's going to best to take the time to get it working 100% correctly in test mode first before doing anything in live mode.

muted wing
#

yes, our migration is fine.

#

it's that our previous system was much more flexible.

#

We can easily change rebilling dates, and amounts on the fly.

#

The general consensus is stripe is good, but api flexibility is bad.

#

We migrated off of a couple other payment processors (paypal and eXact, canadian company)

#

Have a great day, I'm logging off now.