Privacy Policy

Last updated: October 30, 2026

1. Introduction and Who We Are

Ship To Who ("the App") is operated by BrightLayer Lab LLC, a Virginia limited liability company ("we," "us," "our"). Ship To Who is a Shopify app for florists and gift shops. It lets buyers name the person a gift is for, then checks each order to catch gifts that are about to ship to the buyer's own address by mistake. When an order looks wrong, the App flags it and can hold it so the shop's staff can check the address with the buyer before anything is sent.

This Privacy Policy explains what personal data the App handles, where it comes from, what we do with it, who else receives it, how long we keep it, and what rights people have. It applies to:

• merchants who install the App, and their staff;
• the merchant's customers who place orders (buyers);
• the people gifts are sent to (recipients); and
• visitors to our website, shiptowho.com.

The App does not send email or text messages to anyone.

2. Data Controller and Processor Roles

This section uses the terms of the General Data Protection Regulation (GDPR). Other laws give the same roles other names: under the California Consumer Privacy Act (CCPA) the merchant is the "business" and we are its "service provider" (Section 13), and under Canada's PIPEDA the merchant remains accountable and we are its service provider (Section 14).

• For order and recipient data (the buyer's and recipient's details that reach the App from a merchant's store), the merchant who installs Ship To Who is the data controller. The merchant decides why and how its customers' data is used, and its own privacy notice should tell buyers and recipients about it.
• BrightLayer Lab LLC acts as a data processor for that order and recipient data. We process it only to provide the App to that merchant, on the merchant's instructions, under our Data Processing Agreement (DPA) with the merchant, published at https://shiptowho.com/dpa, which forms part of our Terms of Service (https://shiptowho.com/terms). Order details that appear in our server logs (Section 3.3) are processed in the same way, for the merchant. So are the email addresses of the merchant's staff that the App records on outcomes, corrections and fix links, and any customer or recipient data that the merchant, its staff, a buyer or a recipient sends us so that we can act for the merchant (for example a data request).
• For data about the use of the App itself, BrightLayer Lab LLC acts as an independent data controller. This covers merchant account and staff session data, the staff access log, other correspondence from anyone who writes to us, data we keep to secure the service, and data about visitors to our website.

3. Data We Collect

3.1 From Merchants and Their Staff (via Shopify)

• Shop details: the store's myshopify domain, the date the App was installed or uninstalled, the country and province or state of the store's business address in Shopify (not the rest of the address) and whether it is a Shopify development store, with the time the App last checked them (Section 11), and the App settings the merchant chooses. Settings include the order tag, the hold note wording, the contact message shown to buyers, which delivery types the store offers, the names of the order fields the App reads, and whether the optional buyer fix page is on.
• Shopify access credentials: the access and refresh tokens Shopify issues so the App can work with the store.
• Staff details from Shopify: when a staff member opens the App, Shopify gives it that person's Shopify user ID, first and last name, email address, language, whether they are the account owner or a collaborator, and whether their email is verified. The App keeps these in its session records.
• Staff activity: the email address of the staff member who records an outcome on an order (Fixed, False alarm or Report a problem) or saves a correction. It is shown in the order's history in the App. When the fix page is on, the App also stores the email of a staff member who creates a fix link, with that link (Section 3.2). The staff access log is described in Section 3.3.
• Support correspondence: anything a merchant or anyone else sends to support@shiptowho.com.

3.2 From Buyers and Recipients (via the Merchant's Store)

The recipient form in the store. Merchants can add Ship To Who's recipient form to their product or cart page. There the buyer says whether the order is a gift ("It's for me" or a gift) and can enter:

• the recipient's name and phone number;
• the delivery type (home, hospital, school, office, funeral home or hotel); and
• details for that delivery type: hospital, ward and room; school, building and department; company and floor or suite; funeral home, service date and "in memory of"; or hotel and check-in date.

The form saves these to the buyer's cart in Shopify, using the store's own cart. It sends nothing to our servers and sets no cookies or browser storage of its own. The details reach the App only as part of the order Shopify sends us once the order is placed. A merchant can instead point the App at the recipient-name and gift fields that another app or its theme already collects.

Sensitive details. Some delivery details can reveal sensitive information about the recipient. A hospital, ward and room show that a named person is a patient, which is likely to be data concerning health under the GDPR and sensitive personal information under California law. A funeral home, service date and "in memory of" name can reveal a bereavement. These fields exist only so the delivery reaches the right place. The App uses them only to deliver the order, never to infer anything about anyone, and deletes them on the schedule in Section 7. Hospital and funeral home are off by default, both in the recipient form and in the App's Settings. A merchant that delivers there turns them on in the recipient form's settings in its theme, which decide what the form asks for, and keeps the App's Settings in step, which decide what staff and the fix page can choose. The other delivery types are on by default. The form always offers home, and merchants can switch off the other types. If an order carries delivery details without a delivery type, the App keeps all of them. Buyers should enter only what the delivery needs.

The order Shopify sends us. When an order is placed, Shopify notifies the App. From that notification the App reads only:

• the order ID, order number, the time it was placed and the sales channel it came from;
• the recipient details from the cart (above);
• the shipping name, first and last name, company, address lines 1 and 2, and city; and
• the buyer's first and last name, from the customer record and from the billing address on the order. These are used only for the name check in Section 9.

Shopify's notifications can contain more order information than this. The App does not read the rest, and it does not store the notification itself. Later notifications tell the App when an order is fulfilled or cancelled, or when a hold is released; for these it reads only the order or hold ID and the time.

The shipping address usually belongs to the recipient. In the mistake the App looks for, it is the buyer's own name and address. The App keeps a record (Section 3.3) for every order with a shipping address, except an order where no recipient details were entered and the shipping name is the buyer's own. So it also keeps records for orders where the buyer chose "It's for me", and for orders shipping to someone other than the buyer where no recipient details were entered. Orders with no shipping address are not recorded.

When staff open an order in the App. The App reads the current order from Shopify: its number, dates, fulfillment status, order note, all of its order attributes, the full shipping address including province, postal code, country and phone, and the countries the shop ships to. It shows staff the order number and status, the shipping address and the recipient details, so they can review and correct the order. The note and the other order attributes are read only so that a correction keeps them unchanged. None of this is stored unless staff save a correction (Section 3.3).

The thank-you and order status page block. The App adds a block to Shopify's thank-you page and to the order status page in customer accounts. It shows the buyer a recap of the recipient name, delivery details and shipping address, with a "Something is wrong" button. The recap is built in the buyer's browser from Shopify's data and is not sent to us. The block contacts our server only to:

• check whether a correction link is available, each time it shows a gift order that has recipient details (if the answer is no, it asks up to twice more, a few seconds apart, because a new order may not be ready yet);
• send a report when the buyer presses the button; and
• check the status of the resulting hold while the buyer waits (up to 12 times).

Each call carries a session token signed by Shopify that identifies the shop, and sends the order ID and the order's confirmation number in the body of the request, never in its web address. For a buyer who is signed in, the token also carries their Shopify customer ID; the App does not read or store it. The App uses the confirmation number only to check it against the order in Shopify and, when the fix page is on, to build the fix-page link it returns to the block (that link carries it, as described below). It does not save it in its database, and its request log does not record it (Section 3.3). A report stores only the order ID and the time. Like any website, our server also receives the buyer's IP address and browser details with each call (see connection data in Section 3.3).

Optional feature. The buyer fix page below is off unless we make it available and the merchant turns it on.

The buyer fix page (optional, only when the merchant turns it on). A merchant can let buyers correct the recipient and shipping address themselves. Buyers reach the page through a link in the order confirmation email, on the thank-you page or on the order status page. That link carries the shop, the order ID and the order's confirmation number, and each visit opens a page that works for 2 hours. Staff can also create a link to send to a buyer themselves, which works for 7 days. The page opens only for gift orders that have recipient details. It closes when the order is cancelled or fulfilled, when a fulfillment service has started on it, or when no fulfillment order is visible to the App 10 minutes after the order was placed (which means a fulfillment service the App cannot see or hold has the order). It also closes when the order carries a tag the merchant chose for this and, unless the App's hold is on the order or staff created the link, once a time the merchant sets after the order has passed. The thank-you and order status pages offer the link only while the page could open or, for an order placed in the last 10 minutes, while the App is still recording the order.

The page shows whoever opens the link the recipient's name and phone number, the delivery details, the full shipping address with its phone number, and the shop's name, so the link should be kept private. The page also links to this policy. The buyer can correct these details; the country cannot be changed, and delivery details the page does not show are kept as they are. The App stores:

• the order ID, a scrambled (hashed) form of the link's code, when it was created, its expiry and when it was last used, and, for a staff-created link, the email of the staff member who created it;
• when the buyer saves a change: a before-and-after copy of the details, the time, a report record (if the order does not already have one), and an access log entry recorded as "customer";
• when the buyer presses "These details are correct" (offered while the App's hold is on the order, and refused if the buyer has typed changes without saving them): the time only.

Wrong confirmation numbers are counted in the server's memory, per order, and are not saved. After 10 wrong attempts within an hour of the first one, the link stops working for that order until that hour is up. The server also limits how many start links can be opened from one IP address (30 in 10 minutes) and, for order IDs the App has no record of, for one shop (120 in an hour, checked against the App's own records before it asks Shopify about the order), counting them in memory in the same way. The IP address is the one our edge network provider, Cloudflare, reports for the request or, failing that, one taken from the request's other forwarding headers, so this limit is best effort. These counts are reset when the server restarts. The fix page sets no cookies and loads nothing from other websites, with one small exception described in Section 12.

The order confirmation email. The App gives merchants a short template to paste into Shopify's order confirmation email. It shows the buyer the recipient, the shipping address and the delivery details, and, when the fix page is on, a link to it. Shopify sends this email, not us.

3.3 Data the App Creates

• Gift order records: the order ID and number, the time placed, the buyer's gift answer, a copy of the recipient details, and a copy of the shipping name and address (name, first and last name, company, address lines 1 and 2, city). They also hold the result of the name check, which rule decided it and other signals that contain no names, plus the matched name words. These are either the recipient-name words found in the shipping details, or the buyer's first and last name found in the shipping name. Each record also tracks the holds the App placed and released, the outcome staff recorded and who recorded it, and when the buyer reported a problem, corrected or confirmed the details, and when the App started deleting its recipient field from the order in Shopify (Section 7).
• Correction history: each correction by staff, or by a buyer on the fix page, keeps a before-and-after copy of the recipient details and the full shipping address, including phone number, together with who made it (the staff member's email, or "customer").
• Data request records: when Shopify passes on a buyer's request for their data, the App records the request ID, the buyer's Shopify customer ID and the order IDs requested.
• Report records: the order ID and the time of the first buyer report or fix-page correction on that order.
• Fix-link records: described above (only when the fix page is on). They hold the order ID, but no customer names, addresses or phone numbers; a staff-created link also holds the email of the staff member who created it.
• Staff access log: one entry each time staff open the Needs attention or All gift orders lists, view or change an order, or download a data-request export, and each time a buyer saves a correction on the fix page. Each entry holds the shop, who acted (the staff member's email, or their Shopify user ID if there is no email, or "customer"), the type of record and its internal ID, the action, and the time. It contains no customer names, addresses or phone numbers. Buyers opening the fix page, and staff creating a fix link, are not logged.
• Technical records: a receipt for each Shopify notification (its ID, topic, shop and time, but not its contents), and records of background tasks such as placing or releasing holds. These hold internal IDs, attempt counts and any error message Shopify returned, and, for the task that deletes the App's recipient field from orders in Shopify, the Shopify order IDs concerned.
• Server logs: our hosting provider, Render, keeps the App's server logs. For each request, the App's request log records only the method, the path of the web address with any query string removed and the code in a fix link masked, the result, the size and the response time. On the App's order pages, that path includes the Shopify order ID. The request log never records confirmation numbers, fix-link codes or Shopify sign-in tokens. The App's own event logs record shop domains, internal IDs and error reasons rather than names or addresses. Occasionally an error record can contain a staff email address, an order ID, the path of the page that failed (with any query string removed and the code in a fix link masked, as in the request log), or values from the order being processed, such as a name. Render deletes the logs after the log retention period of our plan, which we keep to 28 days at most.
• Connection data and provider request records: every request to the App from a staff member's or buyer's browser reaches Render through its edge network provider, Cloudflare (Section 6). Both receive the request's web address, IP address and browser details (user agent) as part of the connection. The App's own request log and database do not record IP addresses or browser details. Separately from the App's logs, Render and Cloudflare may keep their own records of requests, which can include these details, for a limited time in their own platform, security and operations logs, under their own terms and retention periods.

3.4 Data We Do NOT Collect

• Buyers' email addresses. We do not request Shopify's access to customer email, and the App does not read or store buyers' email addresses. The only email addresses the App stores are those of the merchant's staff, from Shopify sign-in.
• Payment details, prices or order contents. The App does not read card or bank details, transactions, prices, totals or the items ordered. Any charges for the App are billed by Shopify, and we never receive merchants' payment details.
• The buyer's billing address or account phone number. Only the first and last name on the billing address is read, for the name check, and only matched name words are kept. The App does read and store the shipping phone number. If the buyer's browser filled the shipping form automatically, that number may be the buyer's own.
• Passwords. Staff sign in through Shopify; the App never sees their passwords.
• Tracking. No advertising or tracking cookies, and no tracking of people across other websites or apps. The App's own database and request log do not record IP addresses (the fix page's request limit counts them in memory only, Section 3.2); our hosting provider and its edge network receive them as described in Section 3.3.
• The order note. The App reads the order note so it can add or update its own line without changing anything else, but it does not store the note.

4. How We Use Data

We process personal data to provide the App:

• The name check: comparing the recipient name with the shipping name, and the buyer's name with the shipping name, to spot gifts that look set to ship to the buyer (see Section 9).
• Flagging and holding orders: tagging flagged orders, and placing a fulfillment hold in Shopify with a note (by default naming the recipient and the shipping name) so staff know what to check. The App releases only holds it placed itself.
• Staff review: showing flagged and gift orders in the App's lists and order pages, so staff can check details with the buyer and record what they found.
• Corrections: when staff (or, with the fix page on, the buyer) correct the recipient or address, updating the order in Shopify.
• Getting the recipient onto the paperwork: writing a "Gift recipient (Ship To Who)" line into the order note, which Shopify's default packing slip prints, and saving the recipient details in an order field that staff can see on the order page in Shopify. The merchant can stop new note lines being added; a line already on an order is kept up to date when the order is corrected. If Shopify sends the App the same order notification again after a correction, or after the App has deleted its copy of the recipient details, the App does not put the original details back into the note line or the order field.
• Buyer recap and reports: showing buyers what they entered and letting them report a problem.
• Data requests and deletion: handling buyers' requests that Shopify passes on (Section 8).
• Measuring accuracy for the merchant: keeping check results and staff outcomes, without names or addresses, to show the merchant how accurate the check has been in its store (the Accuracy page). These figures are worked out for each store from its own orders only and, in the App, are shown only to that store. We look at a store's figures only to support that store or with its agreement, for example in a review of how the App is working for it.
• Checking where the App is offered: reading the country and province or state of the store's business address and whether it is a development store, so the App serves only the stores described in Section 11.
• Security and reliability: verifying that requests come from Shopify, keeping the staff access log, limiting attempts on fix links (wrong confirmation numbers per order, start requests per IP address, and requests for orders the App has no record of per shop), and diagnosing errors.
• Support and service notices: answering questions, and contacting a merchant's staff about matters such as incidents or security issues affecting their store.

We do not use any of this data for marketing, advertising or profiling, and we do not send it to any artificial-intelligence service. We do not compute or use accuracy figures across stores; across stores, the App's server logs record only operational totals, such as how many records the daily clean-up deleted.

5. Legal Basis for Processing (GDPR)

This section applies where the GDPR or the UK GDPR applies to the processing (Section 11).

For order and recipient data, the merchant, as the data controller, decides and documents the legal basis under Article 6 of the GDPR. Bases that commonly apply include:

• Performance of a contract (Art. 6(1)(b)): delivering the order the buyer placed to the person and place the buyer chose.
• Legitimate interests (Art. 6(1)(f)): the merchant's interest, shared by buyers and recipients, in getting gifts delivered to the right person, and in catching address mistakes before an order ships. This also covers the recipient's details, since the recipient is not a party to the sale, and the comparison of the buyer's name with the shipping name.

Hospital delivery details are likely to be data concerning health (Section 3.2), a special category under Article 9 of the GDPR. The hospital delivery type is off unless the merchant turns it on. A merchant that turns it on must identify a condition under Article 9(2) that applies to it. The App processes these details only on the merchant's instructions and deletes them on the schedule in Section 7. Merchants are responsible for confirming the legal basis for their store and for telling buyers and recipients about it in their own privacy notice.

For the data we hold as an independent controller (Section 2), BrightLayer Lab LLC relies on its legitimate interests (Art. 6(1)(f)) in operating, securing and supporting the App, keeping an accountable record of who accessed customer data, and keeping our website available and secure. It relies on performance of its contract with the merchant (Art. 6(1)(b)) for account and support administration. Staff members who want to exercise their rights over this data can contact us at support@shiptowho.com.

6. Data Sharing and Sub-processors

We do not sell personal information, and we do not share personal information for cross-context behavioral advertising (within the meaning of the California Consumer Privacy Act, as amended by the California Privacy Rights Act).

Shopify (the merchant's platform). Shopify is the platform the merchant uses, not a service provider we engage. The App receives all order and recipient data from the merchant's Shopify store and writes back to it. Shopify processes that data under its agreement with the merchant and its own privacy policy. The App writes:

• an order tag (by default ship-to-who-check) on flagged orders;
• an app-owned order field holding the recipient's name, phone number, delivery type and details, which staff can see on the order page in Shopify but cannot edit or delete. While the App is installed, it deletes this field when it deletes its own copy of the recipient details (the daily clean-up, a buyer's erasure request, or a merchant's request to clear a recipient's details), and in any case 55 days after the order was placed, and from then on does not write it on that order again, even when the order is corrected. After uninstalling it can no longer do so (Section 7);
• a "Gift recipient (Ship To Who)" line in the order note, with the recipient's name, delivery type and details, and phone number;
• fulfillment holds. By default, the hold note names the recipient and the shipping name and links to the order in the App; merchants can change the wording. Holds placed because a buyer reported a problem or used the fix page carry a fixed note without names. The App asks Shopify to notify the merchant's staff of each hold, so Shopify may send them the note; and
• when staff or a buyer save a correction, the corrected shipping address (including phone number) and recipient details.

Other apps the merchant has given access to orders can also read the order note and order attributes. Section 7 explains what happens to this data when the App deletes its own copies.

Our sub-processors. We disclose personal data only to the following service providers, which process it so we can run the App. Our DPA lists them (Annex 3) and explains how we tell merchants about changes (Section 4.4).

• Render (render.com) hosts the App's server in the United States. It processes all of the App's data while handling requests, keeps the server logs described in Section 3.3, and holds the App's configuration secrets. Render delivers the App's traffic through its edge network provider, Cloudflare (cloudflare.com), which processes each request in transit, including its contents, web address, IP address and browser details, as Render's sub-processor. Cloudflare handles a request at its network location nearest the sender, which may be outside the United States, for example in Canada or Europe. Staff and buyers' browsers reach the App this way, including for the thank-you and order status block and the fix page, and so do Shopify's notifications.
• Neon hosts the App's database on Amazon Web Services in the United States. It stores the App's database records: the shop, credential and staff records in Section 3.1 and the records in Section 3.3, apart from the server logs and connection data.
• Zoho Mail hosts our support mailbox, support@shiptowho.com, in the United States. It receives only what people choose to send us.
• As required by law: we may disclose data to comply with legal obligations, court orders or government requests.

Website infrastructure (visitors to shiptowho.com): separately, our public website is served through our own Cloudflare account, which provides hosting, DNS and protection against attacks, and processes standard request data from visitors (such as IP address, browser type and request time). The website receives no order or recipient data.

7. Data Retention

Data Retention Statement

Ship To Who keeps a gift recipient's details (name, phone number and delivery details) and the order's shipping name and address for 30 days after the order is fulfilled or cancelled, or 60 days after it was placed, whichever comes first. A daily clean-up then deletes them, normally within a day of that date. When a merchant uninstalls the App, all recipient and address data is deleted immediately. Everything else held for the store is deleted when Shopify sends its store deletion request, normally 48 hours after uninstalling. If that request has not been processed 30 days after uninstalling, the daily clean-up deletes everything the App holds for the store, normally within a day of that date, unless the merchant has reinstalled and opened the App in the meantime. Server logs and our database provider's restore history are not deleted with it; they age out on their own short schedules, set out below. The staff access log, which contains no customer names, addresses or phone numbers, is kept for 18 months. While the App is installed, it also deletes its recipient field from the order in Shopify when the daily clean-up, a buyer's erasure request or a merchant's request to clear a recipient's details (Section 8) deletes its own copy of the recipient details, or 55 days after the order was placed if that comes first. The other recipient details it writes into the merchant's Shopify orders stay in Shopify, as explained under "Data in Shopify" below.

Retention Details

Uninstalling. When a merchant uninstalls the App, Shopify notifies us. The App then immediately deletes the store's staff session records and access credentials, unfinished background tasks and fix links, and all recipient and address data for the store's orders. The remaining records, which hold no customer names, addresses or phone numbers, stay until Shopify sends its store deletion request, normally 48 hours later. We then delete everything the App holds for that store, apart from server logs and restore history, which age out as described here. If that request has not been processed 30 days after uninstalling, the App's daily clean-up deletes everything the App still holds for the store, normally within a day of that date, unless the merchant has reinstalled and opened the App in the meantime. A merchant who reinstalls before the records are deleted keeps their settings and accuracy history, but not the deleted recipient data. "Data in Shopify" below explains what happens to the App's recipient field in Shopify after uninstalling and on a reinstall.

Backups. Deleted data can remain in our database provider's restore history for up to 6 hours on our current Neon plan, and never more than 28 days, after which it is gone. We do not keep other copies of the production database. If we ever have to restore the database from that history, we run the daily clean-up straight away, which clears restored recipient details past their deletion date and deletes the restored data of any store uninstalled more than 30 days earlier. Before the App resumes normal processing, we re-apply the erasure requests, uninstall clean-ups and store deletions received after the restore point that we can identify, and we ask affected merchants to send again any erasure requests from the period we restored over.

Data in Shopify. What the App wrote into the merchant's Shopify store is handled as follows:

• The order tag, the order note line, and any corrected shipping address and recipient order attributes are ordinary order data. The App does not change them when it deletes its own copies, when it is uninstalled or when Shopify passes on a buyer's erasure request. The merchant can edit or delete them in Shopify.
• The App's recipient order field is app-owned: staff can see it but cannot edit or delete it. While the App is installed, when it deletes its own copy of an order's recipient details, at the daily clean-up above, for a buyer's erasure request or when a merchant asks us to clear a recipient's details (Section 8), it also deletes this field from that order in Shopify shortly afterwards, and in any case 55 days after the order was placed (normally within a day of that date), before Shopify's 60-day limit on the orders the App can reach. If Shopify cannot be reached, the App keeps trying for up to an hour; if it still cannot, the App records the failure in its server logs and its next daily clean-up tries again, as long as the order was placed less than 60 days earlier. If Shopify refuses the deletion, the field stays on that order and the App records the failure in its server logs. Once the App has started deleting the field from an order, it does not write it on that order again, even if the deletion failed or staff or the buyer later save a correction. After uninstalling, the App can no longer reach the store, so it does not delete the field: Shopify takes the field off the order page and deletes its stored values later, on Shopify's own schedule. If the merchant reinstalls and opens the App before Shopify removes them, the field reappears on the orders where the App had not deleted it. If the App still holds the store's records at that point (normally only in the first 48 hours after uninstalling), its next daily clean-up deletes the field from those orders, including any whose deletion was still under way when the App was uninstalled; otherwise the App no longer knows those orders and does not delete it.
• Staff cannot edit the note on a hold the App placed, and the App does not change it when it deletes its own copies. Shopify handles hold records under its own terms.

8. Data Subject Rights

Buyers and recipients may exercise the following rights by contacting the merchant (the data controller):

Under the GDPR or UK GDPR, where it applies (Section 11):

• Right of access: Request a copy of personal data held about you
• Right to rectification: Request correction of inaccurate data
• Right to erasure: Request deletion of personal data
• Right to data portability: Receive data in a structured, machine-readable format (JSON)
• Right to object: Object to processing based on legitimate interests
• Right to restrict processing: Request limitation of processing
• Right to lodge a complaint: File a complaint with a data protection supervisory authority in your country of residence

Under the Australian Privacy Act 1988, where it applies:

• Right of access: Request access to personal information held about you (APP 12)
• Right to correction: Request correction of inaccurate, out-of-date, incomplete, or misleading personal information (APP 13)
• Right to complain: Lodge a complaint with the Office of the Australian Information Commissioner (OAIC) if you believe your privacy has been breached

In Canada: see Section 14. In California: see Section 13.

How requests reach the App. When a buyer asks a merchant for their data, or asks for it to be erased, Shopify passes the request to the App, and the App handles it as follows:

• Access: the App records the request (its ID, the buyer's Shopify customer ID and the order IDs) and lists it on the App's Settings page, which shows the 20 most recent requests. Staff download a JSON file of the recipient, shipping and correction details the App still holds for those orders: the order ID and number, the recipient details, the shipping name and address, the matched name words, and the correction history with dates. Staff identities are left out, and each download is recorded in the access log. The file does not include the other records the App keeps about those orders, which hold no names, addresses or phone numbers: the check result and its signals, holds, the staff outcome, report and fix-page times, and other timestamps (Section 3.3). Merchants can ask us for these at support@shiptowho.com, and we will send them within 15 days. The App sends no email or alert about the request, so merchants should check the Settings page; we also check for new requests at least once a week and remind the merchant within 7 days of a request arriving. Because the App deletes recipient data on the schedule in Section 7, the file for an older order may hold only the order ID and number and the dates of any corrections; most order details are in Shopify itself, where the merchant can provide them.
• Erasure: for the orders listed in the request, the App deletes the recipient details, the shipping name and address, the matched name words and the before-and-after copies of corrections, and deletes those orders' fix links and report records. It also deletes the App's records of data requests from that buyer. While the App is installed, it also deletes the App's recipient order field from those orders in Shopify (see "Data in Shopify" in Section 7, which also covers the other data the App wrote into Shopify). Until the store's data is deleted, it keeps the order IDs and numbers, check results, holds, staff outcomes and timestamps (for the merchant's accuracy figures), and the staff email addresses on outcomes and corrections (a record of who acted). None of these contain the buyer's or recipient's name, address or phone number. Access-log entries about those orders stay for their 18-month period, and server log lines that include an order's ID stay until Render deletes them (Section 7). If, after the request, staff or the buyer save a correction to one of those orders, the buyer opens the fix page, or the buyer reports a problem, the App creates new records: a new before-and-after copy is kept until the order's normal clean-up date, a new fix link until it expires and the daily clean-up deletes it, and a new report record until the store's data is deleted. A saved correction does not write the App's recipient order field in Shopify again.
• Correction: staff can correct the recipient and shipping address from the order page in the App, which updates the order in Shopify, or edit the order in Shopify directly.

Recipients. Shopify passes on requests from buyers, keyed to the buyer's own orders. A recipient who is not the buyer should contact the shop that sent the gift. A recipient can also write to support@shiptowho.com. We will pass the request to the merchant promptly and act on the merchant's instructions. When a merchant asks, within 15 days we send it what the App holds about a recipient for the orders concerned, or clear the recipient details from the App. While the App is installed, clearing them also deletes the App's recipient field from those orders in Shopify (Section 7).

Our support to merchants. We help merchants respond to these requests. We will respond to reasonable written requests about data the App holds (for example for access, correction, objection or restriction) without undue delay and within 15 days, and in any case in time for the merchant to meet its legal deadline.

Staff. Merchant staff can contact us directly at support@shiptowho.com about data we hold as controller (Section 2). Some records, such as the access log, exist to show who viewed customer data; where the law allows, we may keep them for their retention period.

9. Automated Decision-Making

The name check. The App checks each order with a shipping address automatically, using fixed rules:

• If the buyer chose "It's for me", the order is not flagged.
• If no recipient name was entered, the order is not flagged.
• If any word of the recipient's name (other than titles such as Mr or Dr) appears in the shipping name, company or address line 2, the order is not flagged.
• If no word of the recipient's name appears and the shipping name contains the buyer's own first and last name, the order is a strong mismatch. If the recipient was entered with a family word such as "Mom" or "Grandma", it is only a weak mismatch.
• If no word of the recipient's name appears and the shipping name is not clearly the buyer's, the order is a weak mismatch.

Flagged orders are tagged and listed in the App. A strong mismatch, or a weak one if the merchant chooses, also gets a fulfillment hold in Shopify. The App also places a hold when a buyer reports a problem or corrects their details on the fix page. A hold only pauses fulfillment so staff can look. Staff decide what happens: they check with the buyer, then save a correction (recorded as Fixed) or record a false alarm, and the hold is released. If the buyer changed the details on the fix page after staff loaded the order, the App refuses to save the correction or record the false alarm until staff reload and see the change, and the Needs attention list offers no one-click "False alarm" on an order the buyer changed. The App never cancels or refunds an order or changes the shipping address on its own. It does not score or profile buyers, and it does not use artificial intelligence.

In our view, the hold is not a decision that has legal or similarly significant effects on a person. It is a pause for human review. Even so, anyone affected can ask the merchant for a person to review the outcome, give their point of view, or contest it, using the contact details the merchant provides. Staff can release a hold or mark a flag as a false alarm at any time.

10. Data Security

We use the following measures:

• Encryption in transit: all connections to the App use HTTPS. Connections between the App and its database must use TLS.
• Encryption at rest: we require our database provider to encrypt stored data, its backups and its restore history at rest. This includes the Shopify access credentials, which the App stores in its database.
• Authentication: the App's admin pages require a Shopify staff session. Calls from the thank-you and order status block need a session token signed by Shopify, and a report is accepted only with the order's matching confirmation number. Notifications from Shopify are accepted only with a valid Shopify signature.
• Fix links (when on): each link code is 32 random bytes, and only a scrambled (hashed) form is stored in the App's database. Links expire, repeated wrong confirmation numbers lock an order's link for up to an hour, and the number of links opened from one IP address, or for orders the App has no record of in one shop, is limited. The pages ask browsers not to cache them, not to pass their address to other sites, and ask search engines not to index them.
• Data minimization: the App requests Shopify's protected customer data for name, address and phone only, not email. It reads only the order fields it needs, deletes recipient data on a fixed schedule, and keeps no copy of Shopify's order notifications.
• Least privilege: the App asks Shopify for read and write access to orders (including the buyer's first and last name on each order, used only for the name check) and access to fulfillment orders so it can place and release holds. It does not ask for access to customer records.
• Access logging: staff access to customer data in the App is recorded in an access log (Section 3.3). Buyers opening the fix page, and staff creating a fix link, are not recorded. If an entry cannot be saved to the database, it is written to the server logs instead.
• Production access: only BrightLayer Lab LLC's owner can access production systems and data, and only when needed to run, support or secure the App.
• Data loss prevention: production data is not copied outside our hosting and database providers, except the minimum needed for a specific support request or security investigation, which is encrypted and deleted when the work is done. It is never put into code repositories, tickets, chat, screenshots or AI tools.
• Secrets: credentials are kept in our hosting provider's environment settings, never in source code.
• Test data: development and automated tests use BrightLayer Lab's own development stores, separate databases and made-up data, never merchants' data.
• Incidents: if a personal data breach affects a merchant's data, we will notify the merchant without undue delay and no later than 72 hours after we become aware of it, as set out in our DPA (Section 4.6). For data we control ourselves (Section 2), we notify supervisory authorities and affected people where the law requires.

These measures are set out in more detail in Annex 2 of our DPA and in our Security and Incident Response Policy, which we make available to merchants on request at support@shiptowho.com. Inside the App, any staff member the merchant's Shopify account lets into the App can see all of its pages. Merchants should control which staff have access to the App in Shopify. We have not completed a third-party security audit, SOC 2 report, ISO 27001 certification or penetration test. No system is perfectly secure, but we work to protect the data we hold.

11. International Data Transfers

Where the App is offered. The App is offered only to merchants established in the United States, or in Canada outside Quebec (Terms of Service, Section 4). It is not offered to merchants established in Quebec. Shopify development stores, which hold only test data, can use it wherever they are. To apply this, the App reads from Shopify the country and province or state of the store's business address (the business details in the store's Shopify settings, or the store address if there are none) and whether the store is a development store, keeps them with the store's details (Section 3.1) and checks them again at most once a day, or each time the App is opened while the store is not served. If the business address is outside the United States and Canada, or in Quebec, the App's pages in the Shopify admin show only a message saying where the App is available and where Shopify places the store. It records nothing from that store's new orders or from buyer reports on its thank-you and order status pages, and its fix page does not open. If the App cannot determine the store's country, it serves the store and records that in its server logs. If the business address is in Canada and the App cannot determine its province, it also serves the store. Shopify's privacy requests (Section 8), its store deletion request, the clean-up when a merchant uninstalls and the daily clean-up (Section 7) always run, for every store. A merchant whose store is not served can write to support@shiptowho.com about any data the App holds for it.

Where data is processed. The App and its database are hosted in the United States (Render and Neon), and our support mailbox is hosted by Zoho in the United States. Personal data the App handles is stored, and processed by the App, in the United States, wherever the merchant, buyer or recipient is located. On the way, requests to the App pass through Cloudflare's network locations, which may be in other countries (Section 6). In the United States, personal data may be accessible to courts, law enforcement and national security authorities under US law. Section 14 explains what this means in Canada.

Where the GDPR, the UK GDPR or the Swiss FADP applies. Although the App is offered only to merchants in the United States and in Canada outside Quebec, one of these laws may still apply to some of its processing, for example to data about a served merchant's buyers or recipients located in the European Economic Area (EEA), the United Kingdom or Switzerland. Where it does, we rely on appropriate safeguards under Chapter V of the GDPR, and the equivalent UK and Swiss rules, for transfers of that data to the United States:

• The European Commission's Standard Contractual Clauses (Module Two — Controller to Processor) and the UK International Data Transfer Addendum (where data is transferred from the United Kingdom), with the adaptations needed for Swiss data, incorporated into Section 6 of our Data Processing Agreement with each merchant, published at https://shiptowho.com/dpa.
• The Standard Contractual Clauses and data processing terms published by our service providers, for transfers to and from those providers.

BrightLayer Lab LLC is not certified under the EU-US Data Privacy Framework or its UK and Swiss extensions.

12. Cookies and Tracking

In the App. Ship To Who sets no cookies of its own: not in the Shopify admin, on the fix page, or in the blocks it adds to the store, checkout and order status page. Staff sign in through Shopify session tokens, not cookies. The App uses no tracking pixels, advertising cookies or analytics tools. In the admin and on the fix page, the web framework the App is built with saves page scroll positions, and after an update a version marker, in the browser's session storage. This holds no personal data and is cleared when the tab closes.

The App's pages other than the fix page (its admin pages, and its public start and sign-in pages) load Shopify's App Bridge script and a font from Shopify's servers. Shopify's admin, storefront and checkout use Shopify's own cookies under Shopify's privacy policy. The recipient form relies on Shopify's cart cookie, which keeps the shopping cart. The fix page loads nothing from other websites, except that the page shown when a fix-page link does not work can ask the browser to preload Shopify's App Bridge script from Shopify's servers.

Buyers' consent choices. The App sets no cookies of its own and does not use customer data for marketing, advertising, analytics tracking or profiling. It uses that data only to provide the App to the merchant, for the purposes in Section 4, mainly to check, hold and correct the merchant's orders and to show each store its own accuracy figures, and it does not override any consent choices a buyer makes in the merchant's store.

On our website. Our public website, shiptowho.com, uses Cloudflare Web Analytics to count visits in aggregate (for example page views and referring sites). It is cookieless, sets no identifiers in the visitor's browser, does no cross-site tracking, and does not identify individual visitors. The website sets no cookies of its own and has no forms. Cloudflare processes this data as described in its own privacy policy, and we rely on our legitimate interest in understanding and improving our website. Cloudflare's hosting, DNS and attack protection for the website also rely on our legitimate interest in keeping it available and secure, and Cloudflare keeps the related request data under its own terms.

13. California Privacy Rights (CCPA/CPRA)

When we process personal information for a merchant, we do so as the merchant's service provider, only to provide the App. As a service provider, we do not sell or share that personal information; we do not retain, use or disclose it outside our direct business relationship with the merchant, or for any purpose other than providing the App; and we do not combine it with personal information from other sources except as the CCPA regulations allow. Delivery details that may be sensitive personal information, such as hospital details, are used only to deliver the order and never to infer characteristics about anyone. Under other US state privacy laws, such as those of Virginia, Colorado and Connecticut, we act as the merchant's processor, and requests should go to the merchant.

If you are a California resident, you may have rights under the California Consumer Privacy Act (CCPA) and the California Privacy Rights Act (CPRA), including:

• Right to know: Request disclosure of the categories and specific pieces of personal information collected about you.
• Right to delete: Request deletion of your personal information.
• Right to correct: Request correction of inaccurate personal information.
• Right to opt out of sale/sharing: We do not sell or share personal information for cross-context behavioral advertising.
• Right to non-discrimination: We will not discriminate against you for exercising your privacy rights.

To exercise these rights, California residents should contact the merchant (data controller) directly. Merchants may contact us for assistance in fulfilling these requests.

14. Privacy Rights in Canada

In Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA), or a substantially similar provincial law such as Quebec's Act respecting the protection of personal information in the private sector (as amended by Law 25), may apply to personal information the App handles. Under these laws the merchant remains accountable for the personal information of its buyers and recipients. It uses us as its service provider under our Data Processing Agreement, and we use that information only to provide the App to the merchant.

• Access and correction: you can ask the merchant for access to the personal information held about you and for correction of anything inaccurate or incomplete. Merchants can ask us for help (Section 8). Merchant staff can ask us directly about data we hold as controller (Section 2).
• Complaints: if you are not satisfied with the response, you can complain to the Office of the Privacy Commissioner of Canada; in Quebec, to the Commission d'accès à l'information du Québec; or, where Alberta's or British Columbia's Personal Information Protection Act applies, to that province's Information and Privacy Commissioner.
• Storage in the United States: your personal information is stored, and processed by the App, in the United States (Section 11), where it may be accessible to courts, law enforcement and national security authorities under US law. On the way, requests from your browser pass through Cloudflare's network locations, which may be in Canada or other countries (Section 6).

For merchants in Canada. The App is not offered to merchants established in Quebec (Section 11). Your own privacy notice should tell buyers and recipients that a service provider stores and processes their information in the United States. For that notice, and for any privacy assessment you carry out, this policy and our Data Processing Agreement and its annexes set out where the data is stored and processed, the categories of data, our safeguards and our sub-processors, and we answer further questions at support@shiptowho.com within 15 days. If a breach affects your data, reporting it to the Office of the Privacy Commissioner of Canada or a provincial privacy authority and notifying affected people, where PIPEDA or a provincial privacy law requires, is your responsibility. We notify you within 72 hours of becoming aware of it (Section 10), with the information you need to do so.

15. Children's Privacy

Ship To Who is a business service provided to Shopify merchants. It is not directed at children, and we do not knowingly collect personal data from children under 16. Recipient details can relate to a child, for example a delivery to a school. These details come from the adult buyer, are used only to deliver the order, and are deleted on the schedule in Section 7. If a merchant's store serves minors, or a gift is sent to a child, the merchant is responsible for complying with applicable children's privacy laws.

16. Changes to This Policy

We may update this Privacy Policy from time to time. When we do, we will change the date at the top. Where a change is material or the law requires it, we will also give notice on our website and by email to merchants as described in our Terms of Service (Section 14), or through another appropriate channel such as the App's Shopify App Store listing.

17. Contact

For privacy-related inquiries:

• Company: BrightLayer Lab LLC
• Address: 8401 Mayland Dr #10685, Richmond, VA 23294, USA
• Email: support@shiptowho.com
• Website: https://shiptowho.com

Buyers and recipients should send requests about their data to the merchant (the data controller) first. Merchants can reach us at the email above for help with any request.