Add saveTokenComponent support to express payment methods

[paymentplugins]

Is your feature request related to a problem? Please describe.

At the moment only regular payment methods registered using registerPaymentMethod support the savedTokenComponent component. If the saved payment method's gateway_id does not map to a payment method registered via registerPaymentMethod it is not rendered in the list of saved payment methods.

It is common for a returning customer to have a saved payment method like GPay that is an express payment method.

Describe the solution you'd like

Customers should be able to select a saved payment method that is also an express payment method. Currently it looks like only saved payment methods that have a gateway registered via registerPaymentMethod are presented.

Describe alternatives you've considered

Registering an express payment method as a regular method and hiding it's content located in the wc-block-components-radio-control. This is not ideal because it requires direct DOM manipulation and there could be unintended consequences of registering the payment method as both express and regular.

Additional context

Add any other context or screenshots about the feature request here.

[mikejolley]

Can we have a little more information about the use case here (i.e. which payment methods support this)?

What would the advantage be of using a "saved card" in regular checkout for a customer, vs just using Express again?

Express Payment Methods are designed to let you skip regular checkout and use a "saved card" stored elsewhere, like in your browser. I'm struggling to see how this would be reusable in the context of the regular checkout, or even how regular checkout would have access to the tokens etc generated vs the express flow.

[paymentplugins]

Hi @mikejolley,

Thank you for the reply.

_Can we have a little more information about the use case here (i.e. which payment methods support _this)?__

The payment methods I have in mind are Google Pay, Apple Pay, and PayPal. I imagine block support for plugins like WooCommerce Subscriptions and WooCommerce Pre-Orders is on the road map. Those plugins require that payment methods be tokenized so payments can be processed in the future or in a recurring capacity.

Let's say a customer purchased a subscription 6 months ago using Apple Pay and at that time the merchant's site was using the checkout page shortcode. Since then, the merchant has switched over to the blocks checkout. The customer returns to purchase another subscription product and they see the Express payment options but not their tokenized Visa card they used 6 months ago. They choose Apple Pay in the express section and use the same Visa card they used 6 months ago. WCS requires the payment method to be tokenized for recurring payments so they now have the same payment method tokenized twice in the WooCommerce tokens table and with the payment processor. Depending on certain settings, payment processors won't allow the same payment method to be saved twice as a security measure. That could result in a checkout page error and the customer would not be able to proceed with their purchase.

_What would the advantage be of using a "saved card" in regular checkout for a customer, vs just using Express _again?__

I think the advantage here is a customer's billing and shipping info is already pre-populated from a previous order and if their express payment method is saved from a previous order that required tokenization, they can just select that saved payment method and proceed. It also avoids duplicate payment methods in the WooCommerce tokens tables and with the payment processor.

Express Payment Methods are designed to let you skip regular checkout and use a "saved card" stored elsewhere, like in your browser. I'm struggling to see how this would be reusable in the context of the regular checkout, or even how regular checkout would have access to the tokens etc generated vs the express flow.

Although the payment method is stored elsewhere, like in the Apple Wallet, the payment method still has to be tokenized by the payment processor so it can be re-used. That tokenized reference must also be stored in the WooCommerce tokens table so it can be applied to future payments.

[mikejolley]

I imagine block support for plugins like WooCommerce Subscriptions and WooCommerce Pre-Orders

Subscriptions are already supported afaik.

I think the advantage here is a customer's billing and shipping info is already pre-populated from a previous order

This is not an advantage over the express checkout flow because it too has address pre-populated. What's more, these addresses are always current.

Let's say a customer purchased a subscription 6 months ago using Apple Pay and at that time the merchant's site was using the checkout page shortcode. Since then, the merchant has switched over to the blocks checkout. The customer returns to purchase another subscription product and they see the Express payment options but not they're tokenized Visa card they used 6 months ago. Depending on certain settings, payment processors won't allow the same payment method to be saved twice as a security measure. That could result in a checkout page error and the customer would not be able to proceed with their purchase.

In this case I'd expect the user to again bypass checkout and use the express method, but can you back that statement up about the limitations on token reuse? If this is documented it shows a genuine need for token reuse from express methods. If not, I think the express flow is still beneficial over regular checkout flow.

[paymentplugins]

Hi @mikejolley,

but can you back that statement up about the limitations on token reuse? If this is documented it shows a genuine need for token reuse from express methods. If not, I think the express flow is still beneficial over regular checkout flow.

Braintree used to support a property failOnDuplicatePaymentMethod but upon review they have now changed this prop to be ignored by express payment methods. So from a processor standpoint, it appears adding duplicate cards is no longer an issue.

