Stripe Webhook/Frontend Checkout Fails with Stripe Gateway Plugin for WooCommerce's New Checkout Experience When Total Amount is $0 Due to Free Trial Period

[ydwnj]

Describe the bug When using the Stripe Gateway plugin for WooCommerce with the Subscriptions for WooCommerce plugin, an issue occurs during checkout if the total amount due is $0 (due to a free trial period). Instead of proceeding to the order confirmation page, the frontend displays a Cannot read properties of undefined (reading 'match') error above the card payment block. This issue does not occur when the total amount due is greater than $0 or when the plugin is set to legacy checkout mode. This issue persists on both live and test mode.

To Reproduce Steps to reproduce the behavior:

1. Add a subscription product to the cart that includes a free trial period, resulting in a $0 total at checkout.
2. Go to the checkout page on my WooCommerce site.
3. Enter payment details using the Stripe payment gateway.
4. Submit the order.
5. Observe that the frontend does not redirect to the order confirmation page and instead shows a Cannot read properties of undefined (reading 'match') error above the card payment detail block.
6. The order is successfully submitted, customer and admin receive the order confirmation email. Subscription is successfully created in the backend. Payment/Order does not show up in Stripe's webhook logs. No errors in console.

Behavior in Legacy Stripe Mode:

1. Submit the order.
2. Customer is redirected to Order Confirmation Page and receives a confirmation email. Admin receives "order received" email. Subscription is created in the backend.
3. Webhook connection successful between WooCommerce and Stripe. A "POST /v1/payment_methods" log is created with customer and order details. Customer is not added in Customer table and order does not show up in Transactions table within Stripe.

Expected behavior After submitting payment details, even if the total amount due is $0, the user is redirected to the order confirmation page upon successful payment processing. Customer's preferred payment method detail is saved in their account and in Stripe. Order triggers confirmation emails for customer and admin. Stripe webhook succeeds.

Screenshots

Environment (please complete the following information):

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
  • WordPress Version 6.6.1
  • WooCommerce Version 9.1.4
  • Stripe Plugin Version 8.6.1 -Active plugins (25):
    1. Gravity Forms by Gravity Forms – 2.8.15
    2. BookingPress Pro - Appointment Booking plugin by Repute Infosystems – 3.9
    3. BookingPress Appointment Booking by Repute Infosystems – 1.1.8
    4. BookingPress - Google Calendar Integration Addon by Repute InfoSystems – 2.7
    5. Elementor Pro by Elementor.com – 3.23.3
    6. Elementor by Elementor.com – 3.23.4
    7. Essential Addons for Elementor - Pro by WPDeveloper – 5.8.17
    8. Essential Addons for Elementor by WPDeveloper – 5.9.27
    9. Gravity Forms Conversational Forms Add-On by Gravity Forms – 1.4.0
    10. Gravity Forms Mailchimp Add-On by Gravity Forms – 5.4.0
    11. Gravity Forms Partial Entries Add-On by Gravity Forms – 1.7
    12. Gravity Forms Quiz Add-On by Gravity Forms – 4.1
    13. Gravity Forms reCAPTCHA Add-On by Gravity Forms – 1.5.0
    14. Gravity Forms User Registration Add-On by Gravity Forms – 5.3.0
    15. Gravity SMTP by Gravity Forms – 1.3.0
    16. MC4WP: Mailchimp for WordPress by ibericode – 4.9.14
    17. PowerPack Lite for Elementor by IdeaBox Creations – 2.7.26
    18. Rank Math SEO by Rank Math – 1.0.225
    19. Speed Optimizer by SiteGround – 7.6.3
    20. Security Optimizer by SiteGround – 1.5.2
    21. Subscriptions For WooCommerce by WP Swings – 1.7.0
    22. Force Authentification Before Checkout for WooCommerce by Luiz Bills – 1.4.4
    23. Preview E-mails for WooCommerce by Digamber Pradhan – 2.2.13
    24. WooCommerce Stripe Gateway by WooCommerce – 8.6.1
    25. WooCommerce by Automattic – 9.1.4

