What StateWise reads, and what it ignores
A sales tax tool has a good excuse to ask for everything. It is looking at orders, orders have customers attached, and nobody would blink at an app that read the lot.
This one reads a state code and a number. Here is the whole list, both halves of it.
What it reads from your orders
| Field | What it is for |
|---|---|
| Order id | Recognising the same order twice so a repeated delivery cannot double-count |
| Order date | Which measurement window the sale falls in |
| Ship-to province code and country code | The whole product: which state the sale counts toward |
| Bill-to province code and country code | Only when an order has no shipping address at all. Shown tagged, so you can see it was inferred |
| Order total (and currency) | Measured against the state's dollar threshold |
| Test flag | Test orders are excluded from every number |
| Cancellation status | Cancelled orders are excluded from every number, and shown to you as excluded with that reason |
| Shipping requirement and local-pickup classification | For connected Shopify orders, excluding digital and local-pickup-only sales without reading line items |
| Refund total | Stored and displayed. Never subtracted from a threshold |
| Sales channel | Whether a sale was marketplace-facilitated, which is the number most tools miss |
A province code is two letters. TX. That is the level of detail the arithmetic runs on.
What it never reads
Customer names. Email addresses. Phone numbers. Street addresses, line 1 or line 2. Postal codes. Geolocation. IP addresses. Line items.
Not "does not currently". Not "only with your permission".
CSV exports do not expose digital and local-pickup semantics consistently across Shopify and marketplaces. StateWise does not guess those facts from an absent shipping address. Those two exclusion reasons are exact for connected Shopify data; an imported CSV row is classified only from the fields the export actually provides.
Why that second list is structural and not a promise
Shopify classifies apps by how much customer data they are approved to touch. StateWise holds Level 1, the lowest tier, and requests none of Shopify's individually-approved protected fields. Name, address, email and phone are each a separate approval, and this app has asked for none of them.
Its access scopes are read_orders and read_all_orders. Nothing else. Not products, not customers, not locations. So a name is not something the app declines to look at. It is something the app could not retrieve if its code asked, and no query in it asks.
The part that is easy to get wrong, and what we do about it
There is a gap in how this works that is worth explaining, because most apps in this position do not close it.
When Shopify sends an order to an app, StateWise asks for four dotted address leaves only: the shipping and billing province and country codes. It does not subscribe to either whole address object, so names, streets, postal codes and phone numbers are not part of those deliveries.
Every handler also reduces the payload to the fields in the table above before doing anything else with it, including before writing it to a queue or a log. That ordering is deliberate. A queued job is a database row, and a log line is neither redacted nor covered by the deletion path, so an unreduced address reaching either one would outlive the request that carried it. The rest of the app never sees a Shopify order object at all, only the reduced version.
The narrow subscription and the runtime reduction are two independent privacy boundaries.
Files you upload
When you import a marketplace export, the file is parsed and then discarded. Only the normalized fields above are stored.
Marketplace exports are generous with customer data, and an Amazon or Etsy report may well contain buyer names and full shipping addresses. Those columns are not read. They are not stored, and they do not survive the import.
What it reads about your store, as opposed to your customers
The store's domain, timezone, currency and Shopify shop id, and the contact email already on file in your Shopify admin.
That last one is worth stating plainly because you never type it in: it arrives from the admin at install, and it is where threshold alerts and the weekly digest are sent. Clearing the alert address in Settings stops all of it.
Two things that are less comfortable, stated here rather than buried
A page like this is easy to write as reassurance only. These two belong on it.
Analytics rows are kept indefinitely, in pseudonymized form. When a store is erased, the store domain in those rows is replaced with a keyed pseudonym so install-cohort history survives. That is pseudonymization, not anonymization: under GDPR those rows are still personal data, and calling them anonymous would be a false statement rather than a simplification.
An erasure can be discharged by reinstalling. If you uninstall, an erasure is scheduled. If you reinstall and open the app before it runs, the data is kept and email resumes, because stores uninstall and reinstall routinely and deleting a live merchant's history is the worse failure. If you want the data gone, uninstall and do not reinstall, or ask us directly.
Where to check any of this
The privacy policy is the binding version and lists the fields and only those fields. The merchant terms hold the reliance posture. If you want to know how the numbers themselves are produced, that is how StateWise counts your sales.
Related: the jurisdiction table, more guides, and what StateWise does.