moistcode - Payment Elements | Stripe Developers | Page 1

true thicket Jun 2, 2022, 6:08 PM

#

Hi 👋

twin oracle Jun 2, 2022, 6:08 PM

#

Hiya Snufkin!

#

It also works just fine on my iPhone too...

true thicket Jun 2, 2022, 6:17 PM

#

Okay so where is this code running. In what context is this being used?

twin oracle Jun 2, 2022, 6:17 PM

#

Also FYI I'm not expect any fixes. Just if you came across this scenario before. If not, I'll continue the expedition to figuring out why it doesn't work on just my machine 😄

#

It's on the web if that answers your question.

true thicket Jun 2, 2022, 6:19 PM

#

So what are you trying to achieve with the Payment Element exactly? The link is for a payment request button.

twin oracle Jun 2, 2022, 6:22 PM

#

Right. The link is for the payment request button because my research resulted in the error I got being related to the Payment Request button but I'm not using it which is why I'm a tad bit confused by it. This is why I'm wondering if there was a case where we would need to handle this case with the Payment Element. The Payment Element is being used to obtain the users payment method in order to update a payment method for a subscription we use.

true thicket Jun 2, 2022, 6:28 PM

#

Okay and you are seeing this error when? When the Payment Element loads? When the user tries to use Apple Pay?

twin oracle Jun 2, 2022, 6:38 PM

#

When a button is clicked using a mouse that attempts to setup the users payment method when a user selects Apple Pay.

true thicket Jun 2, 2022, 6:39 PM

#

Okay so the Apple Pay button rendered as part of the Payment Element.

twin oracle Jun 2, 2022, 6:40 PM

#

Yup

true thicket Jun 2, 2022, 6:45 PM

#

Okay so what browser is this occurring in?

#

What devices?

#

It sounds like this might be related to some browser changes

#

Is there a URL we can test this out?

#

Can you share the .confirmPayment or .confirmSetup code?

twin oracle Jun 2, 2022, 6:55 PM

#

Desktop Safari 15.5 on my MBP is the only one that gives me that error.
Desktop Safari 15.3 doesn't seem to have that issue.

My iPhone on iOS < 15.5 didn't have that issue but I'm updating it to iOS 15.5 right now to see if I can replicate it.

I don't have a URL but I can try to come up with one after all my meetings to reproduce the error.

Here's a snippet. Let me know if you need more context.

    let {
      setupIntent,
      error: confirmStripeSetupError,
    } = await stripe.confirmSetup({
      elements,
      // TODO: At some point we may start supporting payment methods that will
      // require some sort of redirects such as bank redirects. That work will
      // be completed in:
      redirect: 'if_required',
      confirmParams: {
        /* eslint-disable camelcase */
        payment_method_data: {
          billing_details: {
            name,
            address: {
              line1,
              line2,
              city,
              state: region,
              postal_code: postalCode,
              country,
            },
          },
        },
        /* eslint-enable camelcase */
      },
    });

true thicket Jun 2, 2022, 6:55 PM

#

Is this code being called from within a gesture-handler? Like "on-click"?

twin oracle Jun 2, 2022, 6:56 PM

#

Yup!

true thicket Jun 2, 2022, 6:56 PM

#

Okay so this whole thing is an event handler for an on-click event?

twin oracle Jun 2, 2022, 6:56 PM

#

It's part of the process that starts when the user clicks on a button, yes.

true thicket Jun 2, 2022, 6:57 PM

#

"part of the process". Can you zoom out and provide more context about what's going on there?

twin oracle Jun 2, 2022, 6:58 PM

#

Sure, there's an address part before this confirmSetup that processes the user's address and we end up passing it in the billing_details above. Nothing really fancy.

#

Okay so updating my iPhone to iOS 15.5 caused it to not work now. Gonna see if it logs the same issue.

true thicket Jun 2, 2022, 7:01 PM

#

Are you awaiting an async response from your server when you process the user address?

twin oracle Jun 2, 2022, 7:01 PM

#

Yup.

true thicket Jun 2, 2022, 7:02 PM

#

Okay that can exceed the gesture handler timeout threshold which means the button click is no longer considered a valid gesture

#

Apple may have adjusted the threshold in the most recent updates

twin oracle Jun 2, 2022, 7:03 PM

#

Yeah that sounds possible. Might need to move things around a little if that is the case. I'll try removing the address processing portion to see if that'll work.

true thicket Jun 2, 2022, 7:04 PM

#

Okay great. I'm heading out by my colleague @novel bear will be around to answer follow up questions.

twin oracle Jun 2, 2022, 7:04 PM

#

Thanks Snufkin!

#

Also hi Pompey! I'll dig into this again later but it looks like the update to iOS 15.5 on my iPhone also logs the same integration error.

novel bear Jun 2, 2022, 7:11 PM

#

Sounds good to me, let me know what you find when you dig further

oak notchBOT Jun 2, 2022, 8:42 PM

#

This thread has been archived. If you need help with anything else please ask in #dev-help or contact Stripe Support: https://support.stripe.com/contact

true thicket Jun 3, 2022, 3:48 PM

#

Hi @twin oracle what did you find?

twin oracle Jun 3, 2022, 3:49 PM

#

Thanks Snufkin! Give me one second to lay it out real quick. 🙂

true thicket Jun 3, 2022, 3:52 PM

#

While you're laying that out, a colleague of mine also found and shared the browser API spec that is responsible for identifying what counts as "user-initiated": https://html.spec.whatwg.org/multipage/interaction.html#user-activation-data-model

twin oracle Jun 3, 2022, 4:04 PM

#

To summarize, I have 4 different pages that have very similar implementations of <PaymentElement> with Apple Pay. I tested the hypothesis that it is due to the user gesture exceeding the timeout threshold which I now believe is true.

My two update payment pages perform two actions before the Apple Pay modal shows up and right after the user gesture. These actions are verifying that the user's session is valid and processing the address if the user changed it. I removed these actions one by one which did not resulted in Apple Pay working. However, removing both did. One action was about 250-350ms while the other was about 450-500ms long for a combined 700 - 850ms just from a few bits of data I gathered.

This hypothesis was further supported by testing another one of my pages that only come across an error with Apple Pay if the user changed their address and we'll need to process it first before showing the Apple Pay modal.

My last page, a subscription sign-up page, ended up working just fine and the reason is because it is a two-stage page. The first stage allows the user to select Apple Pay as a payment method and enter in their new address. Selecting the button to move to the second stage triggers the address validation process. On the final page, the user will then click on the subscribe button which will then show the Apple Pay prompt. This works since the address validation process isn't part of the gesture on the final stage.

A solution I going to bring up with my team is maybe turning the other pages into a multi-stage page as well.

#

On a similar note, it also looks like .confirmSetup() hangs in this scenario. It doesn't return an error object nor does it throw. I've wrapped it in a try catch with no luck. I'll try to set up a sandbox to reproduce this hang.

#moistcode - Payment Elements