Privacy Policy

Kumi Commerce — Kumi Bundle Builder for Shopify

Effective date: 2026-10-12
Last updated: 2026-10-19

1. Who we are

Kumi Commerce ("we", "us") is a sole proprietorship based in Tokyo, Japan. We build and operate apps for the Shopify App Store. This policy covers the app Kumi Bundle Builder and the website kumicommerce.com.

Operator	Kumi Commerce (sole proprietorship)
Location	Tokyo, Japan
Website	https://kumicommerce.com
Contact for privacy and data protection	support@kumicommerce.com

There is one person with administrative access to our systems: the owner of Kumi Commerce.

2. Definitions

We use these words throughout this policy and in our Terms of Service.

Term	What we mean by it
App	The Shopify app "Kumi Bundle Builder", including its admin interface, its theme app block, its Cart Transform function and the backend that serves them.
Merchant	The business that installs the App on its Shopify store. If you are reading this because you run a store, you are the Merchant.
Store	The Shopify store on which the App is installed, identified by its `*.myshopify.com` domain.
Customer	A person who shops on a Merchant's Store. Customers do not have accounts with us and do not interact with us directly.
Personal data	Any information relating to an identified or identifiable natural person. Shopify treats order information — including order totals and order identifiers — as customer personal data, and so do we, even when it carries no name or email address.
Controller	The party that decides why and how personal data is processed.
Processor	A party that processes personal data on a Controller's behalf and on its instructions. Under the CCPA the comparable term is "service provider".
Sub-processor	A third party we engage to process personal data for us as part of running the App.
Protected customer data	Shopify's term for customer and order data that an app may only access after Shopify approves the app's request.
Processing	Anything done with personal data: receiving, reading, storing, using, transmitting, deleting.

3. Our role, and yours

For personal data that reaches us because the App is installed on a Store — orders, store configuration, bundle definitions — the Merchant is the Controller and we are the Processor. We process that data only to provide the App to that Merchant and to bill the Merchant correctly. We do not decide to use it for anything else, we do not sell it, and we do not use it to build profiles, advertise, or train machine-learning models.

The contractual terms that govern this relationship are in Part B (Data Processing Agreement) of our Terms of Service. Installing the App accepts them.

For a small amount of data we are the Controller ourselves: the record that a Store installed or uninstalled the App, which plan it is on, and our billing records. We need these to run our business, to invoice correctly, and to know whether the App is working.

The Merchant remains responsible for its own privacy notice to its own Customers, for having a lawful basis to process its Customers' data, and for the instructions it gives us.

4. What personal data we process, and why

This is the complete list. Nothing is processed that is not described here.

4.1 Store and account data (we are Controller)

Data	Why	Source
Store `myshopify.com` domain	Identifies the Store. It is the key every other record hangs on.	Shopify, at install
Shopify API access token, token scope and expiry, refresh token	Lets the App call the Shopify Admin API for that Store.	Shopify OAuth
Install timestamp, uninstall timestamp	To know whether the App is active, and to measure how many Merchants keep it.	Our own records
Plan key, trial end date, onboarding completion timestamp	To apply the right plan and show the right onboarding.	Our own records
Billing events: event type, plan, amount, currency, Shopify subscription identifier, timestamp	To reconcile charges and to measure revenue and cancellations.	Shopify billing webhooks
Usage counters: a metric name, a month, a count	To enforce monthly limits on features that cost us money per use.	Our own records

Our session table also contains columns for a staff user's ID, first name, last name and email address, because the Shopify session-storage library we use defines them. The App uses offline access tokens only, so these columns are never populated. We mention them because they exist in the schema, not because they hold data.

4.2 Merchant catalog and configuration data (we are Processor)

Data	Why
Product IDs, variant IDs, product titles, product image URLs	To let the Merchant pick which products belong in a bundle, and to show them in the admin and in the storefront block.
Bundle configuration: bundle key, title, parent product and variant, required quantity, allowed products, discount type and value, enabled flag, display order	This is the Merchant's own configuration. It is what the App exists to store.
Whether a component product has become unavailable, and when we last checked	So a bundle does not offer a product a Customer cannot actually buy.

