#Gizmo - Manual Elements Validation

1 messages · Page 1 of 1 (latest)

vernal shoal
#

Hi 👋

gritty tulip
#

Hi Snufkin, how are you today?

vernal shoal
#

Peachy Keen. Are you talking about the Payment Element?

gritty tulip
#

Yes, the drop-in fields for taking payments

#

If you enter invalid info in a field you'll see the field's validation

#

I'm looking to trigger validation for all of them a once when a customer hits a button

#

That way when the customer hits a "continue" button on my page, if they haven't filled out my own name and email fields, I can show them the validation errors there, and if they haven't filled out any of the Stripe Payment Elements fields, I can show them the validation errors for those, and only if they've filled out everything can I call the Stripe Payment Elements confirmPayment method (or whatever it's called)

vernal shoal
#

Okay it's not manual per se but, as you know, you can listen for the change event and the Stripe elements broadcast their validation values. You could store this in a JavaScript variable for each input and provide feedback to the user about which ones were invalid in your button click or form submit event handler
https://stripe.com/docs/js/element/input_validation

Stripe JS Reference
gritty tulip
#

Thanks, but would I have that info if they haven't filled out any of the fields yet?

#

Can I dm you a screenshot of what I'm trying to accomplish (unless it's already clear)?

vernal shoal
#

It's pretty clear. This is just something you would need to handle in your front-end. Gimme a sec to test something

gritty tulip
#

Ok, thanks. I'm not sure I can use your suggestion because if they haven't filled out an of the fields yet then there would be no change events.

vernal shoal
#

Right but you would start with the assumption that all fields are empty

#

like

{ card_number: "empty", expiration: "empty", cvc: "empty", postal_code: "empty"}
#

And check against that when your user submits their information

gritty tulip
#

I see, so I can track their state. How can I get the validation error style to manifest when the button is pressed for a field with the empty state?

vernal shoal
#

That bit is more tricky. Since the element is rendered inside an iframe

gritty tulip
#

Yeah that's the whole point is to have my page look like a cohesive form 🤔

vernal shoal
#

Well have you examined what happens when you leave fields blank and try to submit? I think the existing error messages look pretty decent

gritty tulip
#

I agree, they look good and that's exactly what I want to have appear when I validate. The thing is I can't just submit because I need to first validate that my own name and email fields have values. Otherwise the customer could make the purchase without supplying the required information.

I suppose I could first validate my own form fields when they hit continue, and only if they pass validation try to submit the form. However, it seems like a janky experience for only some of the required fields on a page to show validation errors and not others (the Stripe Payment Elements fields would not show validation errors)

crimson hull
#

You could also choose to not even render and/or enable the paymentElement until after the customer has filled in your fields...

vernal shoal
#

This was triggered when I attempted to submit. I can track the JS execution more closely but I think you could include your own validation function in this callback

gritty tulip
gritty tulip
vernal shoal
#

.cofirmPayment()

gritty tulip
#

Thanks, but confirmPayment is what actually makes the payment. I need to show any validation errors before confirmPayment is called so I can call confirmPayment conditionally.

crimson hull
#

On my page, the paymentElement is rendered, but the submit is disabled, until my fields are filled. You can also have your submit function look at your field's status, and not actually execute the .confirmPayment until they are.

gritty tulip
#

Thanks, I know I can not call confirmPayment until all of my fields have been filled out. The issue is how it looks if I want to validate upon submission. I'm able to make my fields show their validation issues, but not Stripe's.

Screen_Shot_2022-05-03_at_11.45.12_AM.png
vernal shoal
#

But if you call confirmPayment at this point it will just return the validation errors for the Stripe fields.

gritty tulip
#

Yes but if there are no validation errors on the stripe fields, it will submit the payment even though my customer hasn't supplied the information I need yet.

crimson hull
#

Well, since the submit button calls your submit handler, run validation and mark your fields as needed. If they aren't validated, simply don't call confirmPayment, and return from the handler

#

No, it doesn't actually - I believe it only "submits" the form if you call confirmPayment - it just fails-out at that point if the fields don't validate

gritty tulip
vernal shoal
gritty tulip
gritty tulip
vernal shoal
#

No, if the user starts entering data and then moves on it will trigger validation as well

gritty tulip
vernal shoal
#

You could try programmatically setting focus and removing it to trigger the change event. But I haven't tested that yet.

gritty tulip
misty musk
#

👋 I'm hopping in since @vernal shoal has to head out - give me a mi nute to catch up

gritty tulip
#

Sure, thanks karbi.

