#mkoenke-paymentelement-click

1 messages ยท Page 1 of 1 (latest)

lethal martenBOT
sinful veldt
#

Yeah it looks like "click" is for elements that are themselves a button. Are you looking to get an event when the Payment Element info is submitted, or something else?

old arch
#

Yes, we are trying to know when the click event is fired for google pay or apple pay

#

to open the modal

sinful veldt
#

Are you using our deferred intents flow or the flow where you create the intent before rendering the payment element?

old arch
#

deferred intents

sinful veldt
#

I thought with the Payment Element, the Apple/Google Pay button is not displayed until you call confirmPayment. Are you seeing the modal sooner than that?

old arch
#

we dont use confirmPayment... we submit the payment element, create the payment method, and then send that to the backend to create the payment intent and charge at the same time by sending the payment method in the call when we create the payment intent

#

we see the modal when we call elements.submit()

sinful veldt
old arch
#

yes! we do that, and that works great. So we know that when the payment element changes and it is complete, we can submit. the problem is that is the user closes the modal, and we dont create a payment method and move forward in checkout, nothing changes so the user would then have to click on credit card or another payment method and then back on google pay again to get the modal to open again... its a little weird

#

we would like for the modal to just open again when the user clicks after it has been closed, but in order to do that, we would have to be able to listen for a click i think?

sinful veldt
#

Oh I did not realize that the modal was not showing up again. That sounds like a bug to me but I will need to look in to what we found yesterday first

#

Apologies, the server has been very busy so I haven't had much of a chance to look in to the history of threads here

old arch
#

no worries! take your time

#

thanks so much

sinful veldt
#

Just to make sure I understand the previous thread: you don't have a submit button on your page, and you are trying to automatically submit the payment element when a user selects Apple or Google Pay from the list of available payment methods?

#

And how did trying to use the focus event that bismark mentioned work out for you? I do think that would be the only way to see if the user clicked on the element again

lethal martenBOT
old arch
#

The problem with using the focus event is that when the modal closes, the focus returns to the payment element, so if we are looking for when it focuses to submit, we end up in a loop of making requests to submit

sinful veldt
#

In that case I think you'd have to do something like ignore the first focus after submitting an apple or google pay payment

#

Honestly I think the issue is that this is not how the Payment Element was designed to be used so I am not sure if there will be a solid way to implement this.

lethal martenBOT
sinful veldt
#

Waiting for the user to click a submit button would be one more click but I think it would be worth avoiding the development headaches

old arch
#

Yeah I hear you... we have a legacy system we are trying to integrate with that makes it difficult. We do have a submit button, but we submit separately because the user can make changes before or after to the product price they are buying, while the payment element is still rendered on the same page

wild lynx
#

mkoenke-paymentelement-click

old arch
#

for the deferred intent flow, where you would create the payment method on the front end, and finalize payments on the server, how is the intended way for the payment element to be used without running into this issue?

wild lynx
#

@old arch I'm not sure I follow the way you are framing the question. But mostly you render PaymentElement with an amount/currency client-side and drive down to the PaymentMethod creation. After that you hit your server to create a PaymentIntent and confirm

old arch
#

yeah that is what we are doing.... how does the payment method know when to open the google pay or apple pay modal if we are not manually calling elements.submit()? and if we need to call elements.submit() to open the modals, how do we know to open it if we do not know when the user has clicked and the payment element has not changed?

wild lynx
#

That's the part I don't really get at all in your explanation. You do need some button they click on. Once they click you call elements.submit(). I don't really understand your explanation of an infinite loop and such.

old arch
#

hmmm ok, sorry if it is not clear, let me try to explain, give me few minutes to organize my thoughts

wild lynx
#

My advice: make a really simple demo that just has your problem and makes it easy to grasp. It will force you to organize your thoughts by trying to show the issue without all the cruft of your existing app around. It's more work but it's also easier to show you potential alternatives in that case

wild lynx
#

Is there any chance you could share real code and text explanation versus listening to a video like that ๐Ÿ˜…

old arch
#

yessss lol sure

wild lynx
#

okay so first "Someone selects Google Pay, the modal pops open". What does that mean? How? Like selecting Google Pay does nothing in PaymentElement. And I would discourage anyone from saying "whenever they click on this I immediately pop up the PaymentRequest UI"

#

