#delgesu1745_api

1 messages ¡ Page 1 of 1 (latest)

novel driftBOT
#

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

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

unique spruce
#

This bit is in index.js in the doc at the beginning, but then the file referenced switches to checkout.js:

const elementsOptions = {
mode: 'setup',
currency: 'usd',
customerSessionClientSecret,
// Fully customizable with appearance API.
appearance: {/.../},
};

#

Also having trouble understand how this then translates to the payment form:

// Set up Stripe.js and Elements to use in checkout form, passing the client secret
// and CustomerSession's client secret obtained in a previous step
const elements = stripe.elements(elementsOptions);

// Create and mount the Payment Element
const paymentElementOptions = { layout: 'accordion'};
const paymentElement = elements.create('payment', paymentElementOptions);
paymentElement.mount('#payment-element');

fathom void
unique spruce
#

Ahhh ok, I think that's the issue then. Right at the beginning of the doc it has code in index.js

fathom void
#

Where do you see the index.js?

unique spruce
#

It's the component config on the client side.

fathom void
#

I see checkout.js

Screenshot_2025-04-02_at_12.29.52_PM.png
#

app.js is the server code

unique spruce
#

Sorry, I'm using the react option

#

Switch the tab from HTML + JS to React

fathom void
#

Ah I see

unique spruce
#

I think what I don't understand is the connection between index.js (on the React side) or checkout.html (on the HTML+JS side) and checkout.js.

fathom void
unique spruce
#

Yeah I've got requires steps 1, 2 and 3 setup and working.

#

And I already understand how to accomplish required steps 4, 5 and 6 from having setup the flow the I first referenced that sets the setupIntent up right away.

fathom void
#

Ok, now, since the Customer Session creation is a separate component, it is in checkout.js separate from checkout.js

#

You use the Customer Session's client secret there

unique spruce
#

What I thought this delayed method allowed me to do was to collect the payment info from the form in the first three steps and then to let them go back to my enrollment form flow and complete the rest of the required info for us and then at the end process the setupintent.

fathom void
#

But you want to add the option to show the payment methods already saved, yeah?

unique spruce
#

Yeah

#

So as it stands now with up to step 3, what happens when they hit the submit button on the form?

#

When I test it I keep getting an error that says "There was a problem connecting your account. Please try again, or try a different payment method."

fathom void
#

Can you share the specific request id where you see this error?

unique spruce
#

Ok, so I guess maybe I'm misunderstanding what the delayed setupintent flow does. It only delays it to until they click the submit button, then it creates it then, as opposed to loading the paymentElement initially with the setupIntent already created. Is that correct?

#

IF that's correct, then what's the advantage of doing the delayed setupintent flow?

fathom void
#

Yes, that is correct.

unique spruce
#

Also, that error message is just when I try to select a bank account to add. Not when I try to submit the form.

fathom void
#

If you want to build a multi-page checkout or collect payment method details before running additional validations, see Build a two-step checkout flow. With this flow, you create a ConfirmationToken on the client to collect payment details and then use it to create a SetupIntent on the server.

#

The advantage would be not have to create the setupIntent first to render the Payment Element.

#

Can you share you full business use case so I can recommend what integration might be best suited?

unique spruce
#

Ok, maybe the two step method then is what I after. I'll take a look here... And with the two step I can just collect payment details and submit to Stripe and not have to charge but save for future payments?

fathom void
#

It does not looke like I have a working example integration with this flow on my end

#

I only have one with the PaymentIntent

unique spruce
#

So does that mean it's not possible to use a setupIntent?

fathom void
#

I do not see a reason as to why not but I'm trying to confirm this

unique spruce
#

K, thx

fathom void
unique spruce
#

Ok, perfect.

#

So just going to see that I understand the two step setup...

fathom void
unique spruce
#

Right, I figured that, thx!

#

Ok, so basically when selecting submit then I'm just creating and capturing the confirmationToken, which I can then use later on a different page to create the setupIntent and confirm it?

#

Is the summary object returned when retrieving the summary something I have to render in a stripe element or is it just json that I can render however I want in my application?

fathom void
#

What you show there is up to you, yes

unique spruce
#

So in this flow there isn't any redirection needed, like previously when the setupIntent was created?

#

Wait so the confirmation summary is actually still being rendered in the same paymentElement form that collects the payment info. So it seems like it all still happens before they hit the submit on the element form.

#

I was mainly trying to handle the case where the user backs out of the payment step, or decides they want to change the payment method before fullly submitting our registration form.

#

I might just put the payment step as the last one though since there seems to be a requirement to redirect and I'd rather not redirect back to the middle of an enrollment form for us. I guess I just don't know how they are going to submit the rest of the data we need on their application after the redirect.

fathom void
#

I do not follow your last question, can you reword it please?