Software companies
E-commerce software vendors: merchant data vs your own records
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
On an ecommerce platform, merchant data ownership usually sits with the merchant: orders, catalogs and customer lists belong to the stores that created them, and shopper details carry privacy duties on top. What an ecommerce software vendor can usually license is its own record: support tickets, engineering history, integration fixes and implementation notes, with merchant and shopper details removed.
Key takeaways
- Merchant orders, catalogs and customer lists are usually customer data under your terms, not vendor property.
- Shopper names, addresses, emails and payment details add privacy obligations even where a contract grants broad usage rights.
- Your support tickets, code reviews, incident records and integration fixes are the strongest licensable candidates.
- A usage data clause that lets you improve your service rarely reaches licensing merchant-derived records to a third party.
- Host platform partner and API terms can restrict what an app vendor does with data pulled through the platform.
Who owns merchant data on an ecommerce platform?#
Merchant data on an ecommerce platform usually belongs to the merchant, because most commerce SaaS terms define orders, catalogs and customer lists as customer data that the merchant submits and controls. The vendor receives a license to host and process that data so the service works, not ownership of it.
That answer holds whether you run a full storefront platform, a subscription-billing app, a returns tool, a shipping integration or a product feed manager. Each one touches merchant records, and each one usually signed paper that limits what the vendor can do with them beyond running the product.
The more useful question for a CEO is narrower: which records did your company create while building, selling and supporting the product? Those records are often yours, and they are where licensing conversations start.
Merchant-owned, shopper personal and vendor-owned records#
Ecommerce software companies hold three main families of records, and each carries a different owner and a different default. Sorting them before anyone discusses licensing prevents rework later, because every later step depends on the sort.
The table shows the sorting rule most rights reviews end up using. Derived data and platform-sourced data sit in between and need a clause-by-clause read.
| Record family | Typical examples | Usual owner or controller | Default for licensing |
|---|---|---|---|
| Merchant business data | Orders, SKUs, product descriptions, pricing rules, discount codes, inventory counts, store settings | The merchant, under your customer terms | Out unless the merchant grants a specific license |
| Shopper personal data | Names, shipping addresses, emails, phone numbers, order histories tied to a person, payment tokens, session events | The merchant as controller, with your company processing on its behalf | Out; removed during preparation wherever it appears |
| Vendor operational records | Support tickets, Jira issues, pull requests, code reviews, incident postmortems, release notes, onboarding playbooks | Your company | Main candidate once merchant and shopper details are removed |
| Derived and aggregated data | Cross-store benchmarks, conversion trends, fraud signals, feature usage statistics | Depends on your usage data and aggregation clauses | Case by case, read against each contract version |
| Platform-sourced data | Store and order data an app pulls through a host platform's API | The merchant terms plus the platform's partner and API terms | Usually limited to providing the app |
Where merchant and shopper details hide in vendor records#
Merchant and shopper details hide in vendor records because support and engineering work happens on real store problems. A ticket about a failed checkout often quotes an order number, pastes a shopper's email and attaches a screenshot of the merchant's admin panel.
Finding these traces is the core of preparation. Removal has to cover free text and attachments, not only structured fields, and reviewers need to know the identifier formats your product generates so they can catch them by pattern.
- Ticket bodies and replies that quote order numbers, store URLs, shopper names or delivery addresses.
- Screenshots and CSV attachments of product feeds, order exports or customer lists sent in to reproduce a bug.
- Application and webhook logs pasted into Jira issues, which often carry full order payloads.
- Slack threads where engineers paste a merchant's configuration while debugging.
- Test fixtures and seed files built from a real store's catalog instead of synthetic products.
- CRM notes from sales and onboarding that record a merchant's revenue, margins or supplier names.
What a usage data clause does and does not cover#
A usage data clause usually lets a commerce software vendor use operational and aggregated data to run, secure and improve its own service. It rarely grants a right to license merchant-derived records to a third party, and it almost never reaches shopper personal data.
Read the exact wording in every version of your terms that merchants actually signed, including enterprise redlines. Merchants who negotiated often struck or narrowed the clause, and older click-through versions may say less than the current one.
As AI shopping agents start reading catalogs and placing orders, expect larger merchants to ask directly whether their data trains anyone's models. Answer from your signed contracts and DPA, not from intent, and keep the answer consistent across sales, support and your trust page.
| Clause wording | What it usually supports | What it usually does not support |
|---|---|---|
| Use data to provide and maintain the services | Hosting, support and troubleshooting for that merchant | Any use outside the merchant's own service |
| Use aggregated or de-identified data to improve the services | Product analytics, internal benchmarks, your own feature work | Handing merchant-derived datasets to an outside developer |
| Vendor owns usage data or service data | Metrics about how the product performs and is used | Ownership of order, catalog or shopper content |
| Merchant grants a license to its content | Displaying and processing catalog and order content in the product | Training or licensing for unrelated purposes, unless stated |
App vendors on a host platform carry one more layer#
An app vendor that builds on a host commerce platform answers to the platform's partner and API terms as well as to its own merchant agreements. Data your app pulls through the platform's API is typically licensed for providing the app to that merchant, and platform terms can address AI use directly.
Developer terms elsewhere in the software ecosystem show where this is heading. HubSpot's developer changelog says its updated Developer Terms restrict using data accessed through HubSpot APIs to train, fine-tune or improve AI or machine learning models, with a carve-out for legitimate single-customer use cases. Check the current partner, API and app store terms of each commerce platform you build on before treating any API-sourced record as yours.
Your own code, support history and engineering discussions are a different matter. Your team created those records, even when the product they describe runs inside someone else's platform.
Illustrative: a subscription-billing app vendor sorts its archive#
Illustrative: a fictional company sells a subscription-billing app to direct-to-consumer brands. Support runs in Zendesk, engineering in Jira and GitHub, internal discussion in Slack, and its production database holds merchant plans, shopper subscriptions and payment tokens.
The CEO asked which records could be licensed without asking merchants for anything. The rights review classed the production database, merchant product feeds and webhook payloads as merchant or shopper data and left them out. It placed support tickets linked to Jira issues and pull requests in scope, because those records show how billing failures, proration bugs and dunning problems were diagnosed and fixed.
Preparation removed merchant names, store URLs, order IDs and shopper emails from tickets and issues, and dropped attachments entirely. Chargeback dispute tickets were excluded because shopper details were too dense to remove reliably. The result was a smaller package with a clear rights basis and no merchant data in it.
A scoping checklist for commerce software CEOs#
A scoping checklist keeps the merchant data question from reopening each time someone proposes a new record family. Work through it once, record the answers and reuse them.
- List every system that holds records: helpdesk, issue tracker, code host, chat, CRM, product database and data warehouse.
- Tag each system as merchant data, shopper personal data, vendor records or mixed.
- Collect every version of your merchant terms, DPA and enterprise redlines still in force.
- Check the partner and API terms of each host platform your app runs on.
- Note public statements, trust pages and sales answers about AI training, and treat them as commitments.
- Decide which mixed systems can be cleaned and which stay out entirely.
How SourceX approaches ecommerce vendor records#
SourceX runs each package through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. In the Rights step, merchant-owned records, shopper personal data and vendor-owned records are separated before anything else is discussed, and the initial fit check collects only metadata.
A package that proceeds carries a SourceX Evidence Packet recording provenance, licensing rights, permitted use, the privacy record and release authorization. The vendor approves every step, licenses the records rather than selling them and keeps ownership.
Frequently asked questions
Do we need merchant permission to license our own support tickets?
Often not, if the tickets are your company's records and merchant and shopper details are removed during preparation. The answer still depends on your merchant terms, confidentiality clauses and what your trust pages promise. Counsel should confirm the position for each contract version before scoping is final.
Can we license benchmarks built from many merchants' stores?
Only if your terms clearly allow that use and the aggregation truly removes merchant and shopper identity. Many usage data clauses support internal benchmarks but not licensing them outward. Small merchant segments are a particular risk, because a niche benchmark can point back to a recognizable store.
Are product descriptions written by merchants ours to use?
Usually not. Product descriptions, images and catalog copy are merchant content, often protected by copyright, and your license to display them in the product does not extend to licensing them for AI training. Keep catalogs out unless a merchant grants a specific written license.
Does agentic commerce change who owns merchant data?
No. AI shopping agents change who reads catalogs and places orders, not who owns the records. What changes is merchant attention: stores ask harder questions about how vendors use catalog and order data, so documented answers matter more than before.
Could licensing vendor records hurt our merchant relationships?
It can if merchants are surprised. Keep merchant and shopper data out, document what is in, and decide in advance how you would describe the program if a merchant asks. A clear, written scope protects the brand far better than silence.
Sources
- HubSpot's developer changelog says its updated Developer Terms restrict using data accessed through HubSpot APIs to train, fine-tune or improve AI or machine learning models, with a carve-out for legitimate single-customer use cases. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.