Cartwright Privacy Policy

Last updated: 2026-10-26

Cartwright is a checkout rules app for Shopify stores. This policy explains what data the app handles, why, how long it stays, and how to have it deleted. If any part of this policy is unclear, write to us at support@getcartwright.com.

1. Who we are

Cartwright is the app. The app is made and run by Cartwright LLC, a Colorado limited liability company. In this document, "we", "us" and "our" refer to Cartwright LLC.

• Email: support@getcartwright.com
• Postal address: 1500 N Grant St, Ste N, Denver, CO 80203, US. That address is the office of our registered agent, which receives our mail; the app is not built there.

For the data described in this policy, we are the data controller for our own records about the merchants who install the app. For order data that reaches us from a merchant's store, the merchant is the controller and we act as their processor. We handle your store's order data on your instructions, to run the app for you. Three things we keep are for us as well as for you: a log of what the app did, which is how a failure gets found; a daily tally of installs, trials, subscriptions and failures across all stores, which has a place in the database but is empty, because the app does not fill it in yet; and a minimal record of each privacy request Shopify sends us, which lets us finish, reconcile and demonstrate the required action even after the store record has been erased. Sections 3.3 and 5 describe all three records, and section 5 states the legal basis on which we hold each one. Beyond those three records, we do not use your data for any purpose of our own. Section 12 lists what we do not do with your data.

2. The short version

• Shopify's copy of each completed order is narrowed to nine fields, one of which is the shipping address. Shopify redacts the name, street address, postal code and phone number in that address for apps that have not been approved to receive them, and Cartwright has not asked for that approval. On our own development store, the whole address arrived unredacted, so this policy is written for that case. In either case, the app does not read or store the shopper's name, email address, phone number or street address. Section 4 lists exactly what the app does read.
• The app does not sit between a shopper and the checkout. Rules run on Shopify's own infrastructure.
• From each order, the app reads the short list of fields named in section 4. The app uses most of those fields in memory and then discards them. Only three values read off the order itself are written down: the order's identifier, the day it was placed, and, if the cash on delivery fee runs on your store, the order's currency. Written alongside them is the app's own working, which is not read off the order at all: which of your rules matched it, and, for a fee, the amount you set in your own settings, whether the attempt worked, why not if it did not, and how many attempts it took. Cartwright does not charge or collect that fee. The fee is yours, and so is the money it raises. Section 4 lists each field the app reads, uses and stores.
• We keep data that came from your orders for a maximum of 90 days.
• We do not sell data, we do not use it for advertising, and we do not use it to train any artificial intelligence or machine learning system.

3. What we collect

We collect three groups of data.

3.1 Merchant and shop data

This section covers data about your store and about you as the person who installed the app.

• Your store's myshopify domain, timezone and currency.
• The name of your Shopify plan, as Shopify reports it, and one flag Shopify gives us: whether the store is a partner development store. From the plan name we also derive and store a suggested price tier for your store, together with a note of how confident that suggestion is.
• Your store's Shopify shop identifier.
• The most recent time Shopify had to re-authorize the app for your store, and when it was uninstalled if it was.
• Your subscription details with us: trial end date, plan tier and price, and whether the subscription is active or canceled.
• A Shopify access token, which is the credential that lets the app act on your store. The token is stored so the app can keep working between visits.
• The names of the payment methods your store offers, as a shopper sees them at checkout. The app can read only the method names Shopify makes available to it, so this list may not include every method your store offers. We refresh this list when you publish payment rules. The list holds method names, not payments.
• When you save or set live a payment rule that targets a card method (a target with words such as "credit card", "Visa" or "Mastercard"), the app asks Shopify at that moment for your store's country and whether your store is on Shopify Plus. The app uses both facts only for the check described in clause 6 of the terms and then discards them. Neither fact is stored.
• Two columns on your store's record that the app does not fill in: a place for the cash on delivery fee's settings, which has no screen anywhere in the app, and a founder-price flag that no part of the app reads or writes. Both columns are empty on every store.

