OpenMerchant Privacy Policy

OpenMerchant Inc, a Delaware corporation (“OpenMerchant,” “we,” “us,” or “our”), provides merchant-authorized commerce discovery and conversion-enablement software. This Policy explains how we handle information through openmerchant.dev, our dashboard, APIs, integrations, hosted endpoints, and support (the “Service”).

1. Our commitment and scope

We do not sell or rent merchant data or shopper personal information. We do not share it with unrelated third parties for their own advertising, marketing, data-brokerage, or other commercial purposes.

We use non-public merchant information for business and identity verification (KYB/KYC), eligibility and compliance checks, and the commerce services the merchant asks us to provide. Those services include authorized catalog publication and discovery, UCP signing, Google Merchant Center and Meta commerce management, merchant-selected reporting, and transactions, together with necessary account administration, measurement, billing, security, fraud prevention, support, refunds, disputes, and legal compliance. We do not repurpose this information for unrelated marketing, cross-merchant advertising audiences, commercial data products, or general-purpose AI training.

Providing these services requires limited disclosures. Stripe and other payment providers receive necessary verification and transaction information. Google, Meta, and enabled agent surfaces receive authorized catalog, integration, measurement, and relevant order information for the features the merchant enables. Contracted infrastructure providers process data to run the Service. Required legal or security disclosures may also occur. Section 6 explains these exceptions; this is not a promise that data never leaves OpenMerchant.

Public catalog information is different from private merchant data. When a merchant directs us to publish an offer, the designated product details, seller identity, public support contacts, policy links, endpoints, and public verification keys become available to the relevant recipients and, for public endpoints, the public. We do not publish identity-verification documents, private signing keys, access tokens, or private customer lists as part of a catalog.

This Policy covers personal information about merchant representatives, authorized users, website visitors, people who contact us, and shoppers whose information is processed through the Service. Our no-sale and purpose-limitation commitments also cover non-public merchant business data, even when it is not personal information.

2. Our role and other participants

Each merchant is the seller and merchant of record for its shopper transactions. OpenMerchant Inc provides the software and charges the merchant a transaction fee on eligible captured agent transactions. There are currently no separate discovery or impression charges.

• Our own limited operational purposes: We act as a controller or business for account administration, KYB/KYC and eligibility review, our billing, security, fraud prevention, compliance, and direct communications.
• Processing on a merchant's instructions: For shopper, order, fulfillment, or support information processed solely to deliver the merchant's requested service, we generally act as the merchant's processor or service provider. The merchant's privacy notice and any applicable data processing agreement also apply.
• Independent services: Stripe, Google, Meta, other payment providers, and enabled agent surfaces may have their own privacy responsibilities and data uses. Our commitments govern OpenMerchant; they do not rewrite those providers' agreements.

An “agent surface” is an AI assistant, shopping application, registry, or discovery service that requests, displays, or transacts with merchant offerings. Enabling an integration requires the relevant permissions and disclosures; signing up with OpenMerchant does not authorize every possible future integration.

3. Information collected and its sources

We collect only information reasonably needed for an enabled service or an identified compliance obligation. Technical access to a connected account does not give us permission to harvest unrelated records.

Information	Examples and sources	Purpose
Merchant identity and account information	Business name, address, country, website, contact details, representative and ownership information, tax details, account identifiers, licenses, verification results; supplied by the merchant, an authorized provider, or relevant lawful public business sources	Account setup, KYB/KYC, eligibility, compliance, account security
Verification documents, where actually required	Identification, registration, or ownership documents supplied through an approved verification flow; providers may collect them directly and return only a status	A specific verification, fraud, or compliance requirement; not discovery or advertising
Merchant-authorized catalog information	Products, descriptions, images, price, inventory, availability, shipping, tax configuration, policies, and public seller details from the merchant or its verified storefront/feed	Publish and maintain the requested commerce listings and integrations
Order and payment information	Buyer contact and delivery details, authorized items, amount/currency, quote/order/payment identifiers, credential scope, payment status, limited payment-method metadata, refunds and disputes; supplied by transaction participants	Route and support the authorized transaction, fulfill it, reconcile fees, and prevent fraud
Authorization and delivery evidence	Policy versions, acceptance events, agent scope, timestamps, delivery records, relevant login/access/paid-feature events, and IP/device information where available	Verify authorization and delivery and resolve support, refunds, fraud, or disputes; no guarantee of a dispute outcome
Discovery measurement	Product and surface identifiers, display confirmation, timestamps, attribution and deduplication identifiers, minimal request context and invalid-activity signals	Provide merchant reporting, validate discovery measurements, and prevent abuse; discovery measurements are not currently billed
Integration and security information	OAuth grants and tokens, app-scoped provider identities, business and asset identifiers, account roles, configuration, webhook metadata, public keys, securely managed private signing keys, and key-lifecycle records	Operate and secure authorized UCP, payment, commerce, Google, and Meta integrations
Operational logs and communications	Authentication, API, error, IP/device and security events; support messages, invoices, contracts, and voluntarily submitted information	Operate, diagnose, secure, bill, and support the requested service and document compliance

