#m4tt-Paymentintents
autumn wagon
Hi there! Yes you would want the order to already be ready prior to confirmation as this would be the last step in your flow and you need to know the amount to charge.
It is always possible a customer drops off at any point in your flow. I'm not quite sure why that is relevant here?
low path
I would not normally create the order (ie in the db) until the payment has been confirmed.
autumn wagon
Sure you don't need it created in the DB until that point
low path
Ok so that's the bit I'm confused on
autumn wagon
You would use Webhooks to ingest the order to your database
Are you familiar with Webhooks?
low path
Yes
Not stripe specifically
Ok so what do you recommend I do about validation? Ie non payment fields in the checkout process?
Email, name etc
autumn wagon
That is really up to you and how you are going to use that data.
low path
For example what I've done so far, everything wit stripe works but the form being submitted is empty, which is obviously incorrect. So the only way I can see this validating is to call an endpoint via js before the payment is confirmed. Then once the endpoint validates (and probably creates the order db record) I then confirm the payment via stripe.js
Does that make sense?
autumn wagon
Not exactly. Let's back up. What integration flow are you using? Sounds like a custom form? Are you using Payment Element?
low path
It almost seems to be like payment intent is designed for invoices where the amount and details are already confirmed
Yes this is the card element
I create the intent when the checkout page loads, ie where the card element is located
autumn wagon
Gotcha. So you likely do want to add validation that is based on your "Pay" button to ensure that the fields you want filled out are filled out.
low path
Yes that's where I am at, but I cannot see how I do that without an extra http call before I confirm the payment
As I cannot combine the confirm payment and my own validation in one http request right?
I'm sure I'm overcomplicating or missing something silly!
In the old days I would create the order, confirm payment and update order all in one http request
It's been a while since I worked with checkouts
autumn wagon
There are definitely a few ways to do this, but the safest is indeed to add validation server-side. You would trigger a request to your server where first you would have a conditional to check the information from your custom fields (like name + email).
However
If you don't want an "extra" http request here then you can wait on the PaymentIntent until you do this validation check.
Since you are using card element you don't have to create the PaymentIntent on page load.
low path
So the flow would look this:
- Load checkout page and create payment intent server side
- Customer completes form
- Http request to my server to validate and possibly create the order in the db
- Assuming validation is correct, confirm payment
- Clear session and redirect to order accepted page
- Wait for webhook to confirm payment
- Etc
low path
Since you are using card element you don't have to create the PaymentIntent on p...
Oh..?
autumn wagon
Yeah definitely don't log to your DB at step 3
As payment could still fail
Unless you want to track order attempts or something
low path
This is exactly my issue and source of confusion
autumn wagon
But yeah with Card Element you can create the PaymentIntent when the customer hits "Pay" and then send the client_secret back client side to confirm that PaymentIntent.
The biggest thing here is there is a tiny bit of extra latency due to the round-trip so you'll want to show some sort of spinner or something.
low path
But how do I ask for the card details without an intent?
The card element will not be available without an intent no? So when I click pay there will be no card details
autumn wagon
You can mount card element without a PaymentIntent
You can't render the Payment Element without a client_secret
Those are two different types of Elements
low path
🤯
Well this is why I am getting confused then!
Hang on a second
What actually is client secret?
Don't tell me it's the publishable key?
autumn wagon
No, the client_secret is essentially how your client knows what PaymentIntent to confirm
low path
Right ok phew!
So how would I have a client secret if there is no intent?
Oh hang on, so the card element doesn't need a secret?
low path
Right so how do I link the rendered card element to the backend?
autumn wagon
You pass the card Element into your confirmCardPayment() method.
That is how the PaymentIntent uses the card details from the card Element
low path
Righhhhht
autumn wagon
You want to take a look at: https://stripe.com/docs/payments/accept-card-payments
And basically just ignore where it tells you to create the PaymentIntent prior to mounting the Element.
low path
Right so I just need to render the card element with no intent, submit the form using is, validate and create the intent within the submit request, return the intent secret to the js, then confirm card payment, on success redirect to success page, wait for webhook to confirm, then create the order
Using js*
That's correct yes?
So the confusion all stems from needing the intent for the card element. All makes sense! Thanks so much for your help, crazy how quick and responsive you were!
autumn wagon
Yep that all sounds right to me!