Merchant and staff data includes the canonical Shopify shop domain, Shopify session identifiers and granted scopes, billing plan and trial state, app configuration and automation rules, and Shopify’s associated-user session details when supplied. Those associated-user details can include a staff identifier, name, email, locale, and account-owner or collaborator status.

Customer and order data read from Shopify can include customer identifiers and display names; shipping addresses; order identifiers, names, dates, tags, sales channel, currency, status, totals, and shipping charges; line-item titles, variants, quantities, prices, discounts, and custom attributes; fulfillment orders and assigned locations; inventory item identifiers and levels; and payment transaction details needed to issue a shipping refund. This data is used on demand to find and validate merge candidates and to perform an approved or automated merge.

Cloudflare D1 stores shop domains, Shopify order identifiers and their primary or secondary roles, merge job status and history, whether a merge note was provided (stored as the sentinel provided, not the note’s content), refund amounts and identifiers, billing snapshots, first-trial history, automation rules, and webhook-delivery receipts. B2B approval records additionally store the Shopify company ID and name, company-location ID and name when shared by every order, order display names, the requesting and deciding staff identifiers/display names, and optional request and decision notes. It does not currently record a merge-job channel value or copy customer emails or shipping addresses into the merge tables. Cloudflare R2 audit records and privacy exports can contain shop, customer, order, job, approval, company, and refund identifiers, approval-note content, and sanitized operational metadata.

read_orders supports order discovery, compatibility checks, line-item and payment reads, and merge history. write_orders supports cancelling secondary orders, issuing shipping refunds, and writing merge-linkage metafields. read_order_edits and write_order_edits support staging, validating, committing, and reconciling edits to the primary order. read_customers supports reading each order’s linked customer so orders can be grouped into merge candidates by customer. read_companies supports verifying that every order in a B2B approval belongs to the same Shopify company. read_products supports resolving the underlying product variant for each order line item during merge eligibility checks.

read_locations supports reading fulfillment-order and inventory location names used in the merge and inventory-validation paths. read_inventory supports exact on-hand inventory validation by location. write_inventory is declared for inventory-adjustment support; the current merge path validates inventory and relies on Shopify’s order-edit and cancellation inventory effects rather than directly adjusting inventory quantities.

read_fulfillments and write_fulfillments are declared for the fulfillment-aware merge workflow. The current workflow reads fulfillment state and reacts to fulfillment creation but does not create fulfillments. The more specific read_assigned_fulfillment_orders, read_merchant_managed_fulfillment_orders, and read_third_party_fulfillment_orders allow the app to inspect fulfillment orders across their assigned responsibility types before a merge.

read_shipping supports reading secondary-order shipping charges for the plan-gated shipping refund. write_app_proxy supports the signed Pro customer self-service merge portal. read_metaobjects, write_metaobjects, read_metaobject_definitions, and write_metaobject_definitions are declared for the app-owned automated-merge rule definition and rule projections in Shopify. The current code creates the definition and upserts rule projections; current rule reads come from D1.

The app runs on Cloudflare Workers. Application records are stored in Cloudflare D1 (SQLite), Shopify sessions in Cloudflare KV, immutable job audit objects and privacy exports in Cloudflare R2, and job state in Cloudflare Durable Objects for in-progress, completed, and failed merge jobs, plus retry messages in Cloudflare Queues. Queue messages carry the full Shopify webhook payload, order identifiers, and merge-note content when provided; they are retried up to 3 times and a message that exhausts retries moves to a dead-letter queue rather than being discarded. The Durable Object context includes shop and order identifiers, merge-note content when provided, and an encrypted Shopify access token. Completing or failing a job deletes its alarm but leaves that context stored until an applicable customers/redact or shop/redact request clears the Durable Object. Shopify remains the source of truth for customer and order records. New Shopify access-token and refresh-token writes are encrypted with AES-GCM before storage in KV, and access tokens in Durable Object contexts are also encrypted with AES-GCM. Audit metadata removes values under sensitive token, secret, credential, and password keys. Cloudflare KV also holds short-lived rate-limit counters for the customer-facing merge portal, keyed by shop domain and client IP address, which expire automatically within 2 minutes.

Records are retained while needed to provide, secure, audit, and reconcile the service and to meet legal obligations. On app/uninstalled, the implemented handler deletes the shop’s KV and D1 sessions, current subscription snapshot, development plan override, and automation rules, and marks unfinished merge jobs failed. Completed and failed merge records, audit objects, webhook receipts, and the one-time paid-trial history are retained until Shopify later sends shop/redact.

Shopify provides the commerce platform, merchant and staff authentication, order, inventory and fulfillment APIs, webhooks, app proxy, app-owned metafields and metaobjects, and subscription billing.

Cloudflare provides Workers hosting, D1 database storage, KV session storage, R2 object storage, Durable Objects, and Queues. Sentry processes error diagnostics, PostHog processes product-analytics events, and Datadog processes configured browser and performance-monitoring data. Operational events can include a shop identifier when available, app and release identifiers, error details, and technical request or browser context.

The app authenticates and synchronously handles Shopify’s three mandatory privacy webhooks. For customers/data_request, it looks up merge jobs using the order identifiers supplied by Shopify and writes a machine-readable R2 export containing the requested customer and order identifiers plus the matching merge and B2B approval records, including stored request and decision notes. The handler does not email the export.

For customers/redact, the app uses Shopify’s supplied order identifiers to clear each matching job’s Durable Object, delete its R2 audit objects and matching privacy exports, and delete the D1 merge job with its order and event rows. For shop/redact, it clears every remaining job Durable Object and R2 job log, deletes all shop privacy exports and KV sessions, and deletes the shop’s D1 merge, session, subscription, trial-history, development-override, automation-rule, and webhook-receipt records. It keeps one record holding the redacted shop domain and redaction timing so that requests already queued or running cannot recreate shop data after the erasure completes.

A customer seeking access, correction, or deletion should contact the Shopify merchant from whom they placed the orders so the merchant can initiate the appropriate Shopify privacy process. Merchants can contact Pcnaid Inc. for help with a request.