The point is that we have a checkout extension that checks if an email address is provided. If so, it fires a request to the Shopify API to check if such a customer already exists. If not, it creates one (just the email address). If a customer is/has just been created, it returns the customerID to the extension. Then, during VAT validation (a separate custom field and button), the extension sends a request back to the API with the customerID and VAT number. If it’s valid (validated in VIES), it sets tax exemptions. Sometimes it works, sometimes it doesn’t. Sometimes the checkout refreshes quickly, sometimes you have to wait a minute
Any suggestion how to force clearing of the cache?
Hi @Piotr_Sadowski, curious if you can help us understand the issue better. I’m not following this part:
Sometimes it works, sometimes it doesn’t. Sometimes the checkout refreshes quickly, sometimes you have to wait a minute
Can you share a video walking through the issue in more detail, or code examples of what you are trying to accomplish and where you are running into the issue?
Here is video
showing the problem
(extension was built with react & preact component ) both does not work
With preact i have noticed less stable
When user is created before i got TAX extempt but when I’m trying to create user & validate in checkout it does not work
The extension is embedded in a Remix app (as per Shopify’s guidelines). In that same app we’ve got an API endpoint that gets hit when you click the “Validate” button. We send the VAT number, country code, and customer ID (we have the customer ID because earlier we call another API endpoint to check if a customer with that email already exists, or we create one if not). The validation endpoint checks the number in an external government database and, if it’s valid, we use the Admin API to set tax exemptions for that customer and add a metafield with the VAT number.
After the email is entered in checkout, we call our app’s API endpoint with the customer’s email to check if the customer already exists. If they do, we return info back to the extension (customer id, tax exempt status, etc.). If they don’t, we create the customer via the Admin API and also return the customer id, etc. When someone enters a VAT number in our UI extension field and clicks Validate VAT, the flow is basically what I described in point 1: we validate the VAT in the external system and, if it’s valid, we set tax exemptions for the customer via the Admin API. On success, the extension gets a “all good” response and we set cart attributes: _vat_verified and _vat_number. We also add a whitespace to the user’s address and then remove it to force a reprice in Shopify checkout.
And here’s the issue: in most cases, after this “reprice,” the checkout still doesn’t see the customer updates. It only picks them up after about a minute. In some cases the changes are visible right away and the tax disappears.
We are able to reproduce the issue, much thanks to your detailed response. This indeed appears to be a caching issue. We will be tracking this issue on our end.
As a workaround, have you looked into Discount Functions as an alternative? This won’t help you completely remove the tax line from checkout, but wondering if you can apply an amount discount based on the VAT number validation result and the taxes and duties in the cart cost.
Hi ,
this won’t work for accounting purposes because the reverse charge must be recorded on the invoice. what they plan to do and when. Will you remove the cache or implement some kind of modification/API in checkout to retrieve the latest customer data?
this won’t work for accounting purposes because the reverse charge must be recorded on the invoice.
The function run result includes a message field that can be used to include a label for the reduction. This will be included in the order summary.
Unfortunately, we cannot share a timeline for the bug at this time, but it’s definitely on our radar. The workaround may not be ideal, but it may unblock you in the meanwhile.
Regarding the discount workaround - unfortunately, no discounts or reductions are acceptable from an accounting perspective.
The fundamental issue is that an invoice with reverse charge VAT must have this explicitly indicated on the invoice. If we use discounts instead of properly handling the VAT calculation, this creates several critical problems:
Accounting error with legal consequences - From a bookkeeping standpoint, applying a discount instead of properly documenting reverse charge VAT is an accounting mistake that can carry legal ramifications.
Financial loss - The company loses money with this approach. With proper reverse charge VAT handling, the tax can be reclaimed/deducted later. When you apply a discount instead, that money is simply gone - you can’t reclaim anything.
Even if the discount message field appears on the order summary, it doesn’t create the proper tax documentation required for reverse charge invoicing. The tax line needs to be removed/zeroed out with the appropriate reverse charge notation, not replaced with a discount.
Question: Has there been any progress on resolving this cache issue on your end? Any timeline for when we might see a fix or at least an API method to force-refresh customer data in checkout?
