mkoenke

[rancid notch]

Hi 👋 do you have a test site where I can see this behavior, I'm having a bit of trouble trying to visualize what you're describing.

Like are you seeing previously entered payment details being persisted, or is this more focused on the payment method types that are offered to the customer?

[gritty ruin]

I don't have a test site, it is more focused on the payment method types... Like if a user selects google pay, and the closes the modal without approving the purchase, we want to be able to somehow destroy and re render a new payment element where the payment method type is set to card. But when we try to do this, we can destroy and create a new payment element, but when we mount it, it is exactly the same as the one we just destroyed, and google pay is still selected

its as if the state of the old payment element is being remembered and used in the new element

[rancid notch]

Hm, can you share the code you're using currently to try to get rid of the Payment Element?

I just tried in my test site, and destroying the Payment Element then creating a new one did not cause my previous Google Pay selection to persist. I'm always landing on the Card tab in the newly created element.

[gritty ruin]

very interesting! sure hold on a second

This is the code:

  isApplePayAllowed,
  countryCode,
  disabled,
  error,
  elements,
  handleOnChange,
  isSubscription,
  paymentElementEnabled,
  styles,
}: StripeElementProps) => {
  let paymentElement = null;

  if (elements){
    paymentElement = elements.getElement('payment')
  }

  if (error && paymentElement){
    paymentElement.destroy()
    paymentElement = null
  }

  if (paymentElement == null && elements ){
    paymentElement = elements.create('payment', setOptions(countryCode, isSubscription, isApplePayAllowed))
    paymentElement.mount('#payment-element-root')
  }

  if (paymentElementEnabled) {
    return (
      <div id='payment-element-root'>
      </div>
    );
  } else {
    return (
      <CardElement
        onChange={handleOnChange}
        options={{
          style: styles,
          disabled: disabled,
        }}
      />
    );
  }
};

[rancid notch]

Very interesting, because I see you're also using .destroy() which is what I did. I don't have a ton of context on how the Payment Element decides what order payment method types should be displayed in, but I'm wondering if it is detecting some signal that is causing it to believe surfacing Google Pay first is the best option.

One thing you could do, is explicitly take control of the order of payment method types. You can use paymentMethodOrder when creating the Payment Element to do that:
https://stripe.com/docs/js/elements_object/create_payment_element#payment_element_create-options-paymentMethodOrder

[gritty ruin]

the weird part is that when we render the first time, it defaults to card

I added the paymentMethodOrder but it didnt change anything

[rancid notch]

Weird, that almost makes it sounds like it's being unmounted/remounted, rather than being destroyed and having a new one created.

[gritty ruin]

do you think it may have something to do with using the deferred intents flow?

so were not creating a payment intent until we hit the server

[rancid notch]

Hm, maybe, let me try again on another one of my test sites that uses deferred intents.

[gritty ruin]

ok thanks!

[rancid notch]

Oohh, interesting, I do see that behavior in the deferred intents flow.

[gritty ruin]

well thats good I guess, then im not losing my mind lol

[rancid notch]

Haha, always a plus! 😄

I'm poking on my test flow some, and am noticing that if I recreate the instance of stripe.js (I'm working in a JS/HTML project instead of React) then the Payment Element is being re-rendered in the default state I saw originally.

[gritty ruin]

interesting! So in a react implementation, we would have to instantiate stripe again, render a new elements instance to wrap the payment form, and then render a new payment element?

[rancid notch]

Yeah, that aligns with what I'm thinking. Create a new stripePromise, use it to recreate the Elements wrapper, then recreate the Element.

That being said, as a customer, I think I'd be a bit surprised if I had previously selected a payment method type, then something suddenly changes and I have to reselect it.

So I can see value in stripe.js remembering the previously selected option if an element recreation is required.

[gritty ruin]

sure, yes I understand why that makes sense...

ok cool, thanks so much for your help! I appreciate it!