Data Processing Agreement (DPA)

Last updated: July 30, 2026

This Data Processing Agreement ("DPA") forms part of the Terms of Service between the merchant ("Data Controller," "you") and BrightLayer Lab LLC, a Virginia LLC that operates the Return Wise application ("Return Wise," "Data Processor," "we," "us"). This DPA governs the processing of personal data by the Data Processor on behalf of the Data Controller.

1. Definitions

Personal Data: Any information relating to an identified or identifiable natural person, as defined in Article 4(1) of the GDPR.
Processing: Any operation performed on personal data, as defined in Article 4(2) of the GDPR.
Data Subject: The identified or identifiable natural person to whom personal data relates (i.e., the merchant's customers).
Sub-processor: Any third party engaged by the Data Processor to process personal data on behalf of the Data Controller.
Applicable Data Protection Law: GDPR (EU) 2016/679, UK GDPR, the Australian Privacy Act 1988, and any other applicable data protection legislation.

2. Scope and Purpose

2.1 Subject Matter

The Data Processor processes personal data to provide the Return Wise return management service as described in the Terms of Service.

2.2 Duration

Processing continues for the duration of the merchant's use of the App, plus any retention period required to fulfill legal obligations or complete data deletion.

2.3 Nature and Purpose of Processing

Activity	Purpose
Return request creation	Process customer return requests on behalf of the merchant
Rule evaluation	Determine return offer based on merchant-configured rules
Native store credit issuance	Issue Shopify store credit refunds and optional bonus store credit transactions
Original-payment refund processing	Create a Shopify refund to the customer's original payment method when the merchant or staff initiates it, or under a rule-driven automation the merchant has expressly enabled (including a capped returnless-refund offer accepted by the customer); apply configured review/approval controls and reconcile refund state via Shopify webhooks
Exchange processing	When a customer chooses an exchange, create a Shopify draft/replacement order for the requested item(s), invoice any price-up difference to the customer, or issue any price-down remainder as store credit; where the merchant enables it, create the replacement before the returned item is received (instant exchange)
Return shipping label generation	When the merchant enables return labels, generate a prepaid or pay-on-use return shipping label — and, where offered, a carrier QR code for box-free drop-off — by sending the return's ship-from (customer) and ship-to (merchant) addresses and parcel details to the merchant's configured shipping-label provider, and store the resulting label, tracking number, and drop-off context
Return tracking	Retrieve or receive carrier tracking updates for a generated return label or for tracking-only carrier/number details the merchant enters independently (including for an uploaded external label), to drive customer/merchant status, optional transition notifications, and, where configured, time store-credit release. When a connected Shippo account is available for tracking-only registration, send Shippo only the merchant-entered carrier and tracking number — no customer address or contact details
Inventory restock	When the merchant enables it, adjust Shopify inventory to restock returned items at a merchant-selected location
Return photo storage and display	Store customer-uploaded photos of returned items in object storage and display them to the merchant for return review
Return-label file storage	Where the merchant uploads a return-label file rather than generating one through a connected label provider, store that file in object storage and make it available through signed links (minutes when shown on screen, up to seven days when emailed to the customer)
Abuse detection	Identify unusual return patterns to protect the merchant
Email notifications	Send transactional emails related to return processing (available in the merchant's configured portal languages), and store each message — recipient, subject, headers, rendered body, and delivery state — to retry sends the mail provider does not accept, give the merchant a delivery history for a return, and let the merchant resend the original message
Outbound webhook delivery	When the merchant configures a webhook endpoint, send signed return-event messages to the merchant's chosen destination URL and store each dispatch (destination, message body, delivery state) for retries, the merchant's delivery log, and merchant-initiated redelivery
Audit logging	Record money-touching actions and settings changes in an audit trail for merchant accountability
Usage metering	Count processed returns against the merchant's plan allowance and submit overage charge events to Shopify's billing system (no customer personal data is included in billing submissions)
Analytics	Provide aggregated return metrics to the merchant
AI-assisted policy drafting	When enabled by the merchant, draft suggested return rules and customer-facing copy from merchant-provided return policy text
AI return-reason classification	When enabled by the merchant, categorize customer return reasons (intent, likely root cause, and an abuse-risk signal) to help the merchant understand and triage returns
AI photo review	When enabled by the merchant (plan-dependent, off by default), send a short-lived signed link to a customer's return photo, plus product title, variant title, and return-reason code, to the AI provider to evaluate the visible condition of the returned item; the results are suggestions surfaced for the merchant's review and do not decide any refund
Return fee assessment	Apply merchant-configured return fees and deduct them from the refund or store-credit amount
Approval workflow	Route money-touching actions to a manager for approval based on merchant-configured thresholds, recording the requesting and deciding staff
Shopify Sidekick assistant (optional, merchant-invoked)	When the merchant asks Shopify's built-in Sidekick assistant about returns, return read-only return data (order number, customer email, status, payout type, refund/credit amounts and currency, selected return reason codes — never free-text notes — item counts and return submission dates, and — on abuse-guardrail plans — abuse-flag risk score, reason, and blocked status) so Sidekick can answer; the data returns to the Shopify platform (Shopify's own tool) and no money-touching action is taken. This access is recorded in the protected-customer-data access log, except for aggregate-metrics queries, which return no customer-linked data

2.4 Categories of Data Subjects

Customers of the merchant who look up orders or initiate return requests through the merchant's store
Individuals whose personal data may be incidentally included in merchant-provided return policy text submitted to the optional AI policy assistant (for example, merchant staff or contacts named in the policy). Merchants are instructed not to include personal data in policy text; it is processed only to the extent present.
Individuals incidentally identifiable in customer-uploaded return photos. Customers are asked to photograph the returned item only; any personal data visible in a photo is processed only as part of the image.

2.5 Types of Personal Data Processed

Customer email addresses
Shopify customer IDs
Order numbers and order IDs
Product and variant information from orders
Return reasons and notes provided by customers, including any requested exchange variant(s)
Customer-uploaded photos of returned items (image files and associated metadata such as file type and size), to the extent a photo incidentally contains personal data
The customer's order shipping address — recipient name, street address, city, state/province, postal code, country, and, where present on the order, phone number — processed when the merchant generates a return shipping label, in order to produce the label and (for box-free drop-off) locate nearby drop-off points
Return shipping label details, including carrier tracking numbers and drop-off location context (the customer's postal code and country). For a generated label only these fields are retained — the street address and contact details are not kept, and the shipping provider's response is discarded once the tracking handle is extracted. Where the merchant uploads a return-label file rather than generating one through a connected provider, the label file itself is retained with the return; it shows the customer's ship-to name and address as printed on the label
Tracking-only details entered by the merchant independently of a Return Wise/provider-generated label (including for an uploaded external label): carrier name, tracking number, normalized carrier status, and the time tracking last changed
Requested exchange replacement items and references to the Shopify draft/replacement order created to fulfill an exchange
Fulfillment dates
Customer tags (as stored in Shopify)
IP addresses and related request metadata used for rate limiting, abuse prevention, and operational security
A photo-upload replay-prevention record: a one-way digest of the randomly generated object key of each photo accepted as return evidence, together with the shop domain and the time the record expires. It expires automatically a short, fixed period after the evidence is used (see Section 5.1), and is listed here as pseudonymous personal data rather than treated as anonymous, because a party holding the original object key could recompute its digest
Shopify store credit identifiers, including refund IDs, store credit account IDs, and bonus credit transaction IDs
Shopify refund identifiers and completion timestamps for original-payment refunds
Transactional emails sent about a return, stored as the recipient address, subject, sender and reply-to headers, and rendered message body — which reproduce the customer's email address, order number, and return details — together with the message's delivery state
Merchant staff identifiers recorded in the audit trail, in staff role assignments, in approval records, and in the protected-customer-data access log (email address and, for staff-initiated actions, IP address and browser user-agent string; the access log stores the staff email, an internal record identifier, the action, and a timestamp, and no customer data)
Merchant-provided return policy text submitted to the optional AI policy assistant, to the extent it contains personal data
The store's product types and product tags, sent to the optional AI policy assistant as catalog grounding for the drafted rules. These are catalog metadata rather than customer data; because they are merchant-authored, any personal data a merchant places in them is processed only to the extent present

3. Obligations of the Data Controller

The Data Controller shall:

Ensure there is a lawful basis for processing personal data through the App
Inform data subjects about the processing in accordance with Articles 13 and 14 of the GDPR
Maintain an accurate compliance contact email address in the App settings for privacy and data-rights communications
Respond to data subject requests within the timeframes required by applicable law
Configure appropriate data retention periods in the App settings
Ensure that any instructions given to the Data Processor comply with applicable data protection law
Notify the Data Processor without undue delay if they become aware of any data breach involving data processed by the App

4. Obligations of the Data Processor

The Data Processor shall:

4.1 Processing Instructions

Process personal data only on documented instructions from the Data Controller (as configured in the App settings and as described in the Terms of Service)
Not process personal data for any purpose other than providing the return management service
Inform the Data Controller if, in the Data Processor's opinion, an instruction infringes applicable data protection law

4.2 Confidentiality

Ensure that all personnel authorized to process personal data are bound by obligations of confidentiality

4.3 Security (Article 32 GDPR)

Implement appropriate technical and organizational measures, including:

Encryption of data in transit (HTTPS/TLS)
Cryptographic signing of customer portal session tokens
Rate limiting on customer-facing endpoints
Input validation and output encoding (XSS prevention)
Idempotency and duplicate-detection controls to prevent duplicate processing
Access controls on merchant admin endpoints (Shopify session authentication)
Signed URLs for all reads and writes of stored return photos and label files — short-lived (minutes) for uploads and on-screen viewing, and up to seven days for a label link emailed to the customer; storage buckets are not publicly listable
Encryption at rest of merchant-supplied third-party credentials (such as a connected shipping-label provider API key), which are excluded from data exports and audit records
Region-pinned object storage (EU-jurisdiction bucket for merchants established in the EU/EEA — see Section 6)
Audit logging of money-touching actions and settings changes
Automated data retention and purge mechanisms, including deletion of stored photo and label files alongside their return records

4.4 Sub-processors

Current sub-processors:

Sub-processor	Purpose	Data Processed
Shopify	Platform provider, API services, native store credit refunds, original-payment refunds, bonus credit transactions, and subscription/usage billing	Order data, customer data, store credit and refund transaction data, plan usage and overage charge events (no customer personal data in billing events)
Resend (resend.com)	Transactional email delivery (merchant and customer notifications)	Recipient email addresses, message subject and body content (order numbers, return details, store credit amounts)
Render (render.com)	Application hosting and database storage	All application data
Cloudflare R2 (cloudflare.com)	Object storage for customer-uploaded return photos and for return-label files the merchant uploads (S3-compatible; EU-jurisdiction bucket for EU/EEA merchants)	Return photo image files and storage metadata (file type, size, object key); return-label files uploaded by the merchant, which contain the customer's name and return shipping address as printed on the label
OpenAI (openai.com)	Three optional, merchant-enabled features: (1) AI policy assistant — drafting suggested return rules and customer-facing copy; (2) AI return-reason classifier (plan-dependent) — categorizing return reasons into intent, root cause, and an abuse-risk signal; (3) AI photo review (plan-dependent, off by default) — evaluating the visible condition of items in customer return photos for the return reasons the merchant selects	(1) Policy assistant: merchant-provided return policy text, the store's product types and product tags (catalog metadata retrieved from Shopify, used to ground the drafted rules in the merchant's real catalog — not customer data), and the structured AI draft output; no return, order, customer, customer-tag, abuse-flag, or photo data is sent for this feature. (2) Reason classifier: per returned item, the product and variant title, the selected return reason, and the customer's free-text reason note — automatically redacted to remove email addresses and card-like/long numeric sequences, then truncated. No order numbers, customer names or email addresses, customer tags, order or customer records, abuse flags, or photos are sent for this feature. (3) Photo review: a short-lived (10-minute) signed link to the customer's return photo, which OpenAI's service fetches, plus the product title, variant title, and the return-reason code; no customer name, email address, or free-text reason note is sent. OpenAI's API data is not used to train its models under OpenAI's default API data policy. Calls are sent with OpenAI storage/logging disabled (`store=false`); under OpenAI's standard API data policy OpenAI may retain inputs and outputs for up to 30 days to monitor abuse/misuse and then deletes them (longer only where legally required).
Shipping-label/tracking provider — Shippo (goshippo.com), EasyPost (easypost.com), or ShipStation (shipstation.com), whichever the merchant connects	Optional, merchant-enabled: generate return shipping labels and, where offered, carrier QR codes for box-free drop-off, and retrieve carrier tracking. Shippo may also register a merchant-entered third-party tracking number, including one from an uploaded external label. The merchant connects their own carrier/label account, so the provider also processes this data under the merchant's own agreement with that provider	Label generation: the return's 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, resulting label URL, and carrier tracking number. Tracking-only Shippo registration: carrier name and tracking number only; no customer address/contact information. Neither path sends order history, return reasons, store-credit amounts, abuse flags, or photos

Merchant-configured webhook endpoints are not sub-processors. Where the Data Controller enables outbound webhooks (an optional, plan-dependent feature that is inactive unless the Data Controller configures a destination and a signing secret), the Data Processor sends signed return-event messages to a destination URL the Data Controller chooses. Those messages carry the shop domain, the return request and order identifiers, the order number, the return status, the chosen payout type, 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 Data Processor does not select, control, or contract with the destination — the Data Controller instructs the disclosure and is the controller of any onward processing at that endpoint.

The public marketing website is outside this DPA. The Return Wise marketing and legal pages at returnwise.app are served through Cloudflare's edge delivery, DNS, and DDoS protection, and use a cookieless website-analytics measurement that sets no identifier on the visitor's device. Those services process ordinary request metadata of website visitors (such as IP address, user-agent, and request timing) and never receive the Data Controller's customer return data. They are therefore not sub-processors of the processing governed by this DPA, and are not listed above; they are described in the Privacy Policy, where the Data Processor acts as an independent controller. This role is distinct from Cloudflare R2's role as the App's object-storage sub-processor, which is listed above.

The Data Processor shall:

Maintain the current list of sub-processors in Section 4.4 of this DPA. The Data Processor will give the Data Controller at least 30 days' prior written notice — through the sub-processor list and, where the Data Controller has provided one, the registered compliance-contact email — before a new sub-processor begins processing personal data, so the Data Controller has an opportunity to object. The Data Controller may review the current sub-processor list at any time and may object to a new sub-processor within that notice period by contacting the Data Processor; if the objection cannot be reasonably resolved, the Data Controller may terminate the affected Services without penalty.
Ensure sub-processors are bound by data protection obligations no less protective than those in this DPA
Remain fully liable for the acts and omissions of sub-processors

4.5 Data Subject Requests

Automatically process Shopify's customers/data_request webhooks by compiling the relevant customer data into a snapshot stored inside the authenticated Return Wise admin (the Compliance page) and notifying the merchant-designated compliance contact email; 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 (an accountability record retained per Section 5.1), and snapshots are auto-purged 30 days after the request is received regardless of fulfillment status (supporting the right of access and portability under Articles 15 and 20 of the GDPR while keeping protected data out of email systems and bounding retention)
Automatically process Shopify's customers/redact webhooks by permanently deleting all customer data held in Return Wise's systems, as enumerated in Section 5.3 — supporting the right to erasure under Article 17 of the GDPR. Data previously written to Shopify's own systems during normal return processing — such as order notes and order tags — remains on the Shopify platform and is managed by Shopify, not by Return Wise.
Assist the Data Controller with other data subject rights (rectification, objection, restriction) on a manual basis where the Data Processor holds the relevant data. Most such rights are exercised through the merchant's own workflow; the Data Processor will respond to reasonable written requests for data-level changes within 30 days.

4.6 Data Breach Notification

Notify the Data Controller without undue delay, and no later than 72 hours, after becoming aware of a personal data breach affecting the Data Controller's data
Provide sufficient information to enable the Data Controller to fulfill their breach notification obligations under Articles 33 and 34 of the GDPR
Cooperate with the Data Controller in investigating and remediating the breach

4.7 Data Protection Impact Assessments

Assist the Data Controller with data protection impact assessments (DPIAs) and any prior consultation of a supervisory authority where required under Articles 35 and 36 of the GDPR, taking into account the nature of processing and information available to the Data Processor

5. Data Retention and Deletion

5.1 Retention Period

Personal data is retained according to the Data Controller's configured retention period (default: 12 months, configurable from 1 to 60 months)
Terminal return records (completed, rejected, or failed) older than the configured period are removed by the application's scheduled retention cleanup process, which is ordinarily run daily. The cleanup removes only terminal returns; a pending (non-terminal) return — still awaiting receipt, review, or completion — is retained until it resolves (then ages out on the configured period) or the shop's data is deleted
Certain fraud-prevention records are retained beyond the configured period on the Data Processor's legitimate-interest basis (GDPR Article 6(1)(f)) in preventing return abuse, rather than on the merchant's configured window: a blocked or manually-set abuse flag (which carries the flagged customer's email) is kept until the merchant clears it or the shop's data is deleted, and an unresolved anomaly alert (for example a repeat-returner alert, which can reference a customer's email) is kept until the merchant resolves it or the shop's data is deleted. Both are deleted when that customer's data is erased (Section 5.3) and on shop data deletion
Files stored in object storage follow their return records: customer-uploaded return photos, and any return-label file uploaded by the merchant, are deleted from object storage as part of the same cleanup that removes the return records they belong to. If a storage-side deletion transiently fails, the cleanup of database records still proceeds and the failure is surfaced to the Data Processor's operations alerting. A daily reconciliation sweep removes any stored file — image or label — that no longer has (or never had) an associated return record, covering transient deletion failures and uploads abandoned before their record was created (a photo before the return was submitted, or a label file before it was attached), so stored files do not outlive the data they belong to.
Stored transactional emails (recipient, subject, headers, rendered body, and delivery state) and outbound-webhook delivery records are removed by the scheduled cleanup once they are older than the configured retention period, regardless of delivery outcome — an undelivered message is kept for diagnosis only while it ages inside the window, never past it
Audit trail records are retained for 18 months by default and then removed by the scheduled cleanup
Protected-customer-data access logs — recording which merchant staff member opened a surface exposing protected customer data (the customer's email address and the signed links to their return photos and to any uploaded label bearing their name and address), and when — are retained on the same 18-month default window as the audit trail and are then removed by the scheduled cleanup. Each row holds only the acting staff member's email, an internal reference to the record or surface accessed, the action, and a timestamp — never a customer's name, email address, or postal address. Because these records concern staff activity and hold no customer identifier, they are not located by an individual customer's erasure request; they are deleted on shop data deletion. The Data Processor acts as an independent controller for them (see the Privacy Policy) and relies on its legitimate interests in maintaining an accountability record of access to protected data (GDPR Articles 5(2) and 24)
Rule-evaluation logs record only non-identifying rule-decision facts (the return reason and product attributes evaluated and the resulting rule action — see Section 5.3) and are removed by the scheduled cleanup once older than the merchant's configured retention period
GDPR protected-data access logs — recording which merchant staff member viewed, downloaded, or fulfilled a data-subject export snapshot, or opened the list of data-subject requests, and when — 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 rows for a specific customer's export are additionally deleted when that customer's data is erased. Each row holds only the acting staff member's email, the export request reference (or an internal marker, for list views), the action, and a timestamp — never the export payload or a customer's email. Because these records concern staff activity, the Data Processor acts as an independent controller for them (see the Privacy Policy) and relies on its legitimate interests in maintaining an accountability record of access to protected data (GDPR Articles 5(2) and 24)
AI photo-review assessments (where the Data Controller has enabled the optional AI photo review described in Section 4.4) carry their own retention window, set by the Data Controller: the stored assessment of a photo's visible item condition is retained for the shop's configured AI photo-evaluation retention period (default: 180 days, configurable from 1 to 365 days) and is then removed by the scheduled cleanup, independently of the return record it describes. The underlying return photo itself is not governed by this setting — it follows its return record under the configured retention period above — and both are deleted on erasure of that customer's data and on shop data deletion
AI policy-assistant drafts: a draft the Data Controller applies is retained alongside the shop's settings and audit history; a draft that is never acted on is removed by the scheduled cleanup 30 days after its creation, and a draft the Data Controller discards is removed 30 days after it is discarded. All drafts are deleted on shop data deletion. Drafts hold merchant-provided policy text and catalog metadata rather than customer personal data (Section 4.4)
The photo-upload replay-prevention record described in Section 2.5 carries its own expiry rather than the merchant's configured retention period, because it guards a piece of evidence that itself expires: photo evidence submitted to Return Wise can only be used to obtain a refund for 24 hours from the point it is attached to a return request, after which it is rejected and must be attached again. The record is retained for that 24-hour period plus a 48-hour safety margin, and is then deleted by the scheduled cleanup, which is ordinarily run daily — so the record is deleted within approximately four days of the evidence being used, and always sooner than the configured retention period. The Data Processor relies on its legitimate interests in strictly necessary fraud prevention and service security (GDPR Article 6(1)(f), read with Recitals 47 and 49): the record exists solely to stop evidence that was already consumed for one refund from being replayed for another, it is the minimum data capable of achieving that (a one-way digest, with no photo, raw object key, timestamp of use, or customer, order, or return identifier), it is retained only for the period the evidence remains usable plus the short, fixed safety margin described above, and it cannot be used to contact, profile, track, or make any decision about a data subject

5.2 Deletion or Return on Termination

In accordance with Article 28(3)(g) of the GDPR, the Data Controller may choose either deletion or return of personal data at the end of the provision of services. At any time during the term of the service or before uninstalling the App, the Data Controller may self-serve a data export from the authenticated Return Wise admin (Settings → Compliance → "Export all shop data"; this export is available to the store owner), which produces a structured, commonly used, and machine-readable JSON archive of the personal data processed on behalf of the Data Controller. Because the archive is JSON, uploaded return-photo and shipping-label files are referenced by their metadata (and remain individually downloadable from each return's detail page until deletion) rather than embedded as binaries, and the rendered bodies of stored transactional emails are represented by their metadata (recipient, subject, and delivery state). The archive includes the carrier tracking-registration and notification-decision records and the protected-customer-data access log, alongside the other collections listed in the deletion list below (excluding only the authentication session data, which is the Data Processor's own controller-side record of the merchant account rather than data processed on the Data Controller's behalf). An individual customer's data-subject export handled under Section 4.5 likewise includes that customer's carrier tracking records. If the Data Controller is unable to access the admin, the Data Processor will, on written request to support@returnwise.app, use commercially reasonable efforts to provide an equivalent export by an alternative secure channel within 30 days. In the absence of a return request before the deletion timelines below take effect, the Data Processor will delete the personal data as the default. The Data Processor shall delete existing copies of personal data after deletion or return is complete, unless retention is required by applicable law.

Upon termination of the service (app uninstallation):

On Shopify's app/uninstalled webhook, Return Wise marks the shop for cleanup and preserves its configuration during a short reinstall grace period (approximately 48 hours, aligned with Shopify's compliance schedule). A merchant who reinstalls within that window keeps their settings. After the grace period elapses, Return Wise's scheduled cleanup process permanently deletes all personal data held in Return Wise's systems for the shop.
On Shopify's shop/redact webhook, Return Wise deletes all personal data held in its systems for the shop immediately, without waiting for the grace period.
Data deleted by either path includes: return requests (including tracking-only carrier, number, status, and timestamps), return items, uploaded return photos (database records and the stored image files in object storage), return shipping labels (including tracking numbers, drop-off address context, and — where the label file is hosted by Return Wise rather than by the merchant's label provider — the stored label file in object storage), carrier tracking-registration records (including superseded tracking numbers and any provider error text retained for diagnosis), carrier-transition notification decision records (including the frozen recipient email address), exchange basket selections, AI photo-evaluation records, rule evaluation logs, configured return rules and return fee rules, abuse flags, operational alert records, product defect-insight aggregates, staff roles and pending approval records, partner attribution records, review-prompt records, audit trail records, stored transactional emails (including their rendered message bodies), outbound-webhook delivery records, AI policy-assistant drafts, plan usage and overage charge records, portal and email copy overrides, GDPR export snapshots, GDPR access audit logs, protected-customer-data access logs, photo-upload replay-prevention digests, shop settings, and authentication session data
Deletion from Return Wise is permanent and irreversible
Data previously written to Shopify's own systems by the App — including store credit refunds, bonus store credit transactions, customer records, order notes, and order tags applied during return processing — remains on the Shopify platform as Shopify-owned resources, governed by Shopify's own policies and not by Return Wise

5.3 Customer-Level Deletion

Upon receiving Shopify's customers/redact webhook:

All return requests (including tracking-only carrier, number, status, and timestamps), return items, uploaded return photos (database records and the stored image files in object storage), return shipping labels (database records and, where the label file is hosted by Return Wise, the stored label file in object storage), carrier tracking-registration records (including superseded tracking numbers and any provider error text retained for diagnosis), carrier-transition notification decision records (including the frozen recipient email address), exchange basket selections, and AI photo-evaluation records (all deleted together with the customer's return records), abuse flags, operational alert records that reference the customer, pending approval records tied to the customer's returns or abuse flags, audit entries tied to the customer's returns, outbound-webhook delivery records for the customer's returns, and any GDPR export snapshots and associated access audit log rows for the specified customer email are permanently deleted from Return Wise's systems
Stored transactional emails are deleted on three matches, so that no copy of the message survives the erasure: emails addressed to the customer, emails linked to the customer's return records, and emails sent to the merchant whose stored subject or rendered body contains the customer's email address (for example an abuse alert or a daily digest that is not tied to a single return)
To prevent reuse of previously consumed photo-upload evidence, Return Wise keeps a minimal shop-scoped replay-prevention record consisting of a one-way digest of the random object key and the time that record expires. It contains no photo, raw object key, customer identifier, email address, order identifier, return identifier, or return content, and is used only to reject reuse of already-consumed evidence. Because it holds no customer identifier, it is not located by an erasure request; it instead expires on its own within approximately four days of the evidence being used (Section 5.1). In the ordinary case it is therefore already deleted by the time Shopify delivers customers/redact (sent no earlier than ten days after the request is made); where return evidence was used in the days immediately preceding the webhook, the record can briefly survive the erasure and then expires on its own fixed schedule. It is also deleted when the shop's data is deleted in full (Section 5.2). Return Wise relies on its legitimate interests in strictly necessary fraud prevention and service security for this record, as set out in Section 5.1, and treats it as pseudonymous personal data rather than anonymous data, because a party holding the original object key could recompute its digest
Rule-evaluation logs are not part of the per-customer deletion above because they hold no customer identifier. Each row records only the non-identifying rule-decision facts of an evaluation — the rule evaluated and its conditions, whether it matched, the resulting rule action, and the return reason and product attributes assessed — and stores no customer email, customer or order identifier, return identifier, customer tags, or return-history profile. Like the replay-prevention record, they cannot be located by an erasure request; instead they are retained no longer than the merchant's configured retention period, aged out on their own timestamp by the scheduled cleanup (Section 5.1), and deleted in full when the shop's data is deleted (Section 5.2)
Anonymization is not used as a substitute for deletion: where a record is linked to the customer, that record and its content are permanently removed rather than stripped and retained. A small number of records hold no customer, order, or return identifier at all — the replay-prevention digests and rule-evaluation logs described above are the present examples — and so cannot be located by an individual erasure request; those age out on the retention schedules in Section 5.1 instead. The Data Processor does not create such a record where a customer-linked one would serve
Data previously written to Shopify's own systems by the App (such as order notes and order tags) remains on the Shopify platform and is managed by Shopify; Return Wise has no ability to retroactively remove it

6. International Transfers

The application and database are hosted on Render (render.com) with servers located in the United States. Personal data from Data Subjects in the European Economic Area (EEA), the United Kingdom, or Switzerland will be transferred to and processed in the United States.

Geographic availability. The App is not currently offered to Data Controllers established in the EEA, the United Kingdom, or Switzerland (Terms of Service, Section 3 — a limitation the App enforces technically at the store level). The mechanisms in this Section 6 accordingly govern (a) any processing of personal data of Data Subjects located in those jurisdictions carried out on behalf of a Data Controller established elsewhere, and (b) transfers from Data Controllers established in those jurisdictions if and when the App becomes available to them.

EU data residency for stored files: Customer-uploaded return photos, and any return-label file uploaded by the merchant, for Data Controllers established in the EU/EEA are stored in an EU-jurisdiction object storage bucket (Cloudflare R2) rather than the default United States bucket. All other application data is processed in the United States under the transfer mechanisms below. Because the App is not currently offered to Data Controllers established in the EEA (Section 6, Geographic availability), this residency path is not in use today: a served Data Controller's stored files are held in the United States regardless of where that Data Controller's own customer is located.

6.1 EU Standard Contractual Clauses (Controller-to-Processor Transfers)

For transfers of personal data from the EEA to a third country that lacks an adequacy decision under Article 45 of the GDPR, the parties incorporate by reference the Standard Contractual Clauses (Module Two — Controller to Processor) adopted by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021 (the "EU SCCs"). The Data Controller is the data exporter and the Data Processor (BrightLayer Lab LLC) is the data importer. The optional and modular elements of the EU SCCs are completed as follows:

Clause 7 (Docking clause): not used
Clause 9(a) (Sub-processors): Option 2 — general written authorization. The current sub-processor list and the change-notification process are set out in Section 4.4 of this DPA
Clause 11(a) (Independent dispute resolution): not selected
Clause 17 (Governing law): Option 1 — the law of the EU Member State in which the Data Controller is established, provided that Member State law allows for third-party beneficiary rights; otherwise, the law of Ireland
Clause 18 (Choice of forum and jurisdiction): the courts of the EU Member State whose law governs under Clause 17
Annex I.A (Parties): as identified in this DPA and in the Terms of Service
Annex I.B (Description of transfer): the categories of data subjects, categories of personal data, nature and purpose of processing, retention period, and sub-processors are as set out in Sections 2.3, 2.4, 2.5, 4.4, 5.1, and 5.2 of this DPA. The frequency of the transfer is continuous / on an ongoing basis for the duration of the Services, and its duration is as set out in Section 2.2
Annex I.C (Competent supervisory authority): the supervisory authority of the EU Member State of the Data Controller's establishment or, where the Data Controller has no EU establishment, the supervisory authority of the EU Member State in which the Data Controller's representative under Article 27 of the GDPR is designated
Annex II (Technical and organizational measures): as set out in Section 4.3 of this DPA
Annex III (List of sub-processors): as set out in Section 4.4 of this DPA

6.2 UK International Data Transfer Addendum

For transfers of personal data from the United Kingdom, the parties incorporate by reference the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, version B1.0, issued by the UK Information Commissioner's Office under section 119A of the UK Data Protection Act 2018 (the "UK Addendum"), read together with the EU SCCs in Section 6.1. Tables 1, 2, and 3 of the UK Addendum are completed by reference to the EU SCCs and the corresponding sections and annexes of this DPA. In Table 4, neither party objects to changes to the Approved Addendum issued by the ICO from time to time.

6.3 Swiss Transfers

For transfers of personal data subject to the Swiss Federal Act on Data Protection (FADP), the EU SCCs in Section 6.1 apply with the following adaptations: references to the "GDPR" are read as references to the FADP where the FADP applies; the supervisory authority is the Swiss Federal Data Protection and Information Commissioner; and Swiss law governs transfers concerning Swiss-only data subjects.

6.4 Sub-processor Onward Transfers

Where the Data Processor's sub-processors transfer personal data outside the EEA, the United Kingdom, or Switzerland, those onward transfers are governed by the Standard Contractual Clauses, UK Addendum, and Data Processing Addenda published by each sub-processor listed in Section 4.4.

6.5 Adequacy

Where an adequacy decision under Article 45 of the GDPR or an equivalent UK or Swiss adequacy mechanism covers the destination country, the parties may rely on that adequacy decision in lieu of the SCCs and the UK Addendum.

7. Audit and Compliance Information

On reasonable written notice, and no more than once per calendar year (except where required by a supervisory authority or following a confirmed security incident affecting the Data Controller's data), the Data Controller may request:

Written responses to a reasonable data-protection and security questionnaire
Publicly available security and compliance documentation from the Data Processor's sub-processors (as listed in Section 4.4) that demonstrate relevant certifications or controls
Documentation describing the Data Processor's technical and organizational measures as set out in Section 4.3
Where the questionnaire and documentation above are not sufficient to satisfy an audit obligation the Data Controller demonstrably has under Article 28(3)(h) of the GDPR, an audit or inspection conducted by an independent third-party auditor mandated by the Data Controller — bound by written confidentiality obligations, at the Data Controller's expense, on at least 30 days' prior written notice, during normal business hours, in a manner that does not disrupt the Data Processor's operations or compromise the confidentiality of other customers' data, and no more than once per calendar year (except where a supervisory authority requires otherwise or following a confirmed security incident affecting the Data Controller's data)

The Data Controller acknowledges that, as a small software operator, the Data Processor's ordinary means of demonstrating compliance are the questionnaire responses and the sub-processor and technical-and-organizational-measures documentation described above, and that the Data Processor does not maintain the infrastructure to provide direct, unsupervised access to production systems or personnel; any independent audit will be limited as set out above. Where an audit or inspection is compelled by a supervisory authority or required by applicable law, the Data Processor will cooperate in good faith with the Data Controller and the authority to respond to the specific request.

8. Liability

Each party's liability under this DPA is subject to the limitations set forth in the Terms of Service, except where applicable data protection law does not permit such limitations.

9. Governing Law

This DPA is governed by the same law that governs the Terms of Service between the parties, except for Section 6 (International Transfers), where the EU SCCs and the UK Addendum carry their own governing law and choice of forum as set out in Sections 6.1 and 6.2.

10. Contact

Data Processor contact for data protection matters:

Company: BrightLayer Lab LLC
Email: support@returnwise.app
Website: https://www.returnwise.app/

The Data Processor's registered legal address is published in the Return Wise Privacy Policy.

By installing and using Return Wise, the Data Controller accepts this Data Processing Agreement as part of the Terms of Service.