This is business data about products. It is not personal data, but it is the Merchant's data and we treat it with the same care.

4.3 Order data (we are Processor — this is protected customer data)

The App subscribes to Shopify's orders/create, orders/updated, orders/cancelled and refunds/create webhooks using the read_orders scope. We use them for exactly one purpose: to measure how much revenue the Merchant earned through bundles built with the App, and to reduce that figure when an order is refunded, edited or cancelled, because our pricing tiers are based on it.

Shopify delivers the full order payload to our endpoint. From that payload we read only:

Read from each order	Why
Order identifier (`admin_graphql_api_id`, or the numeric `id`)	To avoid counting the same order twice. Shopify retries a webhook up to 8 times over 48 hours.
Order timestamp (`processed_at`, falling back to `created_at`)	To decide which monthly period the order belongs to.
Order currency code	To get the decimal places right and to convert to USD later.
For each line item: line item ID, variant ID, quantity, unit price (and `price_set.shop_money`), discount allocations (and `total_discount` / `total_discount_set`)	To work out the discounted value of the bundle lines only, and not the rest of the cart. The line item ID lets us match a later refund to the same line without reading the order again.
For a refund: the refunded line item IDs and their refunded subtotals	To subtract a refund from the revenue we previously recorded.

In addition, for each order that matches a bundle we make one Admin GraphQL request, which reads only order.lineItems[].id and order.lineItems[].lineItemGroup.variantId. Shopify records a bundle's components as separate order lines, and this is how we learn which lines belong to a bundle the App created. The request returns no customer fields.

We then store only:

Stored per attributed order	Note
Order identifier
Amount, in the Store's currency, in minor units	Only the portion attributed to the App, not the order total
Currency code
USD-converted amount	May be empty until a daily job converts it
Attribution reason	An internal label, e.g. `bundle`
Order timestamp, and the time we recorded it
The Shopify line item IDs and bundle variant IDs the revenue was attributed to	So that a later refund or order edit can be matched to the same lines without reading the order again. These are Shopify object identifiers, not customer data.

We do not read, request, store or transmit a Customer's name, email address, phone number, shipping address, billing address, IP address, or payment details. We have not requested access to any of Shopify's protected customer fields. The order payload Shopify sends us does contain some of those fields; we parse the fields listed above, and the rest of the payload is discarded with the request and never written to storage.

We are nevertheless explicit that this is personal data: an order identifier and an order amount can be linked back to a person by the Merchant and by Shopify. We do not claim to hold "no personal data".

An order is only recorded if at least one of its line items belongs to a bundle the Merchant configured in the App. Orders unrelated to the App are read, found not to match, and not stored.

4.4 Operational records (we are Processor)

Data	Why
Webhook receipts: Shopify's webhook ID, the topic, when we received it, when we finished it, and an error summary if it failed	Shopify retries webhooks. Without this we would count the same order several times, or silently lose one.
Server logs containing the Store domain, the webhook topic, order identifiers and attributed amounts	To diagnose failures. These are the same values described above; no Customer identifiers are logged.

4.5 Privacy request records (we are Processor)

When Shopify sends us a customers/data_request, customers/redact or shop/redact webhook, we keep a record so that we can show what we received and what we did.

Shopify's payloads for these requests contain the Customer's email address and phone number. We strip them before writing anything down. What we keep is:

the request topic and the Store domain,
the Shopify shop ID,
the Shopify customer ID (a numeric identifier — we keep it so the request can be matched to a later question about it),
the data-request ID, where Shopify provides one,
the *number* of orders named in the request, not the orders themselves,
when we received the request and when we completed it.

The email address and phone number are not stored, not logged and not forwarded.

5. What we never do