The app also uses Shopify's standard session record. That record has columns for the first name, last name and email address of the staff member signed in. Cartwright does not turn on Shopify's online access tokens, so we expect those columns to be empty in normal use. We list them because they exist in our database. The same record carries the rest of Shopify's standard session model, which we do not write ourselves: a Shopify user ID, whether that user is the account owner or a collaborator, whether their email address is verified, their locale, the permissions your install granted, when the token expires, a refresh token with its own expiry, the one-time value used to complete the sign-in handshake, and a flag recording whether the session is one of Shopify's online ones, which ours are not. The user columns there are expected to be empty for the same reason as the name and email ones.

3.2 Data we receive from Shopify about orders

When an order is completed in your store, Shopify sends the app a narrowed copy of that order. The copy does not carry the shopper's email address or the customer record. The copy does carry the shipping address. Shopify redacts the name, street address, postal code and phone number in that address for an app like Cartwright that has not been approved to receive them. On our development store, the whole address arrived unredacted. Section 4 sets out exactly what the app reads from the copy, the short list of values it stores, and the fields it does not read. In summary, the app does not read or store any shopper's name, email address, phone number or street address.

3.3 Data the app makes for itself

• Your rules. The name you give a rule, whether it is a payment rule or a checkout requirement, the action you ask it to attempt, what it targets, the text or number you enter for that action (an attempted replacement label, a position in the list, or the message a shopper reads), its conditions, its priority, its schedule (a column the app does not fill in yet) and whether it is live, paused or a draft. This bullet describes what the rule record stores. The bullet does not promise that Shopify will display a replacement label reliably. If you type something personal into a rule name or a checkout message, it is stored exactly as you typed it.
• Publish history. Every time rules go live we record which module the publish was for, how many rules, how large the compiled configuration was and its size per rule, how many pieces it was split into, why the publish happened (you pressed Publish, or a schedule came round), where at Shopify it was written, the next scheduled boundary if any rule is time-windowed, a fingerprint of the configuration, whether it succeeded, the error text if it did not, and a copy of the compiled configuration itself. That copy is what the "why did my rule not fire" page reads to give its answer, and it is what lets us count matches against the rules that were live at the time rather than the ones live today.
• Match counters. One row per rule per day, holding a store identifier, a rule identifier, a date and a number. That table holds no other data about you or your shoppers, apart from the bookkeeping fields named at the end of this list. The date is the day the counted order was placed, in your store's own timezone, worked out from the order's timestamp; the timestamp itself is not stored.
• An order-identifier ledger. One row per order per rule that has been counted, holding a store identifier, a rule identifier and the order's identifier. Section 4 explains why this exists.
• Product events. A small log of things that happened: an install, a trial starting, a rule created or paused, a template used, a test run, a publish, a fee applied, a webhook that failed. Some of these events carry an order identifier in their properties. Some carry your store's domain. When you use test mode, the app records an event describing the checkout you entered on that screen. The event holds the total to pay, item count, country, province and shipping method you typed in. The event also holds the number of payment methods you listed, but not the names of those payment methods. If you type something personal into that form, it is stored in the event row exactly as you typed it. This log is also how we know whether the product is working at all, which is a purpose of ours rather than yours; section 5 states the legal basis for keeping the log for that purpose.
• A COD fee ledger. The cash on delivery fee has no settings screen yet, so there is no switch a merchant can turn on and this ledger is empty for every store today. If the fee runs on your store in the future, this ledger records which order the fee was applied to, the amount you set, the currency, whether it worked, why not if it did not, and how many times it was attempted.
• An aggregate table. A day-by-day roll-up of counts across all stores: installs, uninstalls, trials started and converted, active and paying stores, revenue, fees applied or failed, and webhook failures. The table also holds a short list of threshold flags, which is the one thing in it that is a judgment rather than a count: too many uninstalls in a day, too many fee failures, trial conversion below a line, or a single rule matching almost every order in a store. Those flags are about how the product is doing, and they are one of the reasons this table exists. The table holds no order data. The app does not fill this table in yet, so it is empty for every store. What a flag will contain is not yet decided: one of the thresholds is about a single rule inside one store, so a flag could name a store once the app fills the table in. When that happens, this bullet will be rewritten and the date at the top will move.
• A record of the compliance requests Shopify sends us. When Shopify asks us, on a shopper's or a merchant's behalf, to hand back data, erase a shopper's data, or erase a store, we write down which kind of request it was, your store's Shopify domain, the identifier Shopify gave that delivery, when it arrived, when we finished acting on it, how many times we tried, and a short note if a try failed. The record holds no data from your orders and no data about any shopper. This record deliberately survives the erasure of your store, because it is our evidence that we did the erasing; the record names your store and holds no other data about the store. Shopify requires the action to be completed within 30 days of the request, and this record is how we know whether it has been, and how an unfinished compliance request is picked up and tried again.

