wcccom Subscriptions: ensure they use setup_future_usage: 'off_session'

[v18]

WooCommerce.com has a custom subscriptions engine. We'll need to make sure the initial payment on checkout is marked as a subscription so that the request uses the setup_future_usage: 'off_session' parameter.

@dwainm will be able to help us find a way to see if a payment is a subscirption & help test our PRs.

Related: https://github.com/woocommerce/woocommerce-gateway-stripe/pull/962

cc @dwainm @RadoslavGeorgiev @DanReyLop @allendav

[v18]

@dwainm for WC Subscriptions, the Stripe extension uses the WC Subscriptions function wcs_order_contains_subscription to see if an order contains a subscription. Is there something similar we could use for wc.com? If not, I think we'll need to have something like that created.

[dwainm]

We use standard products so this approach will not work for wc.com. If this is not something that will work for 80% of merchants I think we should consider filtering it in this file: https://github.com/Automattic/woocommerce.com/blob/master/plugins/wccom-plugins/stripe-gateway-customizations/includes/class-wccom-stripe-gateway-customizations.php

[v18]

We use standard products

That's great to know 👌

Are all products on wc.com subscriptions? 🤔

[dwainm]

It will be helpful to share a quick overview of how subscriptions work:

All WooCommerce.com subscriptions are simply a license key. Here is how we store a license key:

For each order, we generate a new entry as you can see above and link it to the order.

This is not a special post type or product type. We do this for any kind of product. Each product in order gets it's own unique license key, we prefer to call it subscription keys (recurring).

This is how we represent it on the order edit screen:

This key is also used to track user subscription activations and when we do renewals.

This key is also moved from order to order. For a renewal we generate a new order ( a copy of current order ) then we charge the order total. On success, we update the key in the db and point it to a new order. We do not track the history here ( this is our legacy)

To summarise; all products are simple products using standard WC core features. We tacked on a subscription system that links to both product and orders.

[allendav]

As @dwainm suggests, could this be implemented using filter(s) which woocommerce.com custom code could hook into?

[yoandm]

The plugin still uses Stripe Source API no (to save the card) no ? We can read a disclaimer about it and SCA here : https://stripe.com/docs/sources/cards

It's normal ? If the card needs to be "re authentified", is-it possible ?

[RadoslavGeorgiev]

The plugin still uses the Sources API. While Stripe recommends switching to the PaymentMethods API, there is nothing which suggests what sources are less reliable in terms of 3DSv2 and etc.

[yoandm]

I just had a chat with someone from Stripe. He told me that all new sources, cards created after September 14 must absolutely use Payment Method API. You don't have this information ? SCA is definitely not easy.

[DanReyLop]

@yoandm In order to make the September 14th deadline and don't go crazy, we decided not to migrate the whole plugin to use the new Payment Methods API. According to this document, using Sources & Customers in place of Payment Methods when creating a Payment Intent will work perfectly. That has been our experience in testing so far.

[yoandm]

Yes I know. I tested too and it works. He gave me the same link. But it told me after September 14th new cards must use Payment Methods API.

[thorsten-stripe]

@yoandm sorry for the confusion here. While setting up new cards via the methods shown here (https://stripe.com/docs/payments/cards/reusing-cards) will automatically create PaymentMethod objects, both PaymentIntents and SetupIntents are compatible with sources, see also https://stripe.com/docs/api/setup_intents/confirm#confirm_setup_intent-payment_method.

One thing to mention though is in order to confirm a SetupIntent (or a PaymentIntent with setup_future_usage param) the card source needs to be already attached to the customer object and both the source ID (as payment_method parameter value) and the customer ID need to be supplied, e.g.:

[yoandm]

Oh ok. This is a very good news. Thank you.

[yoandm]

@thorsten-stripe If we test with card 4000002500003155, we've exactly the same behaviour that SCA after September 14 (for charge, intent, saving cards, re charge after saving, etc). It's exact ? I just want to be sure because SCA is not insignificant for future conversions.

[thorsten-stripe]

@yoandm yes, correct, that's the expected behaviour for cards once SCA is enforced.

[planetahuevo]

I am having issues already with banks that are enforcing this measures even before the deadline so I am getting renewals failing due to this. I created this issue https://github.com/woocommerce/woocommerce-gateway-stripe/issues/988 before I found this one. When do you think you can issue a fix for this problem? Thanks

[thorsten-stripe]

@planetahuevo it is unlikely that this is related to SCA as enforcement will be gradual, see https://support.stripe.com/questions/strong-customer-authentication-sca-enforcement-date. I've replied on #988.

[allendav]

Should this be in this repo? Seems like it should be in a woocommerce.com related repo

[RadoslavGeorgiev]

I am pretty sure that https://github.com/Automattic/woocommerce.com/commit/889e747ba9c456ecfea49dcce57ca1c34ea6ec9e addresses this. @dwainm please confirm, and if true, close this issue.

[dwainm]

@RadoslavGeorgiev This is handled on our side, the filter is sufficient.

The data we send can be confirmed on the screenshot here: https://github.com/Automattic/woocommerce.com/pull/6386#issue-309947784