We do not sell personal data, and we do not share it for cross-context behavioural advertising. We have never done so.
We do not use Merchant or Customer data to train machine-learning models.
We do not combine data from one Store with data from another, except as anonymous counts (for example, how many Stores have the App installed).
We do not place cookies or trackers in a Merchant's storefront. The App's storefront block reads bundle configuration that Shopify renders into the page; it does not call our servers and does not identify the visitor.
We do not contact a Merchant's Customers.

6. How the App is embedded in the storefront

The App's storefront block is a Shopify theme app block. The bundle information it shows (which products may be selected, how many are required, what the discount is) is published by us into a Shopify app-data metafield, and Shopify renders it into the page. The block makes no request to our servers, so visiting a Merchant's product page sends us nothing: no IP address, no page view, no identifier.

Discounts are calculated by a Shopify Cart Transform function, which runs inside Shopify's infrastructure as a pure function. It has no network access and cannot send anything to us.

7. Legal bases

Where we act as Processor, the Merchant is responsible for having a legal basis; we process on the Merchant's instructions, which are given through the App's settings and through our Terms of Service.

Where we act as Controller (section 4.1), our legal bases under the GDPR are:

Performance of a contract — providing the App to the Merchant and billing for it.
Legitimate interests — keeping the service running, preventing abuse, and keeping the records we need to reconcile charges. We have balanced this against the limited and business-facing nature of the data.
Legal obligation — keeping the records we must keep for tax and accounting in Japan.

8. Third parties who may process data for us

