Privacy Policy

Last updated: August 11, 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 are treated as part of that customer's return data and follow it (including deletion on erasure requests).

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 are treated as that customer's return 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 the merchant generates a label for the return. (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.)
• 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

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
• 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, settings, and customer-facing copy generated from merchant-provided policy text, stored as draft records until the merchant applies or discards them
• 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 collect the customer's physical address for order lookup, return eligibility, refunds, or store credit. The App processes a customer's shipping address only in connection with return shipping labels (Section 3.2): when the merchant generates a label, the address is retrieved from the order and shared with the merchant's chosen shipping-label provider to 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). 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
• 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
• 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 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 merchant's configured contact email or, where none is configured, to a staff or admin email on file for the store (as provided by Shopify at installation). 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, 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). 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 and customer-facing copy. 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/manually-set abuse flag or an unresolved anomaly alert (which can carry a customer's email) is kept until the merchant clears or resolves it — both are deleted when that customer's data is erased and on shop data deletion.
• 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 any stored photo or label file that no longer has (or never had) an associated return record, covering uploads abandoned before their record was created (for example a photo before the return was submitted, or a label file before it was attached) and rare transient deletion failures; such failures are also surfaced to our operations alerting.
• 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 emails sent to — or naming — a specific customer are deleted when that customer's data is erased.
• 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 are deleted when that customer's data is erased.
• 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 a return that exposes protected customer data (the customer's email and the signed links to their photos and any name-and-address label) and when. Each row holds only the acting staff member's email, the internal return identifier, the action, 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. Return Wise marks the shop on app/uninstalled and preserves its configuration during a short reinstall grace period (approximately 48 hours), so a merchant who reinstalls within that window does not lose their settings. After the grace period elapses, Return Wise's scheduled cleanup permanently deletes all shop data. If shop/redact arrives, Return Wise deletes all shop data immediately, without waiting for the grace period. Note that data previously written to Shopify (such as order notes and order tags) is managed by Shopify and is not affected by this deletion.

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 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 or naming the customer, 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. 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. 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. Note that data previously written to Shopify's own systems (such as order notes and 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. 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, manually unblock them, and adjust or disable the automatic behavior at any time in the app settings.

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 at any time from the app settings.

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, which the App enforces technically at the store level). 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 JWT tokens transmitted in form data rather than session cookies; the customer portal sets no cookie other than strictly functional ones, and at present that is only the language cookie described below.

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.

When a customer selects a language in the return portal, Return Wise stores that choice in a single first-party, strictly functional cookie (rw_lang) so the portal — and any follow-up emails about the return — stay in that language. It holds only a language code, expires after one year, and is never used for advertising, customer tracking, or cross-site profiling. The customer's selected language is also stored alongside their return record so later emails match the language they chose; that stored preference follows the return record for retention and deletion (see Section 7).

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.