Every row in every table above also carries its own row identifier, and most carry when the row was created and when it was last changed. These bookkeeping fields hold no data about you or your shoppers.

4. Order data, exactly

This section sets out what the app receives with each order, what it reads, and what it stores.

What Shopify sends us

When an order is completed, Shopify sends the app a copy of the order narrowed to nine top-level fields, which are the only ones the app reads: the order's identifier, the time it was created, its currency, its payment gateway, its payment gateway names, its total price, its line items, its shipping address and its shipping lines. Shopify does not send us the shopper's email address, the order's contact email, the top-level phone number, the billing address, the customer record, the order note, the note attributes, the browser IP, the client and device details, or the discount codes.

The narrowed copy can still contain personal data. The app requires the shipping address, because country and province rules take their values from it. Shopify sends the shipping address as a single unit, with all of its parts together. Shopify redacts the name, street address, postal code and phone number in that address for apps that have not been approved to receive them, which describes Cartwright. On our development store, the whole address arrived unredacted, and this policy is written for that case. The app reads only the country and province codes from the address, and the address is not retained after the request ends.

The app reads the fields listed below from the copy. Of those, the app stores only the three values listed under the second heading below.

What we actually do with each field

Fields the app reads in memory and does not store:

• The order total, to compare against your rules' conditions on the total to pay.
• The payment gateway and the gateway names, which identify how the shopper paid, not who the shopper is.
• The country and province codes from the shipping address. The app reads no other information from the shipping address.
• The shipping method title.
• The line item quantities.
• The time the order was placed, which is reduced to a calendar day before the day is stored; see below.

The app reads these fields once, compares them against your rules to work out which rules matched, and does not log or store them. The fields are cleared from memory when the request ends.

Values taken from the order and stored in our database:

• The order identifier. Three places it can appear. First, in the COD fee ledger, if and only if the cash on delivery fee is active on your store and the order qualified for it. Second, in the order-identifier ledger, if and only if at least one of your rules matched that order and the match could be verified against the configuration that was live at the time. Third, in a product event row, when something about the order is worth recording: a fee applied or failed, a redelivered order skipped, a count that could not be saved.
• The currency code, on the COD fee ledger row, so the fee is recorded in the currency it was priced in.
• The day the order was placed, in your store's timezone, as the date on the match counter row. The day is derived from the order's own timestamp; the time of day is not stored.

These three values are the complete list of values taken from an order and stored. No other part of the copy Shopify sends is stored.

Stored alongside those three values, but not taken from the order: which of your rules matched, on the match counter row and on the order-identifier ledger row. On a COD fee ledger row, the app also stores the fee amount from your own settings, whether the attempt was applied, skipped or failed, or is still marked as started because the process stopped between claiming the order and finishing with it, the reason it was not applied if it was not, and how many attempts were made. These entries record what the app did, not facts about the shopper or the order.

The order identifier is a number Shopify assigns to an order. The order identifier is not a name or an email address, and it holds no details about the person who placed the order. Given access to your Shopify admin, it can be used to look an order up, which is why we treat it as data worth protecting and worth deleting rather than as a harmless integer.

Fields the app does not read. There are two kinds: fields Shopify does not send, and fields Shopify sends that the app does not read.

Fields Shopify does not send to Cartwright: the shopper's email address and the order's contact email, the top-level phone number, the whole billing address, the customer record including its tags and lifetime order count, the order note and note attributes, the browser IP and client and device details, the discount codes, and the goods subtotal.

Fields Shopify sends that the app does not read: everything in the shipping address other than its country and province codes, which on an unredacted copy means the shopper's name, street address, company, city, postal code and phone number; and everything on a line item other than its quantity, including product identifiers.

