stripe/stripe-js

Ability to know when the user has invoked the submit button (Embedded Checkout)

Benjamin-Willard opened this issue · 6 comments

Benjamin-Willard commented

What happened?

I would love to be able to know when a user has invoked the submit button just like how we have the onComplete callback that helps let us know that the checkout process. As there are couple use case for this.

  1. Being able to track with analytics when a user has submitted the checkout.
  2. Being able to use this to determine whether or not to disable UI specific aspects such if we have a modal, and want to prevent the modal from being removed from the DOM which in sense can stop the entire onComplete flow.

Uniphix

Environment

No response

Reproduction

No response

brendanm-stripe commented

For the Express Checkout Element, this is what the confirm event (ref) indicates, which is used to initiate confirmPayment. This should already be part of your flow with ECE, though, so can you please clarify what you're trying to achieve and how this ask fit in?

Benjamin-Willard commented

How will this work with React?? From what I see EmbeddedCheckout for react version does not contain this reference and I noticed I stated Express Checkout, this is my bad and I meant the Embedded Checkout...

brendanm-stripe commented

Ah, gotcha. Embedded Checkout is a bit different. There's no signal tied directly to the pay/submit button click.

For redirect-based payment methods, you'll handle results via the return_url, or without redirects you'd provide an onComplete handler: https://docs.stripe.com/payments/checkout/custom-redirect-behavior#redirect-if-required

Benjamin-Willard commented

Yes we are not using return_url, because we don't want them navigating outside the page scope of what we are doing. So we are using onComplete. However what we would like to do is prevent the user from being able to cancel the modal or pressing any cancel button that would close the modal. Closing the modal while the primary action button has been triggered will break the entire chain of the onComplete being unmounted.

So being able to know when the user has triggered the "Primary button" which help us know that the process has begun. This not only helps for what we want to do but it opens the door for other things like analytics to see how many people actually begun the process vs an error etc.

brendanm-stripe commented

So would this amount to exposing an event handler for onPaymentSubmit or similar. I can share feedback about this as something you'd like to see, but we don't support it today.

One challenge here is that it would be limited to the non-redirect case, since a redirect-flow payment method would prevent/interrupt your client code from handling that signal.

  • 👍1
Benjamin-Willard commented

Basically when they click the "Pay" Button so if that is what you are referring then yes. And yes that would make sense that this would only work for non-redirect flows. Just like the onComplete I believe also.

Our flow is that we are not using the redirect-flow we have disabled that by doing

redirect_on_completion: 'never'

Therefore the onComplete call gets invoked like it should. Only time is that if the user clicks on the "X" part of the modal, it will unmount the entire payment flow. Again that is not your guy's fault, that is more of an issue on how we are implementing it. What we would like to do is either hide or disable the "X" from being invoked if the "Pay" button was invoked. This is a nice to have feature moreso than anything. I am sure you guys have other pressing things you need to fix/improve on first. So I understand if this isn't a high value, but I would think it would be a low risk implementation on your guys end.

Thanks again