If not, I think the express flow is still beneficial over regular checkout flow.

I agree. What I am saying is if a customer's saved express payment method isn't shown in the list of available saved payment methods, they are going to keep saving the same credit card every-time they purchase a subscription using express.

If I have 5 active subscriptions with a merchant and I used VISA ****1111 stored in my Apple Wallet for all 5, that will result in the same payment method being shown 5 times on the My Account > Payment Methods page. From a user experience context, that would be very odd to see my credit card duplicated 5 times.

[paymentplugins]

As a follow up to my previous reply; one way to offset the issue of an express payment method being duplicated is to register the payment method as both an express and regular payment method.

That would result in the payment method being rendered in the express section and the regular payment method section. The affect of this would be that all of the payment methods saved during the express process would be available in the saved payment methods section.

Is that what the developers intended for this particular scenario?

[nerrad]

To make sure I'm understanding the issue correctly, I'll write a summary here and maybe you can confirm whether I'm correct.

• A shopper purchases a subscription using the checkout block and an express payment method.
• Woo is saving the token from the express payment method and attaching to the subscription.
• If the shopper revisits the checkout in the store to make a different purchase, even though there is a saved token for their card, it won't show up. So if the shopper pays using the express payment method with the same details, a new token is created and added to the shopper's account.

There's some assumptions I'm making in the above statements:

• That this describes the behaviour you are reporting accurately.
• The token is indeed being saved for express payment methods (and verified by checking the shortcode checkout flows where it should show up there).

If the above is correct, there are some additional considerations in accounting for the shopper experience:

• If the shopper isn't logged in, they won't likely see the token anyways and likely will make another purchase using the express payment methods (I'm not sure if the shortcode checkout flow works differently or already accounts for this somehow).
• Even if things are fixed so the saved token does appear correctly for those created via express payment methods, the current location of these saved tokens might not be seen by the shopper given the placement of the express payment area and the high likelihood the shopper would still choosing the express payment method again. There'd need to be some exploration around how this could be improved (if determined its a significant enough problem).
• What if the express payment method is used to purchase other products elsewhere on the store (via the Cart or individual products)? There would still be a new saved token created in those cases too right?

Before actioning any further on this issue, I'd be really interested in knowing what the behaviour is in current shortcode flows involving express payment methods and the presence/lack of token creation/usage in those flows. This could inform what steps we potentially take with the new flows.

However, for now, given this has larger ramifications than simply showing the saved token, and given it's not a significant issue for the shopper to go through the express payment flow again for new purchases - this isn't a high priority issue and I wouldn't want to make any quick fixes here.

As a follow up to my previous reply; one way to offset the issue of an express payment method being duplicated is to register the payment method as both an express and regular payment method.

I wouldn't really recommend this approach be taken and may surface other problems (besides the UX likely being poor for the shopper).

[paymentplugins]

@nerrad Thank you for your well-thought-out reply.

Your summary and assumptions are correct.

If the shopper isn't logged in, they won't likely see the token anyways and likely will make another purchase using the express payment methods (I'm not sure if the shortcode checkout flow works differently or already accounts for this somehow).

Plugins such as WooCommerce Subscriptions do not allow guest checkout since a Wordpress user account is required to purchase the subscription. If a user isn't logged in and they enter a billing email address for an existing account, they are asked to login.

What if the express payment method is used to purchase other products elsewhere on the store (via the Cart or individual products)? There would still be a new saved token created in those cases too right?

Yes, a new saved token is created in the case of a subscription being purchased from a product or cart page, where tokenization is required. In those instances, I have seen returning customers skip the product page or cart page payment buttons and use the checkout page since they know they already have a saved payment token from a previous purchase. This happens using the checkout shortcode. Things are a bit different with the checkout page shortcode because there isn't a standardized express payment section. All available payment methods like Apple Pay, GPay, etc are displayed in the payment method list located below the order details. The saved payment methods are displayed in that section.

However, for now, given this has larger ramifications than simply showing the saved token, and given it's not a significant issue for the shopper to go through the express payment flow again for new purchases - this isn't a high priority issue and I wouldn't want to make any quick fixes here.

Ya I agree it's not a huge issue. Mostly I just think returning customers might be surprised/confused if they navigate to the My Account > Payment Methods section and see a large number of duplicate saved payment methods. There are ways around this though that plugin developers can explore. For example, processors tend to include some unique identifier for a payment method that is the same across duplicate payment methods. The dev can just write some code that checks to see if that identifier exists and if so, use the token that's already saved.

I'm good if you want to close the issue.

[nerrad]

Thanks @paymentplugins, I'm going to go ahead and close the issue for now.