arcanedevops

We aren’t involved in invoicing, so you’ll have to contact the plugin that is.

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.

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 Phil,

The WisePOSE is the preferred device, so that’s the best one to use. Both of those prompts occur prior to the submission, so you would see both before the error message. I can’t atest to whether you have it in test mode, that’s something you’ll have to check within your settings.

Regarding Point of Sale for WooCommerce, we are not the developers of that plugin. The checkout procedure for our plugin can be performed with WooCommerce’s existing frontend checkout procedure or the backend checkout procedure available on all WooCommerce sites in the “Orders” panel labeled “customer payment page”. Our plugin will add the gateway to the Woocommerce payments section like any other gateway and proceed through checkout with the StripeJS SDK. If you have trouble getting the plugin available in a third party POS plugin you’ll need to discuss with that plugin developer. You can also fork off of this adaptation of the Kilbot WCPOS plugin which provides a compatibility patch but please note we do not support/maintain this codebase, so upgrades will be required: https://github.com/arcanestrategies/stripe-terminal-for-woocommerce-pos

If your payments are working as you’d like them to, why change it? You’re just using someone else’s terminal payment method in your POS, that’s all I’m saying. Our plugin should still work for your mobile integration (ie. for M2 and Chipper devices), you’re just not using it for web orders. Your current terminal solution doesn’t really provide useful data on your Stripe PI’s but if that’s not important to you, you’ve got a perfectly workable solution without us. It’s entirely likely that your POS developer has their own terminal solution and doesn’t integrate with ours. Ours is meant to work directly with the default checkout procedures which all themes implement but most POS plugins ignore theme files and build their own DOMs which makes them incompatible with most plugins. You really should touch base with your POS developer, they’d be the best to speak with about this. They’d also probably have a better answer regarding “Is it possible that something else is overriding it and turning it off?” (anythig is possible but it wouldn’t be coming from us).

Our plugin will import data from your account, that doesn’t mean you’re actually using it for transactions. The account we’re reviewing has actually never made a transaction using our plugin. Go to your Stripe account and click “Developers”, then click “Logs”, then click on a transaction and look at the API call header. You’ll see “Arcane POS” under the Application property and “arcanestrategies.com/products/stripe-terminal-for-woocommerce” in the source if it’s from us. In fact, you’ll also see a lot more data. Our plugin includes a lot more transaction data than yours. For example, ours displays the order description title with the order ID (not a PI id), meta data listing all line items, cashier name, and more. All of your terminal transaction PIs are missing this info, don’t have our headers, and have the order ID in meta data under “Order Number: reg#”, that’s not from us.

• This reply was modified 3 years, 10 months ago by arcanedevops.

We do not support manual card entry on the terminal, the terminal is not the POS UI. Manual card entry should be handled via your POS UI (ie. Stripe gateway plugin).