Privacy Policy

Last updated: October 7, 2026

1. Introduction

BrightLayer Lab LLC ("we," "us," "our") operates the Return Wise application ("App"), a Shopify application that helps merchants manage product returns by offering customers store credit (with optional bonus incentives), a refund to their original payment method, or an exchange for a different item. The App can also show return-package tracking and, where the merchant enables it, generate a return shipping label for the customer. This Privacy Policy explains how we collect, use, store, and protect personal data when you use our application.

2. Data Controller and Processor Roles

Under the General Data Protection Regulation (GDPR) and similar data protection laws:

• For merchant customer return data, the merchant who installs Return Wise is the data controller. They determine the purposes and means of processing their customers' personal data.
• BrightLayer Lab LLC (Return Wise) acts as a data processor for that merchant customer return data when we process it to provide the return management service.
• For merchant account, session, support, security, admin-activity (audit trail), and compliance-contact data relating to use of the App itself, BrightLayer Lab LLC acts as an independent data controller. Audit entries that document a specific customer's return — or a staff decision about a customer, such as clearing, blocking, or unblocking them, and the approval requests for those actions — are treated as part of that customer's data: they are deleted when that customer's data is erased (for a return the retention cleanup has already removed, only while they can still be linked to the customer — see Section 7), and are otherwise kept for the audit-trail period in Section 7 (clearing a flag, or its expiry, does not remove them).

3. Data We Collect

3.1 From Merchants (via Shopify)

• Shop domain and Shopify store identifier
• Merchant/admin account information made available by Shopify, such as user email, first name, last name, locale, and account status
• Merchant notification email address (if configured)
• Merchant-designated compliance contact email address
• App configuration and settings
• Return policy text a merchant pastes into the optional AI policy assistant (a plan-dependent feature), to the extent it contains personal data
• Admin activity (audit trail): Actions taken in the app admin (for example approving a return, issuing a refund, or changing settings) are recorded with the acting staff member's email address and, for staff-initiated actions, the IP address and browser user-agent string of the request. BrightLayer Lab LLC acts as an independent controller for these staff-activity records (see Section 2); audit entries that document a specific customer's return, or a staff decision about a customer, are treated as that customer's data and are deleted with it. The trail exists to give merchants an accountability record of money-touching actions and settings changes.