The second group arrives in the copy because Shopify sends the shipping address and the line items as single units, and the app leaves the rest of them unread. The app previously read the customer tags and order count. The app stopped reading them because the checkout function the counts are meant to mirror cannot see them, so reading them made the counts wrong. Removing them also removed any reason to ask Shopify for permission to read customer records. The app does not request that permission. Your install screen shows the full list of permissions the app does request.

Why the order-identifier ledger exists

Shopify can occasionally send the app the same order more than once. A repeat delivery happens after a timeout or a retry, and is normal platform behavior. Without a record of which orders we have already counted, a redelivered order would add one to every matched rule's total a second time, and the number we show you would be wrong in our favor. So we keep a note of every order we have counted, and a repeat is skipped.

Shopify redelivers an order up to eight times, over about four hours. After that, a row in this ledger no longer does the job it was created for. Cartwright therefore deletes ledger rows far sooner than the 90 days in the next section: we keep each row no longer than 7 days.

5. Why we hold each type of data

The legal basis for each type of data. We process merchant and shop data because that data is necessary to perform our contract with you, which is to provide Cartwright to your store. We handle order data on your instructions, as your processor; you are the controller of your shoppers' data, and we act only on what the app is configured to do.

We hold three things for our own purposes as well as yours. The first two rest on our legitimate interest in keeping the product working and knowing whether it is. The first is the product event log: it is how a failure is found before you have to report it, and it is also the data a paid analytics feature would use if one is built. The event log carries your store's domain and, on some rows, an order identifier. The event log is subject to the same 90-day maximum in section 6 as all other data derived from your orders. The second is the daily tally of counts across all stores in section 3.3, which the app does not fill in yet. The third is the compliance-request record in section 3.3. The compliance-request record rests on our legitimate interest in finishing, reconciling and demonstrating the privacy actions Shopify requires us to carry out. The compliance-request record keeps the minimum information needed to show which request arrived and whether and when we completed the request. Section 6 explains why the record is kept after the store record is erased. You have the right to object to any of these three uses, as section 9 states; write to the address in section 1 and we will answer.

Every type of data in the table below is held for you. Product events, aggregate daily counts and the compliance-request record are also held for our own purposes.

6. How long we keep your data

Data derived from your orders is kept for a maximum of 90 days. That maximum covers the COD fee ledger, the order-identifier ledger, the match counters and the product event log, including any order identifier sitting in an event's properties. A deletion job removes those records before they turn 90 days old, and it deliberately cuts two days early rather than late, so a run that is a day late still deletes each record before the 90-day maximum. Each run of the deletion job writes a single line to our own event log stating what the run removed. Cartwright does not currently monitor that log automatically, so a deletion job that stopped running would appear only as a gap in the log.

There are five exceptions to the 90-day maximum:

1. Order-identifier ledger rows are deleted far sooner than 90 days, as section 4 explains. Shopify stops redelivering an order after about four hours, so a ledger row older than that serves no purpose.
2. Your rules, your publish history and your store record are kept for as long as the app is installed. Your rules, publish history and store record are your own configuration, not order data. Deleting that configuration after 90 days would switch off rules you rely on. We delete your rules, publish history and store record when you ask us to, or when the app has been uninstalled and Shopify asks us to erase the store. Section 7 describes that erasure.
3. Your session and access token last as long as the install. We delete the session and the access token when Shopify tells us the app has been uninstalled.
4. Five kinds of event rows are kept beyond 90 days. One records that you dismissed the plan-suggestion banner, so the app does not show the banner again. One is the note we write each time we check whether any compliance request is still unfinished. That note carries counts and no store name. The other three are our receipts for the compliance requests Shopify sends: a data request, a customer redaction and a store redaction. The store-redaction receipt carries a row count and no store name; the other two carry your store's domain. None of these event rows holds data from your orders.
5. Our record of a compliance request is kept indefinitely. The record is our evidence that we did what Shopify asked, and when, so we do not delete the record on a schedule. The record holds your store's domain, the kind of request, the dates and the delivery details listed in section 3.3. The record holds no data from your orders and no data about any shopper. Section 3.3 lists each field the compliance-request record holds, and section 7 explains why the record is kept after the rest of your data is erased.

Match counters are one case where we keep more history than the app shows you. The app displays the last 30 days. We keep 90 days of match counters so that we can answer a merchant's question about the last quarter.