We do not need a shopper's full unrelated conversation history to process an order or count an impression. Merchants and integrations must minimize free-text and sensitive information sent to us. We do not intentionally request health records, biometric data, precise location, or unrelated government identifiers. Identity documents required for merchant verification must use the approved verification workflow, not catalog fields, public endpoints, or ordinary support messages.

Where Stripe Radar is enabled, Stripe may collect device characteristics and customer-activity signals for fraud detection and make relevant indicators available to other Stripe users under its own terms. OpenMerchant supplies only relevant permitted information and uses returned risk data only within Stripe's restrictions, not for marketing, credit eligibility, or an independent commercial fraud-data product. Merchant relationship decisions using Radar for Platforms are not based solely on that signal; a merchant may request human review at support@openmerchant.dev.

Payment credentials

The supported tokenized/scoped payment flow is designed for the payment or credential provider to handle raw card numbers and card security codes. OpenMerchant may process limited-use tokens, credential scope, payment identifiers, card brand/last four digits, and transaction or risk metadata. These remain protected information; “tokenized” does not mean anonymous or unrestricted.

Do not send raw card numbers or security codes through ordinary OpenMerchant APIs, catalogs, logs, or support. Any different payment architecture must be separately approved, documented, and supported by appropriate PCI compliance and updated disclosures before it is enabled.

4. Allowed uses—and prohibited uses

We use the information above only to:

1. Verify and administer the merchant and authorized users, including KYB/KYC, business eligibility, and applicable compliance checks;
2. Carry out the merchant's enabled catalog, discovery, UCP, Google Merchant Center, Meta commerce and reporting, and other commerce integrations;
3. Route and support authorized quotes, orders, payments, fulfillment updates, cancellations, refunds, and disputes;
4. Measure the merchant's discovery and transaction activity for reporting, calculate agreed transaction fees, correct errors, and maintain necessary financial records;
5. Protect accounts and the Service, investigate fraud or security incidents, diagnose errors, and maintain the reliability of those requested functions;
6. Respond to requests and send necessary operational, security, verification, billing, and policy communications; and
7. Meet applicable legal and provider obligations, report relevant prohibited activity, and establish or defend legal rights.

We do not use private merchant, KYC, order, or Google account data for unrelated product research, general-purpose AI training, third-party marketing, audience building, or selling industry benchmarks. We do not use a merchant's customer list to market another merchant's products. Aggregating, deidentifying, or deriving a metric does not create permission to use the underlying data for an unrelated purpose. Internal minimized operational metrics may be used only for the purposes above; we do not attempt to reidentify deidentified data.

If a merchant explicitly requests an AI-assisted catalog transformation, only the necessary authorized content may be processed for that task by a contracted provider under appropriate data-use restrictions. KYC documents, payment credentials, and unrelated customer records must not be sent to a content-generation model. Any materially different data use requires a separate clear disclosure and the necessary affirmative authorization before it begins.

Waitlist contact information is used to respond to the person's request and provide access-related updates. A merchant's KYC or transaction data is not a source of marketing leads. Any optional promotional subscription must be separately chosen and can be stopped using its unsubscribe method or by contacting us.

5. Google Merchant Center, Google API data, and UCP keys

When a merchant connects Google, the permission screen and enabled functions determine our access. Data may include the authorized Google identity/email, Merchant Center account identifiers and roles, business and website settings, product data, shipping and return policies, diagnostics, approval status, available performance reports, and integration metadata. OAuth access and refresh tokens maintain the authorized connection. We do not request Gmail, Drive, Contacts, or unrelated Google services merely to manage Merchant Center.

