#piyush_best-practices

1 messages ¡ Page 1 of 1 (latest)

placid barnBOT
#

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

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

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.

limber cloud
#

As per #help, we close threads after inactivity. There was no reply for ~25 minutes. Please be ready to reply and engage in threads with your follow-up questions

young forge
#

I've gone through it, the problem is when creating subscription which has trial days, the susbcription directly has trialing state(with or without payment method), this article collects the payment method after creating subscription(through the pending_setup_intent of subscription object which i don't want), i want to collect it upfront, before creating the subscription, as customer may not add the payment method after initiating the trial

limber cloud
#

Did you read the link I just sent? It covers exactly what you describe:

i want to collect it upfront, before creating the subscription, as customer may not add the payment method after initiating the trial

young forge
#

what if the customer don't go ahead after receiving
pending_setup_intent?

The subscription will be trialing state right?

limber cloud
#

I don't know what you mean 'don't go ahead after receiving SI'? That's not really how the flows works

Imagine your checkout UI. In there you'll have the Payment Element where the customer provides the card/payment details, and a 'pay' button. Once they press that pay button they have committed to providing you with payment details, and your integration will create the subscription and confirm the Setup/Payment Intent generated from the API call

They can't not go ahead after they press 'pay'

#

Sure, there may be the occasional scenario where 3DS/auth is requested for the initial Setup Intent and the customer doesn't complete it/it fails and you'd have a subscription in 'trialing' without a valid card. But you can account for those scenarios by subscribing to webhooks, like invoice.payment_failed and ultimately cancelling the subscription or initiating a recovery flow

#

You can also just check for subscriptions where status: 'trialing' and default_payment_method is null

young forge
#

thanks, let me consume all this and will get back in case of any question.

young forge
#

I was doing some play around, i've enabled card and amazon pay PMs, so when i add card as pending_setup_intent's PM it directly adds but amazon pay leads me to this, though this is sandbox, could the same be there in prod too? If so, then this could be failed too, and as confirmIntent is called after creating subscription it will require manual handling, am i missing something?

image.png
limber cloud