misty musk
#

Just to confirm - your question is whether there's any way to to trigger validations on empty inputs inside Payment Element w/o calling confirmPayment?

gritty tulip
#

Yes, basically. See this screenshot? #971091209261023282 message The idea is to show the customer all of the fields that are missing or invalid when they try to checkout.

As it stands, I can only show them the validation issues with my own form fields (name and email) for the reasons I described in the thread, namely because if I called confirmPayment to trigger the Stripe validation issues, the customer may have filled that part of it out and the payment would submit before my fields had values.

Does that make sense?

misty musk
#

Yeah I see what you mean - unfortunately there's no way to trigger validation on these empty inputs. The only option that's available is what snufkin already mentioned about listening for the change event (which as you mentioned is only for invalid values)

gritty tulip
#

Got it. Thanks for confirming, karbi.

crimson hull
#

you could drop a highlight around the entire element if there hasn't been any change events - and if not all elements have had change events you can be confident there'll be validation errors... after all, I'm pretty sure they have to have at least changed from empty to be valid

gritty tulip
#

Thanks for another interesting idea / workaround, GiGStartr. I'm trying to think if the "lesser evil" would be to wrap the entire payment element in red as you describe, or to simply not show validation issues for the payment element if/when there are validation issues with my own fields (ie. only call confirmPayment if my fields pass validation)

#

Reposting here since karbi asked me to continue to use this thread for another question:

Is there a way to use the Stripe Payment Element so you have the benefit of not having to create the payment form, but have payment submit synchronously via the backend (as a result of the customer submitting that form)?

My customer is supposed to be taken to a page to use my application after they submit their payment, so I'm not sure how it would work to rely on asynchronous webhooks to do the processing triggered by their purchase.

misty musk
#

Just to make sure I understand - are you trying to emulate the server-side confirmation flow with Payment Element?

gritty tulip
#

Basically to get a form from Stripe like Payment Element provides, but be able to process everything server side so I don’t need to redirect the customer or rely on webhooks to know if the transaction was successful. Does that make sense?

misty musk
gritty tulip
#

Thank you. Can you elaborate on what it means when it says this is difficult to scale?

misty musk
#

Sorry let me clarify - is that the flow you're trying to accomplish with Payment Element? (Right now this isn't supported on Payment Element at all, I sent the link just to confirm that's the flow you're describing)

gritty tulip
#

Yes I'm looking for a flow like that where I can process payments synchronously and immediately give my customer access to my software if the transaction is successful.

misty musk
#

As of right now there isn't a good way of accomplishing this with Payment Element - there's some work to be done to add this, but it's not ready yet

gritty tulip
#

I see, thanks. Do you have any advice on how I could use the standard integration but ensure the payment has gone through before giving the customer access to my software?

misty musk
#

Immediately after redirecting you could retrieve the Payment Intent to confirm that the status is succesful

gritty tulip
#

Thank you. I need to submit my form so I save the customer's name and email once they submit payment. Is there a way to suppress the redirect altogether so I can

  1. Submit the Stripe Payment Element
  2. Get a callback that it went through successfully
  3. Submit my form and take the customer to the page for paid users
misty musk
gritty tulip
#

Got it, thank you karbi. Will using only credit cards effectively disable redirects entirely, or are there some cards that may still redirect? (it sounds like things will break if the redirect happens)

misty musk
#

Cards should never require redirects

crimson hull
#

3DS?

gritty tulip
#

What's 3DS?

misty musk
#

3DS wouldn't need a redirect either - it'd be completed in a modal

gritty tulip
#

It sounds like this should do the trick. And then I could just add the paymentIntent object I receive in the callback to my post body, submit my form, and validate that the paymentIntent is indeed paid on the backend?

misty musk
#

Yup!

#

I need to head out, but if you have any other questions @pure ginkgo can help

gritty tulip
#

Thanks so much, karbi!

#

Do I even need to validate that the payment intent is paid on my backend? Or does my receipt of the paymentIntent in the callback on the frontend mean it was paid successfully?

pure ginkgo
#

Hello 👋
While you can retrieve the payment intent to check its status, you can implement a webhook endpoint server side to receive real-time updates
https://stripe.com/docs/webhooks

gritty tulip
#

HI Hanzo, thanks for your help. In my case I think a webhook would be less than ideal because I give the customer access to software as soon as they've paid - I don't know how I would achieve that with a webhook (where to send the customer after they pay, etc).

Regarding retrieving the payment intent to check its status, can I just look at the payment intent I receive at the frontend, or should I use its ID to call Stripe from the backend and examine the contents that way?