We use this data to create, connect, configure, synchronize, diagnose, and operate the Merchant Center features the merchant enabled, and to show relevant status and measurement reports. We may send merchant-approved business, product, return, support, UCP profile, public-key, and transaction-status data to Google as required by that integration. This does not authorize sending private KYC files or unrelated shopper records to Google for advertising.

OpenMerchant's use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including applicable Limited Use requirements. In particular:

• We request only permissions needed for enabled user-facing functions and explain any new permission before requesting it;
• Google API data is not sold or used for ad targeting, unrelated marketing, credit decisions, or general-purpose model training; applicable restrictions also cover derived or aggregated data;
• Human access is restricted to applicable permitted circumstances, such as the user's specific agreement for support, necessary security work, legal compliance, or permitted aggregated internal operations; and
• The stricter Google rule prevails if a general disclosure elsewhere in this Policy would allow a prohibited use or transfer, including a corporate-transaction transfer requiring explicit prior consent.

Publishing a merchant-authorized catalog is distinct from selling private Google account data or using it to target advertising. Catalog publication does not authorize reuse of Google-derived data outside Google's permitted purposes.

Keys: Public UCP verification keys and profile metadata are intentionally published. Private signing keys and OAuth tokens are not public content and are accessible only to authorized systems or personnel with an operational need. We retain limited key-use and revocation evidence for security and transaction verification, not advertising. Signing proves message origin and integrity; it does not replace buyer authorization.

Disconnecting: A merchant may revoke Google access in its Google Account connections, remove OpenMerchant's account permissions in Merchant Center, use available OpenMerchant integration controls, or contact support. We stop new access and operations under revoked authority, disable or delete affected usable tokens/keys as appropriate, and delete or retain existing records only under Section 8. Revocation does not itself erase Google's catalog copy or close the merchant's Google account. Key migration or revocation may also require updates to a profile hosted on the merchant's domain.

Meta business, catalog, shop, Instagram, and advertising data

When a merchant connects Meta through Facebook Login for Business, the selected login configuration and the features the merchant enables determine our access. Data may include an app-scoped user or business-system-user identifier; authorized Business portfolios; product catalogs and products; Facebook Pages; professional Instagram accounts; Commerce Manager accounts, shops, and connected sales channels; Page and Instagram insights; advertising-account identifiers; and advertising delivery and spend measurements. Meta requires pages_read_user_content as a dependency of the professional Instagram access we request, but OpenMerchant does not use that dependency to ingest Page visitor posts or unrelated user content. We store the authorization token securely to maintain the requested connection. We do not use the connection to read private Facebook messages, personal posts, friends, or unrelated consumer activity.

We use this data to let the merchant select its own assets, publish and maintain its requested catalog, verify shop setup, and import the reports it chooses to see in OpenMerchant. Advertising access is separate from the base catalog connection. ads_read is used for merchant-selected advertising reports. If ads_management is requested, it is used only for an advertising-management feature that the merchant deliberately enables and operates; merely connecting Meta does not authorize OpenMerchant to create or change campaigns without that action. Meta data is not used to build cross-merchant advertising audiences, target unrelated advertising, sell data, or train a general-purpose AI model.

Disconnecting and deleting: A merchant may disconnect Meta in OpenMerchant, remove OpenMerchant in Meta's Business Integrations settings, or contact support. Revocation stops future authorized access. When Meta sends its authenticated data-deletion callback, OpenMerchant verifies Meta's signature and deletes the matching usable authorization token, provider identity, selected Meta assets, catalog-delivery receipts, and imported Meta reporting observations from active local storage. The callback returns a confirmation code and status page. Canonical catalog information the merchant supplied directly to OpenMerchant, transaction records, and records subject to a specific legal retention duty are handled under Section 8 rather than being treated as Meta-derived data. Revoking or deleting the OpenMerchant connection does not itself delete the merchant's Facebook Page, Instagram account, Business portfolio, ad account, or independently held Meta catalog copy; the merchant can manage those assets in Meta's tools.

6. Limited operational disclosures

We disclose the minimum reasonably necessary information to these recipients, for these purposes:

