woocommerce/woocommerce-gateway-stripe

Cannot manually enter account keys on live sites

Opened this issue · 9 comments

I was asked to forward a support issue on wordpress.org to this repo.

As WooCommerce addon developers, we have some automated end-to-end tests to run with the Stripe payment gateway.

Since version 8.0.0, it’s not possible to setup account keys manually and we just disabled our tests.

Now we’re back on that as we would like to restore our tests, but it’s becoming a big headache…

First of all, (if I understand correctly, correct me if I am wrong) we need to create a real Stripe account with real information such as personal/company information, valid bank account data, … and we cannot provide that for testing purpose only. We are not Stripe users, we just want to ensure Stripe is compatible with our addon.

Then, even if I hardly manage to create a real Stripe account (with random data), I see captcha when it comes to connect to Stripe from the “Connect or create an account” button. This is one more problem for our automated tests.

Could you re-evaluate the possibility to restore the advanced mode? (as it was in version 7.9.3)

Without that, I am afraid we will not manage to restore our automated tests on Stripe, which in the end could affect Stripe users…

Thanks!

@strategio You are correct that it currently is not possible to connect our Stripe extension to a test mode only Stripe.com account, i.e. an account created with just an email, and where live mode is unavailable.

Screenshot taken on 2024-06-24 at 14 26 18 UTC@2x

We are discussing internally what to do about this given our long-term plans for the extension.

Internal link: p1719233249354419-slack-CHG7MTCAF

Thanks for looking into this @aheckler.

If I may suggest one more thing, it would be OK for us if just have to set a constant in wp-config.php. It could be a WC Gateway Stripe constant, or maybe a specific value for the environment type on WordPress.

See also https://developer.wordpress.org/reference/functions/wp_get_environment_type/.

You might be able to use the wc_stripe_settings filter shown here to manually adjust values for the following:

  • test_publishable_key
  • test_secret_key
  • test_webhook_secret

However, that's not something I've tried myself, so I can't guarantee that everything will work 100% seamlessly. You'd need to do a bit of testing.

Thanks @aheckler,

The purpose of our automated end-to-end tests is to have a context very close to what the final user would have.
We click on buttons, fill forms, ... like the final user.
If we have to set custom filters (through a custom plugin), we are already diverging from what a real user would do.

And beyond that, I am not sure the filter hook you suggested will allow us to override all the needed settings.

In short, we don't want to hack the plugin just to have our test running.
Ideally, we just want to follow a user workflow, even if we end up using a discreet GUI element (like the link "Enter account keys (advanced)" that we used to have before 8.0.0).

@strategio Could you take a look at Step 3 from these instructions? I wasn't aware of this before, but if you start the connection flow then back out back to wp-admin, you can apparently still use the old keys interface. Does that work for you?

#2936 may be one to follow too. :)

Thanks @aheckler!

I've followed the workflow from #2936 (comment): temporarily downgrade to 7.9.3 in order to set the test keys, then update to the latest version to continue our tests.

At least that will allow us to restore our automated test.

However, it would be great if you could offer an alternative with the latest version.
I think this ticket still makes sense.

However, it would be great if you could offer an alternative with the latest version.

Did you try the steps explained in Step 3 here? Those should work with the latest version I think.

Hi @aheckler!

Sorry for my late reply, I was away from work for some time...

We ended up using version 7.9.3 to setup our test site and then update the addon to the latest version to continue the execution of the test.

This is far from optimal but good enough for now...

Thanks!