search

Automattic / woocommerce-payments

Accept payments via credit card. Manage transactions within WordPress.
https://wordpress.org/plugins/woocommerce-payments/
Other
173 stars 69 forks source link

Using product IDs after moving/changing WCPay connect accounts #3269

Open james-allan opened 2 years ago

james-allan commented 2 years ago

Describe the bug

It's currently possible to have product IDs stored in the database that aren't linked to the current WCPay Connect account. This can happen in any number of ways. I've included what I believe to be two possible scenarios below.

  1. Merchant connects to WC Pay, creates a subscription product on account, disconnects from WC Pay, re-onboards and creates a new account. The customer attempts to make a purchase of the product using that new account.
  2. A store is set up on a staging/demo site, a subscription product is created, the site is migrated/deployed/goes live, the merchant re-onboards to WCPay on the live site. The database was migrated from the demo site and so WC Pay product IDs copy over. The customer attempts to purchase the product.

In both cases, a product ID linked to 1 WCPay account is used with a different WCPay account and results in the following error.

No such product: 'prod_KVUN2p9l83HkTO'

To Reproduce

I'm not 100% sure how to reliably replicate this issue following a real-world set of steps. The steps below are a way of illustrating how this might happen. I've also based the above 2 scenarios after observing the error logs in logstash.

To replicate I:

  1. Created a new JN site.
  2. Installed and activated WooCommerce, WooCommerce Payments and WCPay Dev Tools.
  3. Onboarded to WC Payments.
  4. Created a Subscription product.
  5. Went into WCPay Dev from the WP admin checked the box to force re-onboarding.
  6. Reonboard to WC Pay.
  7. After onboarding for a second time attempt to purchase the product.
  8. You should get the error above.

Expected behavior

When a site moves WCPay accounts existing any product IDs created on a different account should be deleted or some validation should occur to make sure the product ID is still valid for this account.

Desktop (please complete the following information):

Smartphone (please complete the following information):

Additional context

haszari commented 2 years ago

Thanks for logging this @james-allan - do you think this is likely to cause issues for merchants? E.g. should we proactively fix this or is it reasonable to wait for reports.

If the merchant does get into this situation, is there a reasonable workaround we could suggest? For example, completely recreating the subscription product (and deleting the orphaned one).

james-allan commented 2 years ago

do you think this is likely to cause issues for merchants?

There was at least 1 occurrence of this happening on a site. At least that's how I discovered it via the #wcpay-notices-prod channel. (p1635810288050800-slack-C46H1UYN4)

Looking into the product IDs and blog report card in the specific case, it appeared to be the second scenario I mentioned above - the product ID was associated with a staging site sounding URL, but was being used on a legit site.

james-allan commented 2 years ago

I forgot this question:

If the merchant does get into this situation, is there a reasonable workaround we could suggest? For example, completely recreating the subscription product (and deleting the orphaned one).

Yeah, you'd have to delete the WC Product and recreate it or delete the product ID from the post meta.

haszari commented 2 years ago

Thanks @james-allan - do you think the workaround is enough for now? Perhaps we can document the workaround, and if we get reports/requests then we can revisit.

haszari commented 2 years ago

Saw another variation of this in wcpay-notices-prod logs:

No such subscription: 'sub_abcd1234'; a similar object exists in test mode, but a live mode key was used to make this request.
csmcneill commented 2 years ago

4734326-zen

Resolved the issue by recommending the user create a new subscription product and deleting those created prior to their original account deletion.

aheckler commented 2 years ago

5204855-zen is this, I believe, except that the "product" in question is a tax rate? Digging more into this now.

aheckler commented 2 years ago

Yes, 5204855-zen is indeed a version of this issue. Theirs is pretty much the worst case scenario, which I think was along these lines:

  1. They had WC Pay set up on a live site.
  2. They cloned it to staging.
  3. They (correctly, sort of) set up a new WC Pay account for the staging site.
  4. They created a subscription product, a tax rate, and some customer accounts, all while testing things on staging.
  5. They copied data from staging back to live, which still has its own WC Pay account.
  6. Subscriptions purchases start failing.

Why?

Each error was only discoverable once the previous one was fixed, so the issue has been extremely painful for us and them to work on. :(

I realize this is pretty edge case-ish, but we should have a tool in WooCommerce > Status > Tools that can nuke all these "cached" customer and product IDs from the db and Stripe. Looking at the code, they just get recreated if they do not exist anyway (I think).

Natfor commented 2 years ago

5219076-zd-woothemes

Also related, also gave the user the workaround of creating new subscriptions to replace the old ones.

maxlaf commented 1 year ago

5810642-zen

csmcneill commented 1 year ago

39421119-hc

csmcneill commented 1 year ago

5854338-zen

Jinksi commented 1 year ago

Another potential variation of this issue spotted in wcpay-notices-prod: p1691035504352549-slack-C46H1UYN4.

Invalid request error: resource_missing (subscription id)