#storm-guardian_api

1 messages · Page 1 of 1 (latest)

robust mantleBOT
#

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

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

real relic
#

  1. Why do you need next_action specifically? Do you not just pass the intent client_secret to the confirm fn?

  2. Not really possible without a trial, other than using a 'free' plan for 1 month then transitioning to the paid plan for the remaining 11 via a schedule

twin heath
#

Not really possible without a trial, other than using a 'free' plan for 1 month then transitioning to the paid plan for the remaining 11 via a schedule
Yes, I figured it would require a manual update at the end of the trial.

real relic
#

Well it doesn't need a manual update if you actually use trial_period_days

#

It'd just transition automatically into a paid period

twin heath
#

Why do you need next_action specifically? Do you not just pass the intent client_secret to the confirm fn?
It would be as difficult to get the client secret no ?
Maybe I'm doing things the wrong way, but I figured I would get the redirect_to property back to the frontend once the subscription has been created to follow up with the 3DS validation.

real relic
#

expand: ['latest_invoice.confirmation_secret', 'pending_setup_intent']

should over both scenarios (free and paid invoices)

#

Then depending on presence of one you conditionally call confirmSetup/confirmPayment

twin heath
#

Oki !

robust mantleBOT
twin heath
#

I'll take a deeper look into subscription_schedules, the AI assistant didn't point me toward this.

#

Thanks for the advice.

#

But you're saying that it would be possible to have :

  • no billing at the subscription
  • billing at the end of the month for a full year
  • 11 months later -> billing for the next year
  • 12 months later -> billing for the next year
austere skiff
#

hi! I'm taking over this thread.

#

no billing at the subscription
can you calrify what you mean by this? a free trial?

twin heath
#

more of a withdrawal period.

#

the month will be paid by the first billing

#

but I let him try the product for 1 month before taking the money for the year

austere skiff
#

got it. then yes what you described can be done with a subscription schedule. It would have 3-4 phases.

twin heath
#

Ok I'll take a look

#

I should add that, some features will require the user to give up on this withdrawal period.

For exemple if he uses feature A, a pop up asks him to accept the fact that the 'trial' will end right away. If he accepts, the he should be billed immediately (but the cycle anchor should not change).

#

I guess that means I'll have to dynamically update the schedule.

austere skiff
#

yes, something like that.

twin heath
#

By the way, about that :

There was latest_invoice.payment_intent but it has been removed.
I left a feedback, the AI agent provides answer that are based on the previous API version.

#

TestClocks ! Amazing 🙂

#

I was indeed a bit confused regarding how I would test this.

#

Thanks a lot for the help !

austere skiff
#

happy to help 🙂

twin heath