• The relevant merchant and its authorized users: Their own catalog, customer/order, discovery, billing, and support records. One merchant does not receive another merchant's private records.
• Stripe and selected payment/verification providers: KYB/KYC and eligibility information, payment instructions and scoped credentials, and necessary order, fraud, refund, dispute, reconciliation, and compliance records. See Stripe's Privacy Policy for its independent processing.
• Google, Meta, and the enabled agent surface or registry: The catalog and public configuration the merchant directs us to publish, selected measurement or setup information required by an enabled integration, plus information necessary for the specific authorized quote, checkout, order status, or support interaction. See Google's Privacy Policy and Meta's Privacy Policy. A provider or surface does not receive private KYC information merely because it displays an offer.
• Merchant-selected commerce or fulfillment integrations: Information needed for the requested synchronization, order, delivery, or support function.
• Contracted subprocessors: Hosting, secure signing/key management, authentication, communications, security, and support providers processing on our behalf under confidentiality, security, and purpose restrictions. They are not authorized to sell the data or use it for their own marketing or generalized model training. Request information about relevant subprocessors at support@openmerchant.dev.
• Necessary legal, risk, and security recipients: Providers, networks, regulators, courts, law enforcement, affected participants, or professional advisers when required by law or reasonably necessary to investigate a specific fraud/security issue, satisfy a relevant provider obligation, or establish or defend legal rights. Disclosures are limited to relevant information; routine publication of KYC documents or private order databases is not permitted.

We do not disclose identifiable non-public merchant or shopper records to prospective investors as a routine diligence data set. Any proposed transfer to a successor business must comply with law and provider restrictions and preserve these use limitations; we obtain explicit prior consent where required, including for Google API data subject to that requirement. This is not permission to sell the data as a standalone asset to a data broker.

Stripe, Google, and other independently selected recipients may have broader rights under agreements the merchant separately accepts. For example, an agentic catalog integration may allow the provider to retain or improve its services using submitted catalog content. OpenMerchant cannot promise those independent recipients use all information solely for KYC or one transaction. We disclose the integration and applicable terms before activation so the merchant can decide whether to enable it.

7. Cookies, advertising, and U.S. privacy disclosures

Necessary cookies or similar storage may support authentication, preferences, security, and operation. Non-essential measurement technologies require the notices and choices applicable in the person's jurisdiction; they are not used to build advertising audiences across unrelated businesses. A server-side label does not remove a consent requirement.

Providing commerce discovery and optimization does not involve selling shopper or merchant data. OpenMerchant does not sell personal information for money or other valuable consideration, share it for cross-context behavioral advertising, or use it for targeted advertising as defined by applicable U.S. state privacy laws. We do not use sensitive personal information to infer unrelated personal characteristics or make credit decisions.

Categories processed as applicable are identifiers and contact information; business/customer-record information; commercial and transaction records; internet/network and approximate IP-based location information; professional role information; communications and supplied attachments; verification documents, account credentials, and limited financial information; and necessary fraud/attribution inferences. Sources, purposes, and business-purpose recipients are specified in Sections 3–6, and retention criteria in Section 8. We do not discriminate against people for exercising privacy rights. Where an applicable opt-out signal or right is relevant, we honor it as required by law.

8. Retention and deletion

We retain data only while needed for the stated purpose, considering the enabled service, transaction/refund/dispute lifecycle, applicable recordkeeping obligations, security investigations, and deletion rights. These criteria apply by category—not as blanket permission to keep every document or log indefinitely:

• Merchant verification: Retain the result and minimum supporting evidence needed for active eligibility and applicable compliance obligations; avoid keeping raw identity documents when a provider-retained document and verification status suffice.
• Catalogs and connected Google or Meta account data: Maintain operational copies while enabled; after removal, disconnection, or an authenticated provider deletion request, delete copies no longer needed, subject to specific lawful record-retention requirements.
• Usable OAuth tokens and private signing keys: Retain only while authorized and needed. Stop using revoked credentials, disable access, and retire or securely delete them; historical public keys, identifiers, and verification evidence may remain where needed.
• Orders, contracts, fee, refund, and dispute records: Retain the minimum needed for fulfillment, applicable tax/accounting and provider requirements, and relevant claims or dispute periods.
• Detailed IP, login, usage, and impression logs: Retain only as needed for security, measurement reconciliation, support, and a specific dispute; minimize, delete, or irreversibly aggregate them when those needs end.
• Support and waitlist information: Retain while needed to resolve the request, provide requested access, or meet a specific recordkeeping obligation; honor opt-outs and deletion requests subject to those limits.