Additional context I haven't tested if the subscription triggers after the free trial is over. I just set up a product with 1 day free trial, and process a payment every day to see how it triggers and captures the customer data table to charge the card they input. There is no card saved on file on the WooCommerce side for the customer. Will update here when it triggers.

[james-allan]

Hey @ydwnj. Thanks for filing this issue.

The issue here is caused by the WooCommerce Subscriptions plugin. When purchasing free trial subscription products via the block checkout, the WooCommerce Subscriptions product doesn't communicate to WooCommerce core that the order needs a payment method and so WooCommerce isn't expecting payment processing to occur.

We have a fix for it here and it will go out in the next Subscriptions release. https://github.com/Automattic/woocommerce-subscriptions-core/pull/642

[ydwnj]

Thank you, I checked out your fix; however, I'm using the Subscriptions for WooCommerce plugin so I don't have the subscription coupon type. I did try to use a 100% off coupon on a signup fee > $0 with a trial period to see if anything reacts to that scenario, but I still get the same error.

It's interesting that the same error is occuring on both plugins. This is the first time I'm using a subscription plugin so I don't have any baseline expected behavior. Were free trials always processing correctly in the past? Is this error being caused by recent WooCommerce updates?

I'm curious because your plugin update won't help me if it's a fix, vs. a WooCommerce base issue that needs to be updated to factor in $0 recurring subscription scenario.

[james-allan]

Ah ok. We'll need to look into it from the Stripe plugin side too. I just have a feeling that approach is somewhat suppressing the error and the checkout isn't handling the situation correctly.

We had the issue in the official WooCommerce Subscriptions plugin so I fixed it there, but as @Mayisha mentioned when she tested that PR, she couldn't replicate the bug when using the legacy checkout experience. With that in mind there's a way we could prevent the error from the Stripe plugin side too.

[ydwnj]

That would be great! Any guess how long for a fix? My client is eager to go live, so for now, this is what I'm doing:

1. Create a free product so the credit card block does not appear.
2. Trigger an email to the customer at the end of the trial period with a link to checkout with the subscription product.
3. They'll enter their payment details and submit order. Stripe saves the payment details, recurring subscription proceeds as intended.

It's not the ideal customer journey and would prefer a more seamless transaction process.

[james-allan]

Hey @ydwnj,

Sorry for the lengthy response. I've been looking into what it would take to fix the error on the Stripe plugin side. However, as I mentioned in my last message, what we can do from the Stripe plugin side only suppresses the error rather than fixing the root issue.

I'm not deeply familiar with the subscription plugin you're using, but you mentioned that at step 2, you send an email to your customer at the end of the trial period with a link to checkout. Is that checkout also free ($0), and is it just to collect payment information?

For some background, the error occurs due to a mismatch in how WooCommerce Core handles things on the Block checkout. The payment methods are displayed at checkout because the cart requires payment, but payment processing only occurs if the order requires payment. In this scenario, the cart needs payment, but the order doesn't. As a result, when the customer submits the checkout, the Stripe payment gateway expects a payment response from the server, but instead, it receives a response indicating that payment wasn't needed.

On the Stripe gateway side, we can address this error by checking the server response before assuming it's a payment response. However, this leads to other issues. If your customer signs up with a 3D-Secure card, and WooCommerce Core doesn't attempt any payment processing, the card is never authenticated, leading to future payment failures.

To recap, we can fix the error message from the Stripe side, but if a customer signs up with a 3D-Secure enabled card, their future payments will fail.

The real fix for this error involves ensuring that WooCommerce processes this request as a payment request, even if the order doesn't require payment. For reference, that's the fix we applied to the WooCommerce Subscriptions plugin.

I can reach out to the WooCommerce Core developers, but it might also be worth reaching out to the Subscriptions for WooCommerce by WP Swings team.

[ydwnj]

james-allan

No worries - I appreciate you looking into this for me. I've opened up a issue with Subscriptions for WooCommerce. I'm new to here so I don't know how to reference them / call their attention to this thread.