3.2 From Customers (via Merchant's Store)

When a customer looks up an order or initiates a return through a merchant's store — via the storefront return portal or, where the merchant enables it, the customer's Shopify customer account — we collect or process:

• Order lookup information: Order number and email address submitted in the return portal
• Order information: Order number, order ID, line items, product titles, variant details, item prices, and currency
• Customer contact information: Email address
• Customer identifier: Shopify customer ID (if available)
• Return details: Selected items, return reasons, reason notes, quantities, and — where the customer requests an exchange — the requested replacement variant(s)
• Item photos: Where the merchant's plan includes photo upload, customers may attach photos of the items they are returning; a merchant may require a photo for specified return reasons, risk rules, or a returnless-refund offer. Photos are stored in object storage (see Sections 6 and 11) and shown to the merchant to support return review. Customers are asked to photograph the item only; any personal data incidentally visible in a photo is processed only as part of the image.
• Return shipping address: Where the merchant enables return shipping labels, the customer's order shipping address — recipient name, street address, city, state/province, postal code, country, and any phone number on the order — is retrieved from the order and sent to the merchant's chosen shipping-label provider to generate the return label. For box-free drop-off, the postal code and country are also used to locate nearby drop-off points. This address is retrieved from the order when a label is quoted or generated for the return — by the merchant, or automatically where the merchant enables automatic labels. (A merchant may instead upload their own return-label file, which itself shows the customer's name and return address and is stored in object storage — see Sections 6 and 11.)
• Ship-to country: The country of the order's shipping address, read from the order when a return is started — in the return portal, in the customer's account, or by the merchant's staff — and, where the merchant has configured return-location routing, again when the return is submitted. It is used to decline returns for orders shipping to Brazil, based on the country Shopify reports (see Section 3 of the Terms of Service for the limits of that check), to apply return fees the merchant conditions on the ship-to country, and to choose which of the merchant's return locations a return is sent to. The country is carried within the customer's return session and is not saved with the return; a routed return records which return location was chosen.
• Fulfillment data: Fulfillment dates associated with returned items
• Customer tags: Retrieved from Shopify for rule evaluation (e.g., loyalty status)
• Security and request metadata: IP address and related request metadata used for rate limiting, abuse prevention, and operational security

Entered by the merchant's staff. A merchant's staff can block a customer from starting new returns — including a customer who has not started one — by entering the customer's email address, and must give a written reason whenever they clear, block, or unblock a customer. Return Wise stores that email address, the reason, and any approval request for the action (see Section 9). The reason is shown to the merchant's staff and is included in a copy of the customer's data (Section 8); merchants should keep it factual and limited to what the decision needs.

3.3 Data We Generate

• Return request records (status, timestamps, idempotency keys)
• Native store credit references, including Shopify refund IDs, store credit account IDs, and bonus store credit transaction IDs
• Original-payment refund records, including Shopify refund IDs, the confirmation source, and completion timestamps
• Exchange records: the requested replacement item(s) and references to the Shopify draft or replacement order created to fulfill an exchange
• Return shipping label records (where the merchant enables labels): the carrier and tracking number, label and QR-code links, drop-off location context (postal code and country), and label cost. For a generated label we retain only the fields just listed — the drop-off context is the customer's postal code and country, while the street address and contact details are not kept; the shipping provider's response is discarded after the tracking handle is extracted. Where a merchant instead uploads their own label file, that file shows the customer's ship-to name and address and is stored in object storage (see Sections 6 and 11). Both follow the return record and are deleted with it (see Section 7)
• Return tracking records: the carrier and tracking number, normalized carrier status, carrier-event descriptions and timestamps, and the time tracking last changed. These may come from a generated/uploaded label or from tracking-only details the merchant enters independently of a Return Wise/provider-generated label. Tracking-only fields follow the return record and are deleted with it (see Section 7)
• Transactional email records: for each email the App sends, the recipient address, the subject, the sender and reply-to headers, the rendered message body, and the delivery state (pending, sent, failed, or undeliverable) — retained so failed sends can be retried, so the merchant can see what was sent about a return, and so the merchant can resend the original message (see Sections 6 and 7)
• Outbound-webhook delivery records (where the merchant enables webhooks): the merchant-configured destination URL, the exact message body sent, and the delivery state (see Sections 6 and 7)
• Abuse detection flags and blocks — raised automatically (see Section 9) or placed by the merchant's staff with the reason they give — and the approval requests for staff actions on them
• Rule evaluation records and the audit trail described in Section 3.1
• Plan usage counters and overage charge records used for billing (return counts per billing period and per-return overage charge entries; see the Terms of Service for billing mechanics)
• Analytics aggregates (return volumes, savings metrics)
• AI policy-assistant drafts: suggested return rules, return fees, settings, and customer-facing copy generated from merchant-provided policy text, together with the short excerpts of that text each suggestion is based on. A draft that is never applied is deleted 30 days after it is created (or 30 days after the merchant discards it); an applied draft is kept with the shop's settings and audit history until the shop's data is deleted
• AI return-reason classification results: for merchants who enable the optional classifier, a structured categorization of each return reason (return intent, likely root cause, an abuse-risk signal, and a confidence value), stored alongside the return item
• AI photo evaluations (where the merchant enables the plan-dependent AI photo review): suggested product-condition tags, a descriptive severity, a confidence score, and usage/wear signals generated from a customer's return photo, stored alongside the photo record together with any tag corrections the merchant makes. These are suggestions to assist the merchant's review; they do not make or automate the refund decision

3.4 Data We Do NOT Collect

• Payment card numbers or bank account details
• Passwords or authentication credentials
• Customer browsing behavior or tracking cookies

We do not use the customer's street address for order lookup, return eligibility, refunds, or store credit. The App reads a customer's shipping address in two ways. First, for return shipping labels (Section 3.2): when a label is quoted or generated, the address is retrieved from the order and shared with the merchant's chosen shipping-label provider to price or produce it (see Section 6); the street address and contact details are then discarded — the label record keeps only tracking identifiers plus the address's postal code and country, retained as drop-off context (to locate nearby drop-off points and for carrier-aware copy); when the merchant instead uploads a return-label file, that file shows the customer's name and return address and is stored in object storage until the return is deleted (see Sections 6, 7, and 11). Second, the App reads only the address's country (Section 3.2) to decline returns for orders shipping to Brazil, to apply return fees the merchant conditions on the ship-to country, and to route returns to the merchant's return locations. The address is not used for marketing, profiling, or any other purpose.

4. How We Use Data

We process personal data solely to provide the return management service:

• Processing returns: Creating and managing return requests, evaluating rules, issuing store credit, and declining returns for orders shipping to Brazil, based on the country Shopify reports (see Section 3 of the Terms of Service for the limits of that check)
• Return fees and return locations: Where the merchant configures them, deducting return fees from the refund or store-credit amount, including fees that depend on the order's ship-to country. If the order's ship-to country can't be determined (for example, an order with no shipping address) and such a fee could apply to the return, the standard refund to the original payment method is not offered for that return; store credit remains available, as does any returnless-refund offer, which carries no fees. Where the merchant has configured return-location routing, choosing the return location by ship-to country
• Original-payment refunds: Creating a Shopify refund to the customer's original payment method when the merchant or staff initiates it, or when the merchant has expressly enabled a rule-driven automated refund (including a capped returnless-refund offer that the customer accepts). Merchant-configured review thresholds and approval controls may hold an automated refund for review before issuance.
• Return review: Storing customer-submitted item photos and displaying them to the merchant so the merchant can assess the returned item's condition
• Exchanges: When a customer chooses an exchange, creating a Shopify draft or replacement order for the requested item, invoicing any price-up difference or issuing any price-down remainder as store credit
• Return shipping labels: When the merchant enables it, generating a return shipping label (and, where offered, a carrier QR code for box-free drop-off) by sending the return's addresses and parcel details to the merchant's chosen shipping-label provider and emailing the label or tracking link to the customer
• Return tracking: Receiving or retrieving carrier updates for generated labels and for tracking-only carrier/number details a merchant enters independently (including for an uploaded external label), showing those updates to the customer and merchant, sending optional in-transit/delivered notifications, and highlighting delivered returns that still await merchant receipt. If the merchant has connected Shippo for tracking-only updates, Return Wise sends only the carrier and tracking number to Shippo to register that package; it does not send the customer's address, email, order history, return reason, refund amount, abuse flags, or photos for tracking-only registration.
• Fraud prevention: Detecting unusual return patterns to protect merchants from abuse, and letting the merchant's staff review a customer's flag and clear, block, or unblock the customer, with a recorded reason
• Notifications: Sending transactional emails (return confirmation, credit issuance, rejection notices), and storing each message with its delivery state so a failed send can be retried automatically and the merchant can review or resend what was sent about a return
• Outbound webhooks: Where the merchant enables and configures them, sending signed return-event messages to a destination URL of the merchant's choosing so the merchant can connect Return Wise to their own systems (see Section 6)
• Guest customer support: Creating or locating a minimal Shopify customer record and attaching it to an order when needed to issue native Shopify store credit
• Analytics: Providing merchants with aggregated return statistics (no individual customer profiling)
• Native store credit issuance: Creating Shopify store credit refunds for eligible return amounts and optional bonus store credit transactions, at the issue timing the merchant configures — which, where the merchant enables it, may release the credit as soon as the return is submitted (before the item is shipped or received) or on the first carrier scan of the return label
• AI-assisted setup: When a merchant chooses to use the optional AI policy assistant, drafting suggested return rules, return fees, settings, and customer-facing copy from the merchant-provided return policy text
• AI-assisted return analysis: When a merchant enables the optional AI return-reason classifier, categorizing return reasons to surface return intent, likely root cause, and abuse-risk signals that help merchants understand and triage returns (see Sections 6 and 9)
• Security and reliability: Rate limiting request flows, validating sessions, and monitoring the service
• Accountability: Maintaining an audit trail of actions taken in the app admin (see Section 3.1) so merchants have a reviewable record of money-touching actions and settings changes
• Billing administration: Counting processed returns against the merchant's plan allowance and, on plans with metered overage, submitting per-return overage charges through Shopify's billing system at the per-return rate shown on the plan the merchant approved (no customer personal data is included in billing submissions; see the Terms of Service for billing mechanics)
• Compliance handling: Delivering privacy and data-rights communications to the merchant-designated compliance contact email on file
• Service communications: Notifying merchants about matters affecting their installation of the App — such as incidents, defects, or outages; security notices; usage, billing-administration, and abuse-prevention alerts; and administrative follow-ups — sent to the contact addresses in the App's settings (which one depends on the notice) or, for some notices when none is set, to an email address of the store's staff that Shopify has provided to the App; if no address is available, no email is sent. These are operational notices, not marketing

We do not use customer data for marketing, advertising, or cross-context behavioral profiling, or for any purpose unrelated to the return management service. We may use automated analysis of return history, refund values, return-pattern signals, and — where the merchant enables it — AI classification of return reasons, for fraud and abuse prevention and return triage, as described in Sections 6 and 9.

5. Legal Basis for Processing (GDPR)

For customer return data, the merchant — as the data controller — determines and documents the legal basis for processing under Article 6 of the GDPR. Common legal bases that may apply, depending on the merchant's policies and customer relationship, include:

• Performance of a contract (Art. 6(1)(b)) — for processing return requests and sending transactional emails about a return
• Legitimate interest of the merchant (Art. 6(1)(f)) — for fraud and abuse prevention and for aggregated return analytics

Merchants are responsible for confirming and documenting the legal basis applicable to their store and informing customers in their own privacy notice. The limited categories of data Return Wise processes as an independent controller (merchant account, support, security, admin-activity, and compliance-contact data) are described in Section 2.

For those independent-controller categories, BrightLayer Lab LLC relies on its legitimate interests (Art. 6(1)(f)) in operating, securing, supporting, and maintaining the accountability of the App (including its audit trail and protected-data access logs), and on the performance of its contract with the merchant (Art. 6(1)(b)) for account and support administration. We retain that data as described in Section 7 — for example, audit-trail records for 18 months by default and data-subject-export access logs for the duration of the installation — and delete it on those schedules and on shop data deletion. If you are a merchant user or staff member and wish to exercise your data-subject rights (such as access, correction, or deletion) in respect of data we hold as controller, contact us directly at support@returnwise.app.

6. Data Sharing

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). We disclose personal data only to the service providers and sub-processors listed below, who process data on our behalf to operate the return management service:

• Shopify: Data is read from and written to Shopify via their Admin API. Reads include order lookups (including the country of the order's shipping address — see Section 3.2), customer records, and customer tags (used as inputs to rule evaluation only). Writes include native store credit refunds, bonus store credit transactions, return summary details added to Shopify order notes, and order tags applied for merchant record-keeping (e.g., "ReturnWise-Credit"); for guest orders, the App may also create or locate a minimal customer record and attach it to the order so native store credit can be issued. The App does not write customer tags. Data written to Shopify's platform is governed by Shopify's own privacy policy and persists independently of Return Wise.

• Shopify Sidekick (optional, merchant-invoked): If the merchant uses Shopify's built-in Sidekick assistant to ask about their returns, Return Wise returns read-only return information to Sidekick so it can answer — the order number, the customer's email, the return status and payout type, refund or store-credit amounts and currency, the selected return reason codes (never the customer's free-text notes), item counts and return submission dates, and, where the merchant's plan includes abuse guardrails, abuse-flag data (a risk score, the flag reason, and whether the customer is currently blocked). The reasons the merchant's staff give are never included, and neither is a customer whose only flag is a block staff placed by hand; a customer the automatic system flagged is reported with that flag, including after staff have blocked them. Sidekick is Shopify's own assistant operating inside the Shopify admin, invoked only when the merchant asks; the data it receives returns to the Shopify platform and is governed by Shopify's own privacy policy. This flow is read-only — it surfaces information to answer the merchant's question and never approves, rejects, refunds, or takes any money-touching action on its own. Access through this flow is recorded in the protected-customer-data access log (see Section 7), except for aggregate-metrics queries, which return no customer-linked data.

• Hosting provider: The application and database are hosted on Render (render.com), which acts as a sub-processor. Render's privacy policy and data processing terms apply to infrastructure-level data handling.

• Object storage (return photos and uploaded label files): Customer-uploaded return photos are stored in Cloudflare R2 (cloudflare.com), an S3-compatible object storage service, which acts as a sub-processor for this data. Photos are uploaded by the customer's browser and read by the merchant's photo viewer via short-lived signed URLs; the storage buckets are not publicly listable. The same storage also holds return-label files that a merchant uploads for a return (rather than generating through a connected label provider); such a label shows the customer's name and return shipping address, and is retrieved through a signed link — valid for minutes when shown on screen to the customer or merchant, and up to seven days for a link emailed to the customer. Files for merchants established in the EU/EEA are stored in an EU-jurisdiction bucket (see Section 11). Stored photo and label files are deleted from storage when the associated return records are deleted (see Section 7).

• Email delivery: Transactional emails are sent via Resend (resend.com), a transactional email provider configured and operated by Return Wise. Resend receives recipient email addresses and message content (order numbers, return details, store credit amounts, and links) in order to deliver the email, and may retain message data, delivery events, and logs under its own privacy policy and Data Processing Addendum. Return Wise also keeps its own copy of each message — the recipient address, subject, sender and reply-to headers, and the rendered message body — alongside its delivery state. That copy exists for delivery reliability: an email that the mail provider does not accept is retried automatically over approximately a day, after which it is marked undeliverable, the merchant can see a delivery history for a return, and the merchant can resend the original message unchanged. Stored messages are retained for the merchant's configured retention period and are deleted on a customer erasure request or shop data deletion (see Sections 7 and 8). GDPR data export payloads are deliberately excluded from email content — those snapshots are retrieved by the merchant from the authenticated app admin.

• Merchant-configured webhook endpoint (optional): Where a merchant enables outbound webhooks (a plan-dependent feature that is off unless the merchant configures it), Return Wise sends a signed message to a destination URL chosen by the merchant when a return is created, changes status, completes, or fails. The message contains only the event name and the time it occurred, the shop domain, the return request and order identifiers, the order number, the return status and the status it changed from, the payout type chosen for the return, and the refund or store credit amount and currency; no customer name, email address, shipping address, return reason, reason note, or photo is included. The merchant chooses the destination and is responsible for that endpoint and for any onward processing there — it is not a Return Wise sub-processor. Return Wise stores each dispatch (destination URL, message body, and delivery state) so failed deliveries can be retried, the merchant can review a delivery log, and the merchant can redeliver a message.

• Shipping-label and tracking provider: For a label the merchant asks Return Wise to generate, Return Wise sends the return's addresses and parcel details to the merchant's chosen shipping-label provider (the currently supported providers are listed in the App and in Section 4.4 of the Data Processing Agreement) to generate the label and (where offered) a carrier QR code and retrieve carrier tracking. The provider receives the ship-from (customer) and ship-to (merchant return location) addresses — recipient name, street address, city, state/province, postal code, country, and, where available, phone and email — plus parcel dimensions, and returns the label and tracking number. Separately, when a merchant enters tracking-only carrier/number details (with or without an uploaded external label) and has connected Shippo, Return Wise may send only that carrier and tracking number to Shippo's tracking-only service so carrier updates can be received. No customer address or contact information is sent in that tracking-only request. In either case, no order history, return reasons, store-credit amounts, abuse flags, or photos are sent. The merchant connects and controls the provider account, so the provider also processes the data under the merchant's agreement with that provider.

• AI service provider: Return Wise uses OpenAI (openai.com) as a sub-processor for two optional, merchant-enabled features:

  • AI policy assistant: Return Wise sends the merchant-provided return policy text and, to ground the suggested rules in the merchant's own catalog, the store's list of product types and product tags (catalog metadata retrieved from Shopify — not customer data); it receives back structured draft rules, return fees, settings, customer-facing copy, and excerpts of the policy text supporting them. No historical return records, order records, customer records, customer tags, abuse flags, or return photos are sent for this policy-drafting feature. Because product types and tags are merchant-authored free text, merchants should avoid placing personal data in them; any personal data they happen to contain is processed only to the extent present.
  • AI return-reason classifier (a plan-dependent feature that is off unless the merchant enables it): to categorize why items are being returned, Return Wise sends, per returned item, the product and variant title, the selected return reason, and the customer's free-text reason note, and receives back a structured classification (return intent, likely root cause, and an abuse-risk signal). Before transmission, free-text reason notes are passed through an automated redaction step that removes email addresses and card-like or long numeric sequences, and are truncated to a short length. Order numbers, customer names, customer email addresses, customer tags, order or customer records, abuse flags, and return photos are not sent for this feature. Because reason notes are free text, a customer could include other personal details in them; the redaction step is automated and not guaranteed to catch every such detail.

  In both cases, OpenAI's API data controls apply, including OpenAI's default policy that API data is not used to train OpenAI models unless explicitly opted in by the API customer. Return Wise sends these calls with OpenAI's storage/logging disabled (the store=false API parameter) so the inputs and outputs are not retained as logged completions; under OpenAI's standard API data policy, OpenAI may still retain the inputs and outputs for a limited period (up to 30 days) to monitor for abuse and misuse, after which they are deleted (except where OpenAI must retain them longer to meet a legal obligation).

• AI service provider (return photos): If a merchant enables AI photo review (an optional plan-dependent feature, off by default), Return Wise asks OpenAI (openai.com) to evaluate the visible condition of items in customer return photos for the return reasons the merchant selects. To do this, Return Wise generates a short-lived signed link to the photo — valid for 10 minutes — which OpenAI's service fetches to perform the evaluation; the link expires shortly afterward and the image is not made publicly accessible. Return Wise sends only the photo and minimal product context (product title, variant title, and the return reason code); it does not send customer names, email addresses, or the customer's free-text notes for this feature. The AI is instructed to describe only the product and its packaging and never to identify people or infer personal characteristics. This processing is governed by OpenAI's API data usage policies, including OpenAI's default policy that API inputs are not used to train OpenAI models unless the API customer explicitly opts in. As with the other AI features, the call is sent with OpenAI's storage/logging disabled (store=false); under OpenAI's standard API data policy, OpenAI may still retain the photo and context for a limited period (up to 30 days) to monitor for abuse and misuse, after which they are deleted (except where a legal obligation requires longer).

• As required by law: We may disclose data to comply with legal obligations, court orders, or government requests.

Website infrastructure (visitors to the public site): The public Return Wise marketing and legal pages on returnwise.app are served via Cloudflare (cloudflare.com), which provides edge delivery, DNS, and DDoS protection. Cloudflare processes standard request metadata for visitors to the public site (IP address, User-Agent, request timing) at the network edge. This edge-delivery role for the public website is separate from Cloudflare R2's role as the App's object storage sub-processor described above; the App's data flows and complete sub-processor list are governed by Section 4.4 of the Data Processing Agreement.

7. Data Retention

• Return request data is retained according to the merchant's configured retention period (default: 12 months, configurable from 1 to 60 months).
• Terminal return records (completed, rejected, or failed) older than the retention period are removed by our scheduled retention cleanup process, which is ordinarily run daily. Pending (non-terminal) returns are kept until they resolve or the shop's data is deleted; and, on our legitimate interest in preventing return abuse, a blocked abuse flag — raised automatically, or placed by the merchant's staff with the reason given — or an unresolved anomaly alert (which can carry a customer's email) is kept until the merchant clears, unblocks, or resolves it (a stored block can be cleared on every plan, including after a downgrade to a plan without customer blocking); both are deleted when that customer's data is erased (see Section 8) and on shop data deletion. While the merchant's plan does not include customer blocking, a stored block no longer refuses the customer's returns, but — like any open flag — it still withholds the offers a flag withholds (such as instant exchanges) until it is cleared. Approval requests to clear, block, or unblock a customer are removed by the retention cleanup once older than the merchant's configured retention period, counted from when they were decided (an undecided request expires within the merchant's 1–30 day approval window first).
• Files stored in object storage follow their return records: when a return record is deleted — by the retention cleanup, a customer erasure request (customers/redact), or shop data deletion — the stored return photos and any merchant-uploaded return-label file are deleted from object storage as part of the same process. A daily reconciliation sweep additionally removes stored photo or label files that no longer have (or never had) an associated return record. Uploads abandoned before their record was created (for example a photo before the return was submitted, or a label file before it was attached) are ordinarily removed within a few days. A rare transient deletion failure is surfaced to our operations alerting, and the file it left behind is removed by the sweep or, if the file was stored for more than a week, after our operations team has reviewed it. As a safeguard against deleting files that still belong to live returns, a file stored for more than a week that no return record accounts for is never deleted automatically: while one exists, the sweep deletes nothing until our operations team has reviewed it, and such files are deleted only once confirmed to belong to no return. The sweep may also be paused when we restore or move the production database, for at least a week afterwards; files it then finds are deleted only after our operations team has reviewed them.
• Transactional email records (recipient address, subject, headers, rendered message body, and delivery state) are removed by the scheduled retention cleanup once they are older than the merchant's configured retention period, regardless of whether the message was delivered. They are also deleted as part of shop data deletion, and when a customer's data is erased so are the emails sent to that customer, the emails linked to their returns, and emails to the merchant that contain the customer's email address. Emails to the customer are found by their address and emails to the merchant by their content, never the other way round (an email to the merchant is not deleted because it was sent to an address that is also a customer's, and an email to a customer is not deleted because its footer shows the store's support address); an email to the merchant that names one of the merchant's staff is not deleted by that staff member's address. The search runs early in the erasure and again as its last step. An email to the merchant about a staff decision on the customer, or an alert or digest that names them, is either linked to one of the customer's returns (and deleted with it, or never stored once that return is gone) or stored together with the decision or alert it reports, so one made at the same moment as the erasure is either deleted with it or, if made after it, treated as new activity.
• Outbound-webhook delivery records (where the merchant enables webhooks) follow the same rule: they are removed once older than the merchant's configured retention period, regardless of delivery outcome. Records relating to a specific customer's returns are deleted when that customer's data is erased, and all records are deleted as part of shop data deletion.
• Audit trail records are retained for 18 months by default and then removed by the scheduled cleanup; they are also deleted as part of shop data deletion, and audit entries tied to a specific customer's returns, or recording a staff decision about a customer (with the reason given) and the approval requests for it, or an offer made to them, are deleted when that customer's data is erased. Once the retention cleanup has removed a return, the audit entries tied to it (its order number, amounts, and the actions taken) can no longer be linked to the customer, except those that carry the customer's email address; the rest are removed with the audit trail at the end of its own period.
• Rule-evaluation logs record only the non-identifying rule-decision facts of an evaluation (the return reason and product attributes assessed and the resulting rule action) and hold no customer, order, or return identifier. They are removed by the scheduled retention cleanup once older than the merchant's configured retention period, and are deleted in full as part of shop data deletion. Because they hold no customer identifier they are not located by an individual customer's erasure request (see Section 8).
• GDPR data export snapshots compiled in response to customers/data_request webhooks are retained inside the authenticated app admin and auto-purged 30 days after the request is received, regardless of fulfillment status.
• GDPR protected-data access logs — recording which staff member viewed, downloaded, or fulfilled an export snapshot, or opened the list of data-subject requests, and when (the acting staff member's email, the request reference — or an internal marker, for list views — the action, and a timestamp; never the export payload or a customer's email) — deliberately outlive the 30-day snapshot purge and are retained as an accountability record for the duration of the app's installation, then deleted when the shop's data is deleted. The access-log rows for a specific customer's export are additionally deleted when that customer's data is erased. As these records concern staff activity, we act as an independent controller for them (see Section 2) and rely on our legitimate interests in maintaining an accountability record of access to protected data.
• Protected-customer-data access logs — recording which staff member opened certain surfaces that expose protected customer data, and when: a return (the customer's email and the signed links to their photos and any name-and-address label), the flagged-customers list and the actions taken from it, the approvals queue when it lists requests about a customer, the audit log and its export, the full shop export, and the Sidekick reads described in Section 6 (list views such as the returns queue and the alerts page, which show customer email addresses, are not logged). Each row holds only the acting staff member's email, an internal reference (a record identifier, or a fixed marker for a list or an export), the action (view, download, or update), and a timestamp — never the customer's name, email, or address. These logs are kept as an accountability record (by default 18 months), then removed by the scheduled cleanup, and are deleted on shop data deletion. Because they hold no customer identifier they are not located by an individual customer's erasure request. We act as an independent controller for these staff-activity records (see Section 2) and rely on our legitimate interests in maintaining an accountability record of access to protected data.
• AI policy-assistant drafts: applied drafts are retained alongside the shop's settings and audit history; a draft that is never acted on is auto-purged 30 days after creation, and a draft the merchant discards is auto-purged 30 days after it is discarded, both by the scheduled cleanup; all drafts are deleted when the shop's data is deleted (see below).
• AI photo-review assessments (only where the merchant has enabled the optional AI photo review): the stored assessment of an item's visible condition is retained for the merchant's configured AI photo-evaluation retention period — by default 180 days, configurable by the merchant from 1 to 365 days — and is then removed by the scheduled cleanup, independently of the return record it describes. This setting governs the AI assessment only; the return photo itself follows its return record under the merchant's general retention period above. Both are deleted when that customer's data is erased and on shop data deletion.
• Photo-upload replay-prevention records: where a photo is accepted as return evidence, Return Wise keeps a one-way digest of that photo's randomly generated storage key, the shop domain, and the time the record expires. This record exists solely to stop evidence that was already used for one refund from being reused for another, and it expires shortly after that can no longer happen: a photo can only be used to obtain a refund for 24 hours from the point it is attached to a return request, so the record is kept for that 24-hour period plus a fixed 48-hour safety margin and is then removed by the scheduled cleanup — approximately four days in total, and always less than the merchant's configured retention period. It holds no photo, no readable storage key, no record of when the evidence was used, and no customer, order, or return identifier, and it cannot be used to contact, profile, or make any decision about a customer. Return Wise relies on its legitimate interests in strictly necessary fraud prevention and service security for this record (see Section 5 and Section 5.1 of the Data Processing Agreement).
• Merchants can adjust their retention period at any time in the app settings.
• Upon app uninstallation, Shopify sends an app/uninstalled webhook and (ordinarily 48 hours later, under Shopify's compliance schedule) a shop/redact webhook. On app/uninstalled, Return Wise keeps the shop's data (settings and return records) during a short reinstall grace period (approximately 48 hours); a merchant who reinstalls within it keeps them. After the grace period elapses, Return Wise's scheduled cleanup permanently deletes the shop's data from the App's database and file storage (stored files are cleaned up as described above). If shop/redact arrives, Return Wise deletes the shop's data from its database and file storage immediately, without waiting for the grace period (stored files are cleaned up as described above). Note that data previously written to Shopify (such as store credit refunds, bonus store credit transactions, the minimal customer record created for a guest order, order notes, and order tags) is managed by Shopify and is not affected by this deletion.
• Encrypted database backups kept by our hosting provider, and operational logs kept by our providers, are not edited to remove individual records; they expire on those providers' rolling schedules, and backups are restored only to recover the service after a failure or security incident. This applies to every deletion described in this Section and in Section 8.

8. Data Subject Rights (GDPR / UK GDPR / Australian Privacy Act)

Customers may exercise the following rights by contacting the merchant (data controller):

Under GDPR / UK GDPR:

• Right of access: Request a copy of personal data we hold
• 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 interest
• 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:

• Right of access: Request access to personal information we hold 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

When a merchant receives a data subject request, we support them by:

• Data export: Upon Shopify's customers/data_request webhook, Return Wise automatically compiles the customer's data — found through the email address the request carries and the customer's Shopify identifier, or through the identifier alone when the request carries no email address — and stores the snapshot inside the authenticated app admin (the Compliance page). A short notification email is sent to the merchant-designated compliance contact with a link to the admin; the customer's identifying details and the compiled payload are never included in the email subject or body. Snapshot access is logged for compliance review, and snapshots are auto-purged 30 days after the request is received, regardless of fulfillment status.
• Data deletion: Permanently deleting the customer-linked records enumerated in Section 5.3 of the Data Processing Agreement — including return requests and items, tracking-only carrier/number/status fields, uploaded photos (with their stored image files), return shipping labels (with any label file we host), stored transactional emails sent to the customer, linked to their returns, or containing their email address, outbound-webhook delivery records for the customer's returns, and related AI photo-evaluation, abuse, and audit records — upon Shopify's customers/redact webhook. That section carries the authoritative enumeration. The request finds the customer's records through the email address it carries and the addresses on the customer's returns, in any capitalization of the letters A–Z (any other character must match exactly, so a look-alike address belonging to someone else is never treated as the customer's); a block that the merchant's staff placed on some other email address is not linked to that customer and is not found by the request (it remains until the merchant clears it or the shop's data is deleted). Two internal record types are not part of this per-customer deletion because they hold no customer identifier and so cannot be located by an erasure request. Separately, audit entries recorded by earlier versions of the App for a return submission refused by the risk score, or for a keep-it or returnless offer, carry the order number and amounts but no customer identifier; they are not located by an erasure request either, and are removed with the audit trail after 18 months by default. The same holds for the audit entries of a return that the retention cleanup has already removed (see Section 7). A return submission already in progress at the moment the erasure runs is processed as new activity: a return, flag, or refusal record it creates, and the merchant alert it triggers, are kept like any later activity, and a later request deletes them. Rule-evaluation logs (see Section 7) store only non-identifying rule-decision facts and are instead aged out on the merchant's retention schedule. The short-lived replay-prevention record described in Section 7 above likewise holds no customer identifier; it instead expires on its own, within approximately four days of the evidence being used. In the ordinary case it is already gone by the time Shopify delivers the erasure webhook (customers/redact is sent no earlier than ten days after the request is made). Where return evidence happens to be used in the few days immediately before the webhook arrives, the record can briefly outlive the erasure — it still expires on its own fixed schedule, and at all times it contains no photo, no readable storage key, and no customer, order, or return identifier. Encrypted database backups and operational logs are not edited to remove the customer's records; they expire on their providers' rolling schedules (see Section 7). Note that data previously written to Shopify's own systems (such as store credit refunds and other store credit transactions, the minimal customer record created for a guest order, replacement orders created for exchanges, order notes, and order tags) is not affected by this deletion and is managed by Shopify.

9. Automated Decision-Making

Return Wise includes an optional abuse detection feature that may automatically flag a customer, hold their return for manual merchant review, or block them from submitting further returns — through the self-service portal, through the customer's Shopify account, or as a return created by the merchant's staff. The merchant (data controller) configures this feature and can disable it. The decision may draw on:

• Threshold signals — the number of returns, and the cumulative return value, per customer within merchant-configured rolling time windows.
• A behavioral risk score — a weighted score computed from return-pattern signals such as rapid repeat submissions, repeated returns of the same product, a first-time customer requesting a high-value return, and (where the merchant requires photos) missing photo evidence. The merchant sets the score thresholds at which a return is held for manual review or blocked, and may turn the score-based behavior off.

The optional AI return-reason classifier is not an input to this automated decision. Where enabled, it produces an abuse-risk signal that is displayed to the merchant to help them triage returns manually (see Section 6); it does not feed the behavioral risk score and does not itself flag, hold, or block any return.

These thresholds and risk settings are configured by the merchant (data controller). Merchants can review flagged customers and the risk factors that contributed (Returns → Flagged customers), clear or unblock them there (a flag can also be cleared from the customer's return), and adjust or disable the automatic behavior in the app settings.

Separately from this automated feature, the merchant's staff can block a customer by hand — or clear or unblock one — giving a reason each time. A manual block is a human decision, not automated decision-making; it refuses the customer's new returns in the same way. Where the merchant requires manager approval for these actions, a staff member's action waits for a manager's approval before it takes effect; a manager's own action applies directly.

In accordance with Article 22(3) of the GDPR, customers affected by this automated decision-making have the right to:

• Obtain human intervention — request that a human, rather than the automated system, review the block decision
• Express their point of view — provide context or information the merchant should consider
• Contest the decision — dispute the block and request it be reversed

These rights are exercised by contacting the merchant (data controller) directly, using the support contact information the merchant provides. Merchants are required to review and respond to such requests, and can reverse an automatic block from the Flagged customers page or the customer's return.

The optional AI return-reason analysis and AI photo review features are not automated decision-making within the meaning of Article 22: they produce suggestions (intent/risk signals, condition tags, severity) that surface to the merchant for review. Those AI outputs do not approve, reject, refund, or block any return on their own and can be overridden or dismissed by the merchant. Any automated refund is instead governed by a separate rule and safety controls that the merchant expressly configures, as described above.

10. Data Security

We implement the following security measures:

• Encryption in transit: All data is transmitted over HTTPS/TLS
• Authentication: Customer portal sessions use signed session tokens; merchant admin endpoints require Shopify session authentication
• Rate limiting: Customer-facing endpoints are rate-limited to prevent abuse
• Input validation and output encoding: User inputs are validated and sanitized, and user-supplied content is encoded to prevent XSS
• Duplicate-prevention controls: Return creation includes controls to prevent duplicate processing of the same request

11. International Data Transfers

Return Wise is hosted on Render (render.com) with servers located in the United States. If you are located in the European Economic Area (EEA), United Kingdom, or other jurisdictions with data transfer restrictions, your data will be transferred to and processed in the United States. We rely on appropriate safeguards under Chapter V of the GDPR for such transfers, including:

• 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), incorporated into our Data Processing Agreement with each merchant
• The Standard Contractual Clauses and Data Processing Addenda published by our sub-processors (listed in Section 4.4 of the Data Processing Agreement) for transfers to and from those providers

Geographic availability. Return Wise is not yet offered to merchants established in the EEA, the United Kingdom, or Switzerland (see the Geographic limitation section of our Terms of Service; the App checks for this at the store level, based on the billing country Shopify reports — see Section 3 of the Terms for the limits of that check). The safeguards in this section therefore currently operate for the processing that can still involve those jurisdictions — for example, where a merchant established elsewhere processes a return for its own customer located in the EEA or the United Kingdom — and will govern transfers from merchants established in those jurisdictions if and when availability opens.

EU data residency for stored files: Customer-uploaded return photos, and any return-label file a merchant uploads, for merchants established in the EU/EEA are stored in an EU-jurisdiction object storage bucket rather than the default (US) bucket. Other application data (return records, settings) remains hosted in the United States under the safeguards above. Because Return Wise is not currently offered to merchants established in the EEA (see Geographic availability above), this residency path is not in use today: a served merchant's stored files are held in the United States regardless of where their customer is located.

12. Cookies and Tracking

Within the Return Wise app — the merchant admin and the customer return portal — Return Wise does not use advertising or cross-context behavioral tracking cookies, tracking pixels, or third-party analytics technologies. The Shopify OAuth installation flow may set essential cookies required to complete authentication; these are not used for advertising or analytics. Customer portal sessions are managed via signed tokens transmitted in the request body rather than session cookies. Return Wise does not set cookies in its customer return portal.

Our public marketing and legal website (returnwise.app) uses Cloudflare Web Analytics to measure aggregate site traffic (for example page views and referrers). It is cookieless, sets no client-side identifiers, performs no cross-site tracking, and does not identify individual visitors; it is not used inside the app or the customer return portal. Cloudflare processes this data as described in its own privacy policy, and we rely on our legitimate interest in understanding and improving the public website.

The return portal carries language codes in its links and form requests. A customer can explicitly choose a language without losing their return selections; unfinished selections are kept in browser memory during that change, not in cookies or local storage. When a return is submitted through the portal, the customer’s explicit language choice is stored with the return record for subsequent emails and status pages. If the customer makes no explicit choice in the portal, the email language follows the order’s language where available, subject to the store’s supported portal languages and language-detection settings. Returns submitted through Shopify Customer Accounts instead use the account language, with the order language and a default as fallbacks; staff-created returns use the order language, with English as the fallback. These other channels choose the email language from languages supported by Return Wise without applying the store’s portal language restrictions or detection setting. Their status links open the return portal, where the store’s portal language settings apply. The stored preference follows the return record for retention and deletion (see Section 7). Language information is not used for advertising, customer tracking, or cross-site profiling.

Where the optional partner referral program is active, the merchant-facing installation flow may set a single first-party, strictly functional attribution cookie (rw_partner) when a merchant arrives via a partner referral link. It stores only a partner identifier, is read once at installation to credit the referring partner, expires after 30 days, is HTTP-only, and is never used for advertising, customer tracking, or cross-site profiling. It is not set in the customer-facing return portal.

13. California Privacy Rights (CCPA/CPRA)

If you are a California resident, you may have additional 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 we have collected.
• Right to delete: Request deletion of your 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. Children's Privacy

Return Wise is a B2B service provided to Shopify merchants. We do not knowingly collect personal data from children under 16. If a merchant's store serves minors, the merchant is responsible for ensuring compliance with applicable children's privacy laws.

15. Changes to This Policy

We may update this Privacy Policy from time to time. We will update the effective date above when changes are posted. Where required by law, we will provide additional notice through the Shopify App Store listing, email, the app interface, or another appropriate channel. Continued use of the app after changes take effect constitutes acceptance of the revised policy.

16. Contact

For privacy-related inquiries:

• Company: BrightLayer Lab LLC
• Address: 8401 Mayland Dr #10685, Richmond, VA 23294
• Email: support@returnwise.app
• Website: https://www.returnwise.app/

For data subject requests, customers should contact the merchant (data controller) directly. Merchants can reach us at the email above for assistance with data requests.