Backups follow a restricted-access expiration process. Data retained solely in backups is not used for new commercial purposes and deletion restrictions are reapplied if a backup is restored. A documented legal hold or unresolved incident can justify longer retention only for relevant records. Google- and Meta-specific deletion and use restrictions still apply. Retained data remains subject to this Policy and is not available for unrelated use.

Provider-specific data limits override general retention criteria. Stripe Radar data is retained or disclosed only where Stripe's terms permit and is deleted when those terms require, including on termination or Stripe's request, except to the extent retention is required by law.

Request deletion at support@openmerchant.dev. A person may also use Facebook's removal and deletion flow for data obtained through the Meta integration; Meta's authenticated callback initiates the automatic deletion described in Section 5. We explain a material lawful reason for retaining requested data where required and respond within the applicable legal deadline. Removing data from OpenMerchant does not automatically remove data held independently by a merchant, Stripe, Google, Meta, a registry, or another surface. We assist within our authority; public catalog copies may persist in external caches.

9. Security and incident handling

We use reasonable administrative, technical, and organizational safeguards, including access limitations, credential scoping, logging, and data minimization. Google and Meta API data, OAuth tokens, and private signing keys must be protected in transit and at rest. Access is restricted to people and systems needing it for an allowed purpose. Public-key publication does not authorize disclosure of private keys.

No system can guarantee absolute security. Report a suspected compromise to support@openmerchant.dev. If we become aware of a breach affecting data processed on a merchant's behalf, we notify the affected merchant without undue delay and provide cooperation required by law and our data processing agreement. We notify individuals or authorities when legally required.

10. Legal bases and international processing

For processing where OpenMerchant is a controller and EEA/UK law applies, we rely on contract where needed to perform a contract with the individual; legitimate interests in operating, securing, verifying, and supporting the requested business service where balanced against individual rights; applicable legal obligations; or consent where required. A contract with a company is not automatically the legal basis for every employee's or shopper's data. As processor, we follow the merchant's lawful instructions and relevant processing agreement.

OpenMerchant is based in the United States. Necessary providers may process data in other countries. Where international-transfer safeguards are required, the relevant transfer must be supported by an applicable adequacy decision, Standard Contractual Clauses and required UK addendum, or another lawful mechanism. Contact support@openmerchant.dev about recipients, locations, and applicable safeguards. This Policy is not itself a data processing agreement or transfer mechanism.

11. Your choices and rights

Subject to applicable law, you may request access, correction, deletion, portability, restriction, or objection; withdraw consent; exercise applicable advertising or profiling opt-outs; and appeal a denied request. Email support@openmerchant.dev, describing the request and enough account or transaction context to locate the information. Do not send passwords, private keys, card numbers, or unrequested identity documents.

We use proportionate identity and authority verification and respond within applicable deadlines. Authorized agents may act with required evidence of authority. To appeal a denial, reply to our response or email support@openmerchant.dev with “Privacy appeal.” Where applicable, our appeal response explains further complaint options. EEA/UK residents may complain to their competent data-protection authority without first contacting us.

For a shopper purchase, the merchant is normally the best first contact. As its processor, we route or assist requests under the merchant's instructions and applicable law. As controller, we address our own processing directly. Revoking an integration stops future authorized access but does not waive an outstanding lawful payment obligation or require deletion of records that must legally be kept.

12. Children and restricted data

The Service is designed for business users and is not directed to children. Merchants must not knowingly submit children's personal information or use OpenMerchant for child-directed data collection without an approved use case, required notices and permissions, and appropriate safeguards. Adults may buy lawful products intended for children without submitting unnecessary information about a child. Contact support@openmerchant.dev about improperly collected information.

13. Changes

We publish changes with a new effective date. Material changes require appropriate notice and any necessary consent before new processing begins; a website update alone does not authorize a previously prohibited use of existing data. Google or Meta user data will not be accessed or used in a materially new way before the required updated disclosure and consent. We will not use this Policy to retroactively evade an earlier binding privacy commitment.

14. Contact

Privacy questions, deletion requests, appeals, security reports, and service support: support@openmerchant.dev
Legal notices: legal@openmerchant.dev

OpenMerchant Inc
Attn: Privacy
United States