Third party	What it does	What it receives
Shopify Inc. (Canada / USA)	The platform the App runs on. The source of all order and store data.	Shopify is the source, not a recipient. The Merchant's relationship with Shopify is governed by Shopify's own terms and privacy policy.
Frankfurter (`api.frankfurter.app`), publishing European Central Bank reference rates	Supplies the exchange rate used to convert an order amount to USD for tier calculation.	A three-letter currency code and a date. Nothing else. No Store domain, no order identifier, no amount, no personal data of any kind. We call it from a daily background job, never from a webhook.
Render Services, Inc. (United States; our backend and database run in Render's Frankfurt, Germany region)	Runs the App's backend and stores everything in section 4.	All data described in section 4.

Our backend and our managed PostgreSQL database both run on Render (Render Services, Inc.) in Render's Frankfurt, Germany region. Render encrypts database storage at rest with AES-256 and encrypts connections to it in transit. We use no other provider to run the App's backend or to store Merchant or Customer data.

Services we are not using

Our codebase contains two optional integrations that are switched off and not in use:

an AI-assisted drafting feature for support replies, which would send a Merchant's support message to Anthropic's Claude API, and
error monitoring, which would send error reports to Sentry.

Neither is reachable in the App: no part of the App calls them, and the credentials they require are not configured. No Merchant or Customer data has been sent to Anthropic or to Sentry. If we turn either of them on, we will update this policy first — stating exactly what is sent, with the sub-processor named — and not after.

9. International transfers

We operate from Japan. The data described in section 4 is processed by us in Japan and by our hosting provider, Render, in Frankfurt, Germany.

From the EEA, the UK and Switzerland to Japan: the European Commission has recognised Japan as providing an adequate level of data protection (adequacy decision of 23 January 2019, extended in 2023). Transfers to us in Japan rely on that decision. The UK has made an equivalent finding.
To our hosting provider: our hosting region is Frankfurt, Germany, which is inside the EEA. Merchant data is therefore not transferred outside the EEA by our choice of hosting region. If we ever move to a region outside Japan and the EEA, we will put the European Commission's Standard Contractual Clauses (and the UK International Data Transfer Addendum, where applicable) in place with that provider before any Merchant data is processed there, and we will record it in section 8.
To Frankfurter: only a currency code and a date are sent, so no personal data is transferred.

The contractual commitments covering these transfers are in Part B of our Terms of Service.

10. Security

What we actually do:

All traffic between Shopify, a Merchant's browser and our backend uses TLS. Our platform refuses to start unless the app URL is https://.
Every webhook is verified against Shopify's HMAC signature before we look at its contents. Unsigned or wrongly signed requests are rejected.
Our production database encrypts data at rest, and access to it is limited to the App's backend and to the single administrator of Kumi Commerce.
Shopify API access tokens are stored only in our session table and are never written to logs. Where we forward diagnostics, token-shaped strings are removed first.
Every admin action that changes a bundle checks that the bundle belongs to the Store making the request, so one Store cannot read or modify another Store's configuration.
Email addresses and phone numbers arriving in privacy-request webhooks are removed before anything is written down (section 4.5).

We do not claim that our security is perfect or that a breach is impossible. No single measure described above is a guarantee. If a breach affects a Merchant's data, we will notify that Merchant without undue delay and, in any event, within 48 hours of becoming aware of it, with what we know at the time.

11. Retention and deletion

Event	What happens
Merchant uninstalls the App (`app/uninstalled`)	We immediately delete the Store's sessions, including the Shopify access token. We keep the Store's bundle configuration so that a reinstall does not lose the Merchant's work, and we record the uninstall.
48 hours after uninstall (`shop/redact`, sent by Shopify)	We delete everything for that Store: bundle definitions and their components, attributed orders, monthly revenue totals, billing events, usage counters, privacy-request records, the Store record itself, and any remaining sessions.
Customer deletion request (`customers/redact`)	We hold no Customer personal data beyond what is described in section 4.3, so there is nothing about a named Customer to erase. We record that the request arrived and was handled. We cannot delete individual order totals on request, because they are the basis of the Merchant's own billing; they are deleted with everything else at `shop/redact`.
Customer data request (`customers/data_request`)	We respond to the Merchant. Because we hold no Customer name, email, phone or address, there is nothing to disclose about an individual beyond the fact that the App holds no data about them.

Two things survive a shop/redact, and we would rather say so than be imprecise:

Webhook receipts. The row that records "webhook X on topic Y was received at time Z, and succeeded or failed" remains, but its link to the Store is removed. It holds no Store domain, no order data and no Customer data. We keep it so that a late retry of an already-processed webhook is not processed again.
Server logs and accounting records. Logs are held by our hosting provider for its retention period; we will state that period here once the provider is final. Invoices and accounting records are kept for as long as Japanese tax law requires. These relate to the Merchant's business, not to its Customers.

A Merchant can ask us to delete its data sooner by emailing support@kumicommerce.com.

12. Rights

If you are a Merchant: you may ask us for a copy of the data we hold about your Store, ask us to correct it, ask us to delete it, or object to our processing of it. Email support@kumicommerce.com. We will answer within 30 days. We may ask you to prove you control the Store.

If you are a Customer of a store that uses this App: the Merchant is the Controller of your data, so please contact the store you bought from. Shopify's and the Merchant's processes handle your request; the Merchant can instruct us as part of it, and Shopify's customers/redact and customers/data_request webhooks reach us automatically. We will act on them as described in section 11.

Under the GDPR you have the rights of access, rectification, erasure, restriction, portability and objection, and the right to complain to your supervisory authority. Under the CCPA/CPRA, California residents have the rights to know, delete, correct and opt out of sale or sharing; we do not sell or share personal data, so there is nothing to opt out of, and we do not discriminate against anyone who exercises a right.

We have not appointed an EU or UK representative under Article 27 GDPR. We are a sole proprietorship whose processing of EEA personal data is occasional and limited to the categories in section 4; if that changes, we will appoint one and name them here.

13. Children

The App is a business tool for store operators. We do not knowingly process data about children, and we do not collect data directly from any individual.

14. Changes to this policy

If we change what we process, why we process it, or who processes it for us, we will update this page and change the "Last updated" date. For changes that materially affect Merchants — in particular, adding a sub-processor — we will notify installed Merchants by email at the address Shopify provides for the Store, at least 30 days before the change takes effect, so that a Merchant who objects can uninstall before it does.

15. Contact

Questions about this policy, or any request about your data:

support@kumicommerce.com

Kumi Commerce, Tokyo, Japan — https://kumicommerce.com