#mkoenke-paymentelement-click
1 messages ยท Page 1 of 1 (latest)
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?
Yes, we are trying to know when the click event is fired for google pay or apple pay
to open the modal
I had a conversation yesterday about this situation: #dev-help message
Are you using our deferred intents flow or the flow where you create the intent before rendering the payment element?
deferred intents
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?
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()
Ah, so what I think you may want to do is subscrive to the change event, that will tell you what PM the user is currently on. So when the user hits submit, you will know if they are trying to pay with apple or google pay https://stripe.com/docs/js/element/events/on_change?type=paymentElement
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?
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
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
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
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.
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
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
mkoenke-paymentelement-click
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?
@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
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?
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.
hmmm ok, sorry if it is not clear, let me try to explain, give me few minutes to organize my thoughts
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
Is there any chance you could share real code and text explanation versus listening to a video like that ๐
yessss lol sure
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"?
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
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
the user clicks on google pay or apple pay to open the modal
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
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();
}
}
};
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"
๐ give me a minute to catch up
ok thank you! take your time!
the video is a great way to understand the issue after all so I would say watch it ๐
lol thanks
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?
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()
My test didn't automatically refocus the Payment Element when closing the modal ๐ค
Testing again real quick
ok
(I still think this is really brittle, whatever we do with focus we 100% could change this overnight without thinking twice)
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
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
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
I see what you're saying