#xmy_best-practices

1 messages ¡ Page 1 of 1 (latest)

narrow surgeBOT
#

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

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

still wave
#

I also have an additional question but there was not enough space in the form:

Right now my flow looks like the following:

  • Creating the subscription with payment_behavior: "default_incomplete"
  • Using the payment_intent's client_secret to pay (with card or paypal in my case)

I want to offer a one-time trial per account. From what I've seen I'd need to create a subscription with trial_period_days, but this creates a $0 invoice item and no payment information is required.
As far as I understand, this means the customer would come back another time to actually go through with the payment?

Do I need to change my flow to the following?

First subscription:

  • Create a setup intent to add a payment method
  • If the payment method is valid, create a stripe customer attach the payment method as default
  • Create a subscription with the payment method, adding trial_period_days
  • Disabling trial eligibility in my business logic

Nth subscription:

  • Check if customer has a least one payment method set up (otherwise kick off setup intent flow)
  • Create a subscription with the payment method, not adding trial_period_days as trial eligibility is disabled
worldly lodge
#

for your other question, the flow for a trial is the same, just you use the pending_setup_intent.client_secret on the frontend instead of latest_invoice.payment_intent.client_secret. Or you can collect the card first with a SI and then create the Sub, as you describe, if you prefer that

still wave
#

So my frontend would require no changes? Just conditionally return a different client secret

worldly lodge
#

you have to call confirmSetup instead of confirmPayment, for example

still wave
#

Oh alright, but pending_setup_intent.client_secret is coming from the created subscription?

worldly lodge
#

yes