Are you literally listening to the change event, seeing a new payment_method_type as google_pay and deciding "let's submit"?

old arch
#

yes

#

bc we have to submit to create the payment method

#

and we have to create the payment method and get the response to calculate taxes

wild lynx
#

I mean you say yes but I have never seen anyone do this

#

I'm surprised it even works since there usually needs to be a "gesture" like a real click to trigger that. I would have assumed it'd break Apple's rules

old arch
#

the user clicks on google pay or apple pay to open the modal

wild lynx
#

But okay as much as I hate videos usually, this was really clear about the problem

#

We never intended this click to trigger any UI change. I honestly have never seen anyone do this. You trigger the thing from a callback event of ours and I'm surprised it doesn't break

old arch
#

yeah the problem is the chain of events, we can't create the payment intent until we calculate taxes, we cant calculate taxes until creating the payment method and getting the response, and then we cant create the payment method until we submit the payment element

#

So we are doing this:

    const { elements } = this.props;
    const { paymentElementStatus } = this.state;

    if (elements && prevProps.elements !== elements) {
      const paymentElement = elements.getElement('payment');
      const cardElement = elements.getElement('card');

      if (cardElement) {
        this.setState({ cardElement });
      }

      if (paymentElement) {
        this.setState({ paymentElement });
        paymentElement.on('change', (event) => {
          this.setState({ paymentElementStatus: event });
        });
      }
    }

    const shouldSubmitPaymentElement =
      paymentElementStatus?.complete &&
      prevState.paymentElementStatus !== paymentElementStatus;

    submitPaymentElement(
      shouldSubmitPaymentElement,
      elements?.submit,
      this.handleError,
      this._createPaymentMethod,
    );
  }
#

and:

  shouldSubmitPaymentElement,
  submit,
  handleError,
  createPaymentMethod,
) => {
  if (shouldSubmitPaymentElement) {
    const { error } = await submit();

    if (error) {
      handleError({ message: error.message });
    } else {
      await createPaymentMethod();
    }
  }
};
wild lynx
#

Yeah I really can't think of an alternative here. You're in a way abusing the behaviour of our change event. I totally get your thinking, but definitely not something we want.
You need your own button for this. If you use the defer intent flow, you can have that button be something like "Go to confirmation page" or whatever where you finish the calculation with tax and such and then are ready to confirm for real.
I really don't think you're going to get any alternative to this honestly, this is the right way to build an integration like yours and how most websites I've seen who handle tax too do it

#

@reef current I have to run so leaving this thread back to you as you have some original context on it and I think it boils down to "you can't do this"

reef current
#

๐Ÿ‘‹ give me a minute to catch up

old arch
#

ok thank you! take your time!

wild lynx
#

the video is a great way to understand the issue after all so I would say watch it ๐Ÿ™‚

old arch
#

lol thanks

reef current
#

Oh yeah we discussed this yesterday

#

@old arch so we talked about workarounds yesterday for re-opening the Google Pay modal without selecting a different PMT

#

Is that still what you are working on?

old arch
#

yep! so the payment element does not have a click event to listen to, so I tried the focus event, but the modal opens so the focus is off of the payment element, and then when it closes, it automatically refocuses to the payment element... so if we are checking for focus on the payment element, and no change to the payment element (i.e. the payment method stays google pay) we will continuously be calling elements.submit()

reef current
#

My test didn't automatically refocus the Payment Element when closing the modal ๐Ÿค”

old arch
#

hmmm well thats interesting

#

I wonder what the difference is

reef current
#

Testing again real quick

old arch
#

ok

reef current
#

Oh wait

#

I was using a click handler yesterday to test

wild lynx
#

(I still think this is really brittle, whatever we do with focus we 100% could change this overnight without thinking twice)

reef current
#

So yeah never mind that is why your focus stays

#

And yes, I agree, I would still just recommend going the click handler route

#

Which is what we discussed yesterday

old arch
#

how though? the payment element doesnt seem to expose the click handling to us the same way it does with focus, change, blur, etc.

#

I tried adding an onClick to the payment element and it does not work

#

I agreee, click handler would be the best, given the situation

reef current
#

No I mean you have your own click/submit handler

#

You don't listen for one of the Events at all

#

That isn't what those are designed for.

#

So you have a button that says "add PaymentMethod" or something that you customer clicks on

old arch
#

I see what you're saying