If you want your data deleted sooner than the periods in this section, write to us at the address in section 1. We follow a written procedure for deleting a single store on request, and we answer within one month.

7. Uninstall, and the three compliance webhooks

When you uninstall

Shopify sends us a message when you uninstall, and when it arrives we delete your session and your access token, so the app can no longer act on your store. We mark your store as uninstalled and set your subscription status to canceled.

We deliberately keep your rules. If you reinstall the app within 48 hours, your rules are still there in the app, ready to publish again. If you do not reinstall, Shopify asks us to erase the store 48 hours later, and we do.

When Shopify asks us to erase your store (shop/redact)

Shopify sends this request 48 hours after an uninstall if the store has not reinstalled. We delete your store record, and that deletion cascades to your rules, your publish history, your compiled configurations, your COD fee ledger, your match counters, your order-identifier ledger and your product events. We also delete any remaining session rows for the store.

A small number of product event rows are written without a link to the store record, for example when a webhook fails before we know which store it came from. Those rows carry your store's domain in their properties, so the cascade above cannot reach them, and the redaction step deletes them by domain explicitly. Two kinds of record remain after the erasure, and neither holds data from your orders. The first is a single row stating that the redaction was carried out and how many rows the redaction removed. That row carries no store name. The second is one or more compliance-request rows, as described in section 3.3. Each of those rows names your store, and we keep each row because the row is our evidence of which privacy request arrived and whether and when we completed the request.

When a shopper asks for their data to be erased (customers/redact)

Shopify sends this request when a shopper asks a merchant to erase their personal data. When this request arrives, we hold no data about that shopper to erase. Cartwright does not store that shopper's name, email address, phone number or street address. The shopper's email address and customer record are not sent to us. The shopper's name, street address and phone number can arrive inside the shipping address, as section 4 describes. The app does not read those fields, and those fields are not retained after the request ends. We do not hold any record keyed to a person.

In the app, the only data we hold that could relate to the shopper's order is the order identifier, in the three places described in section 4. The deletion job in section 6 removes the order identifier from each of those places without any request: from the cash on delivery fee ledger and the product event log within 90 days, and from the order-identifier ledger within 7 days. Outside the app, an order number can also be in an email a merchant has sent to support, which our support email suppliers in section 8 hold.

When a shopper asks for a copy of their data (customers/data_request)

Shopify sends this request when a shopper asks a merchant for a copy of their data. We hold no personal details about that shopper. The only records that can relate to their orders are order identifiers in the three places section 4 lists, deleted within the periods in section 6, and order numbers in emails to support, which our support email suppliers in section 8 hold. We record that the request arrived; Cartwright does not look up those order identifiers automatically. On request, we tell the merchant which of the requested order identifiers we still hold. The merchant writes to us with the shopper's orders, giving for each the number at the end of the order's page address in their Shopify admin. We check them by hand and answer in writing, because the merchant is the one who owes the shopper an answer.

8. Who else touches the data

The table below shows who outside Cartwright LLC handles the data and what each of them holds. No data is shared with an advertising network, a data broker, an analytics vendor or anyone not named in the table below.

Where the data is. The app's server and its database both run in the United States, in the Ohio region. If your store is in the United Kingdom or the European Economic Area, the merchant and order data described in sections 3 and 4 is transferred to and processed in the United States. Render and Supabase each offer standard data processing terms for that transfer: Render's DPA at https://render.com/dpa and its sub-processor and compliance pages at https://render.com/trust; Supabase's DPA at https://supabase.com/legal/dpa and its GDPR guidance at https://supabase.com/docs/guides/security/gdpr-compliance.

We also make a read-only call to Shopify's Partner API to check whether your subscription is active. That call sends our app's identifier and your store's Shopify shop identifier, and no other data. No order data and no shopper data leaves the app to anyone beyond those named in the table above.

The table above is the complete list of those outside Cartwright LLC who handle the data. If we add a supplier, we will add the supplier to the table and update the "Last updated" date at the top of this policy before the change takes effect.

9. Your rights, and how to use them

If you are a merchant, you have the following rights, and you can use them at any time:

• Ask for a copy of everything we hold about your store.
• Ask us to correct any data that is inaccurate.
• Ask for the data you gave us in a structured, commonly used, machine-readable format.
• Ask us to delete the data we hold about your store. We follow a written deletion procedure for that request. Uninstalling also starts deletion: Shopify sends us its erase request 48 hours after you uninstall unless you have reinstalled before then, and we act on it when it arrives. Section 7 describes what that erase request deletes. If you want your data erased sooner, ask us. In both cases, we keep our record of any compliance requests Shopify has sent us about your store, as the fifth exception in section 6 describes.
• Delete an individual rule yourself from inside the app. Its counting history goes with it, immediately and permanently.
• Object to how we process your data, or ask us to restrict that processing.

If you are a shopper, your relationship is with the store you bought from, and your request should go to that merchant, who will pass it to us through Shopify's own process. You may also write to us directly at the address in section 1, and we will respond to your request. In most cases, our answer will be that we hold no personal details about you. Section 7 explains why, and what we can check for the merchant.

We answer requests within one month of receiving them.

If you are in the UK or the EEA, you have the right to lodge a complaint with your national data protection authority.

10. Security

The security measures below are in place today.

• The app is not in the checkout path. Rules run as Shopify Functions on Shopify's own infrastructure. No Cartwright server sits between a shopper and their payment. If our servers went down entirely, your published rules would keep running and your checkout would keep working.
• We ask for the smallest set of permissions the app can work with. We do not request permission to read customer records. On 2026-08-14 we removed three further permissions that the app was not using.
• Every webhook we receive is cryptographically verified against Shopify's signature before it is acted on. An unsigned or badly signed request is refused.
• All traffic runs over HTTPS. Shopify requires it of every app it allows to run. HTTPS is a property of the hosting the app runs on rather than something our own code adds, and a plain HTTP request to the live app is redirected to HTTPS.
• The app talks to its database over a private server-side connection. The app does not expose the database to any browser. The database's own public data interface cannot read any table: row-level security is switched on for every table, and no table has an access rule (a row-level security policy) that would let that interface read it. As a result, the app's own server connection is the only way in, apart from the database provider's own keys and authenticated dashboard.
• Data at rest is encrypted by our database provider using their standard managed encryption.
• Offline access tokens expire. The app uses Shopify's expiring token behavior rather than holding a credential that does not expire.
• Only Cartwright's founder has production database access, through the database provider's and the hosting provider's authenticated dashboards. The database provider and the hosting provider named in section 8 run those systems and have their own staff and their own controls; this statement covers Cartwright LLC only.

We do not hold a SOC 2 report, and we do not encrypt individual columns beyond the database provider's own encryption.

11. Cookies and tracking

Cartwright's own code sets no cookies. Cartwright runs no analytics, advertising pixels, session recorders or third-party trackers, either in the Shopify admin or on our own website.

Signing in and installing run through Shopify's official app library, which may set a short-lived cookie as part of that exchange. That cookie exists only to complete the sign-in, and Cartwright does not read it afterward.

Cartwright does not track merchants or shoppers across websites.

12. What we do not do

• We do not sell data in any form, including aggregated data.
• We do not use your data or your shoppers' data for advertising.
• We do not use your data or your shoppers' data to train any artificial intelligence or machine learning system, whether ours or anyone else's.
• We do not share your data or your shoppers' data with any third party except those named in section 8. Our suppliers there process it on our instructions and for no purpose of their own.
• We do not read your customers' personal details. Those details can arrive with the order copy Shopify sends, and the app leaves them unread; section 4 lists exactly what the app reads.

13. Changes to this policy

If we make a material change, we will describe the change on this page and update the "Last updated" date at the top before the change takes effect. A material change is a new category of data, a new supplier, a new purpose, or a longer retention period. Cartwright has no notification banner in the app and no mailing list, so this page is the notice of a change. Compare the "Last updated" date at the top of this policy with the date you last read it to see whether the policy has changed. Minor edits, such as correcting a typo or making a sentence clearer, are not described separately, but the "Last updated" date still changes.

We will not extend how long we keep any data without first updating this page and its "Last updated" date.

Changed on 2026-10-26. Section 8 now names two more suppliers: Titan, which hosts our support email, and Proton, which holds the forwarded copy of that email in the inbox where we read it.