pure ginkgo
#

You can look at the one that your front-end receives, yes.

#

But the PaymentIntents are designed to work asynchronously so you'd likely need to retrieve it again to check its status

gritty tulip
#

I just realized a malicious user could edit the form i submit upon the confirmPayment callback to make it look like it was paid even if it wasn't, so I should definitely submit the id of the payment intend I receive and then look that up on the backend to determine its status.

#

Will my account only have the ability to lookup payment intents created by my account so I can be sure the one I lookup on the backend is the one I just received on the frontend (and wasn't replace by a user via browser dev tools)?

pure ginkgo
#

Yes, your keys would only be able to find PaymentIntents created on your account.

gritty tulip
#

Thank you

pure ginkgo
#

An issue there would be if a user managed to get their hands on a PaymentIntent created and paid for on your account and passed that back

#

You'd likely want to check more than just the status of the PaymentIntent such as the creation date etc

gritty tulip
#

Thanks, good call.

#

I just want to make sure there isn't a solution that would use Stripe's preferred method of using webhooks that would work for me. Or is it not suggested when there needs to be a realtime consequence for the user of their payment going through?

pure ginkgo
#

Not sure I follow
Can you expand on that?

gritty tulip
#

So I'm setting redirect to if_necessary and limiting my payment method to credit cards so that there is no redirect and I can submit my form that saves a customers name and email, and then bring my customer to the software they paid for (without using webhooks because it would be seemingly impossible to do using webhooks).

If I understand correctly, this isn't the intended flow. I'm trying to determine if there is a way to do what I need to do using the intended flow.

crimson hull
#

The webhooks generally happen pretty fast. In my case, it's the webhook handler that makes the database change that enables the user. The front end sends the user where they need to go; code on that page checks the database, which will either already be ready, or will be in a couple seconds

#

It does take the user a couple seconds to respond to a page change, and if the page you send them to has a login (created by the payment) that will mire than cover the time

gritty tulip
#

I was creating the user and logging them right in, but I suppose I could require them to login (even though it arguably adds more hassle/friction)

Do you know if there is any way I could submit my form with the user's account info (name, email, etc) before the redirect happens?

#

I actually don't know how that would work.

#

One solution would be to create the user in the system before they pay, but I only want to create users for paying customers.

#

Also, I think it's worth asking, if I do it the way I was discussing with kribi, can I rely on Stripe to continue not to redirect users if credit card is my only available payment method?

pure ginkgo
#

Also, I think it's worth asking, if I do it the way I was discussing with kribi, can I rely on Stripe to continue not to redirect users if credit card is my only available payment method?
Yes

gritty tulip
#

Is there any way to know the success of a payment intent before a redirect if I tried to use redirects and webhooks like I'm "supposed to"? Trying to figure out if there would be any way for me to save my user's account data that way.

crimson hull
#

There is no reason you can't save a user's data in parallel with the confirmPayment - and update said user record from the webhook

gritty tulip
#

I would be creating the user in the database before I knew if the payment was successful in that case, though, wouldn't I?

crimson hull
#

Create the record in a "pending" state; the webhook changes it to "active"

#

Storage is pretty cheap these days...

gritty tulip
#

Yeah, there's that. Do you think there are enough benefits to allowing redirects and utilizing the webhooks to warrant storing the user's info in a temp table and doing it that way vs only using credit cards and knowing if the payment was successful before I post my form and create the user?

pure ginkgo
#

Best practices usually depend and differ based on integration patterns and how you want it to work 🙂

crimson hull
#

In my mind, it opens you up to the possibility of other payment methods (cards will stay in the modal), and allows you to capture a customer, and to my mind most importantly, have the information to bring the user back to try again if there's a problem

gritty tulip
#

Thanks for elaborating, GiGStartr. Can you expand on what you mean by "have the information to bring the user back to try again if there's a problem"? The user would presumably know right away / in real time if there is an issue with the other way.

crimson hull
#

More speaking about other payment methods you may choose to add later. Trying hard to stay sync limits you to only cards - other payment methods that may be more async simply wouldn't work with the flow. The existing SetupIntents & PaymentIntents async flow will be very very fast so your users will likely not even know it's occurring (really, the page they are being redirected to probably won't even load before the webhooks has responded and updated the database); but you will still have the possibility of the other methods later.

#

This isn't any kind of Stripe recommendation - just my general approach to development after 40 years in the business.

gritty tulip
#

I really appreciate you sharing the benefit of your experience with me. 👍