#deinonychus_code

1 messages ¡ Page 1 of 1 (latest)

dense idolBOT
#

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

📝 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.

acoustic pivot
#

Oops the code cuts off but the important part is there. That's the network error I get when I try to submit a new valid credit card after a failed credit card

oak anchor
#

Hi there

acoustic pivot
#

maybe another important thing I forgot to mention, is I'm testing with this test card, which specifically succeeds the setup intent part if I'm understanding correctly

image.png
oak anchor
#

Okay, a few things here. The purpose of a SetupIntent is that, when confirmed, it gives you a PaymentMethod object which is optimized for future use. You don't need to collect those payment method details again once you have set up the payment method.

Depending on why the PaymentIntent failed, you might need to collect new payment method details, or you might take the same pm_123 object and try to confirm the PaymentIntent again

#

The card you are using can never be used to successfully confirm a PaymentIntent

#

so if, for example, you tried to confirm a PaymentIntent and the response from Stripe tells you that the card number is incorrect/invalid, or the card is expired, you might want to create a new SetupIntent and prompt the customer to provide payment method details

#

Also, the idea of a SetupIntent is to give you an idea of whether the payment method is chargeable or not

acoustic pivot
#

Oh, I thought I needed SetupIntent to get a client secret

#

To display the payment element in the frontend

oak anchor
#

PaymentIntents also have client secrets. And, depending on what you want to do, you don't necessarily need a client secret to render the Payment Element at all

acoustic pivot
#

Our basic current flow looks like this:
The form is loaded after we request a setup intent to get the client secret. The customer enters their credit card information, which is saved with confirmSetup (this requires a client secret if I'm not mistaken) and then manually set as default via the SDK. If the setup intent triggers 3DS or fails, we handle it in the frontend. Otherwise, a subscription is then created and charged automatically (Payment Intent). => We get the payment intent status from the backend, then return in to the frontend so it can be handled

oak anchor
#

When you say "subscription" - do you mean that you handle your own Subscription logic and create charges with the PaymentIntents api, or are you using Stripe Subscription?

acoustic pivot
#

Stripe Subscription. Maybe it helps to see some of the flow from the workbench?

image.png
oak anchor
#

Okay, gotcha. So the flow you are doing is a bit redundant. You can get a client secret from the Subscription's latest invoice and you don't need to create a SetupIntent first

acoustic pivot
#

Cool, will take a deeper look at this. I understand this is for deferred payments, but we also need to charge immediately when the customer subscribes/upgrades. Is this possible?

oak anchor
#

"deferred" here just means that you don't need to create a Subscription/PaymentIntent/SetupIntent before rendering the payment element.

We GA'd this flow a couple of years ago, and it was a big improvement and we called it the "deferred intent" flow

#

You will still charge the customer for their Subscription upfront

#

You'll render the Payment Element and then when they submit the form you'll call your backend, create a customer/subscription, etc, and return the client secret to your frontend, where you'll call stripe.confirmPayment or stripe.confirmSetup

#

With Subscriptions, there are some instances such as usage based billing where you might not be billing upfront and you'd get a SetupIntent client secret from the Subscription rather than a PaymentIntent client secret

acoustic pivot
#

Gotcha, that does sound simpler. And it doesn't sound like a huge refactor on our end.

oak anchor
#

its honestly very easy to do. I was migrating an old 'create react app' project to vite/typescript and I wrote the code for that flow in that app just yesterday. Its pretty quick

acoustic pivot
#

Nice! I also realized recently (after an email from Michael Luo) that we could have been using the semi-recently released Checkout Session API which looks even simpler (haven't dug too deeply yet, just want to finish our payment flow first now that it's almost done). Now that looks a bit more daunting to migrate to

oak anchor
#

I think the question there is if you want/need the features which that feature brings, which is some of the stuff that Stripe Checkout (hosted Checkout - we are very bad at namespacing) does - automatic tax and discounts and handling billing address updates, etc on the frontend

acoustic pivot
#

Ah I think those we handle from the backend at the moment but might still be worth to investigate.

#

Anyway, thanks a lot for the tips, you guys are super helpful!