Unable to remove a terminal

Hi Simon,

Stripe terminals do not have account reciprocity which means if you are moving from one account to another or between a test mode account and live mode account, that terminal will not exist on those other accounts, so if the data isn’t removed before you make that change, it cannot be deleted without either (a) removing it manually from the database, (b) wiping the plugin’s settings, or (c) changing your stripe account ID or live/test mode status to match what it was previously, then you can delete the device.

Option C is obviously the simplest but I do understand that sometimes people lost their Stripe accounts and need to create new ones for various reasons.

Option B is a bit more complicated since it requires making tweaks to the serialized values in the wp_options table, which is not something I’d recommend doing as it can create issues elsewhere.

For Option A (to wipe the plugin’s settings), open and edit your WP Config file, and within it, define a constant “WC_REMOVE_ALL_DATA” with value TRUE. Then deactivate the plugin and click the the “delete” button on the plugin settings to trigger the uninstall script. This should wipe the plugin’s data. Then you can reinstall the plugin and re-enter the settings data.

Hi Simon,

Haven’t heard back from you, so we’re assuming you’ve sorted the issue out. We’ll mark this as resolved.

I reinstalled. Still didn’t work, but turns out that Stripe API was still on 2020 version. I updated it to use the 2022 and all started working. Thanks for your help.

Thanks Simon, we really appreciate you sharing your findings.

That said, an API upgrade wouldn’t be the correct solution. It’s more likely that whatever changes were made on Simon’s account indirectly factored into his desired results. There are a few reasons for this:

1. The “upgrade” feature that Stripe offers on your account doesn’t have any bearing on our plugin. Any Stripe software you install will specify the API version within its own code and you’ll find that your account will show activity for all versions going back to the beginning of your account. For example, you may find the WooCommerce Stripe Gateway using the 2019 API. Your Stripe Account will specify the versions you have running on your account. If, however, you had an outdated WooCommerce Stripe Gateway plugin, which drives the API for our plugin, that would be a different story (but your Stripe account settings aren’t related to that).
2. All of our functionality is built and tested in the 2019 and 2020 API versions, not 2022 (the 11-15-22 release is too new for us to have done any updates on our plugin with it). Obviously we’ll do forward compatibility testing but it isn’t as if we’ve built this on 2022 and not supported 2020 (the opposite would be true).
3. The migration (via backup/restore) is the causal factor here and it’s a very common one. The reader data is stored in the database upon registration, so when you do a migration via backup and restore, you’re carbon-copying data that was stored specifically for a different server and/or account to a new server and/or account. Therefore the new server or account can’t delete the reader because it doesn’t exist to be deleted (it’s orphaned data that’s displaying on screen).
4. The plugin uninstall process when “WC_REMOVA_ALL_DATA” is defined as true will wipe the plugin’s wp_options option_value field competely, thereby resulting in no data being present on the plugin at all. When the plugin is activated and a valid Stripe account is provided, upon first load it will automatically import the readers from that account. This means that if that process above was run, Simon would have either had (a) no readers visible in the settings or (b) the readers visible in settings would have been pulled directly from his stripe account via API which means it would have been delet-able.
5. Even if bullets 1 and 2 weren’t true (which they are), if you had an incompatible payload, you wouldn’t get a “no such reader” response with a recognized reader ID on a DELETE method, you’d get a 400 bad request reponse.

We’re very glad to hear that Simon has reached resolution with his account. We hope that the information above helps clarify any misgivings about how our plugin works.