Privacy Policy

1.About this policy

This policy describes what information Infinity AI Solutions ("we", "the platform") collects, how it is stored and what we do with it, in operating the platform at infinity-ai-solutions.com — a service where business owners ("merchants") create and run an online store.

Effective and last updated: 21 August 2026.

2.What this policy does not cover

Every store built on the platform has its own privacy policy, written and published by that merchant at /policies/privacy-policy on the store's own domain. If you reached this page after buying from a particular store, the policy that applies to you is that store's, not this one.

For shopper data, the merchant is the controller and we act as a processor on their behalf and on their instructions.

3.Signing in with Google

Merchant sign-up and sign-in happen exclusively through Google. We request the openid, email and profile scopes.

• Google returns the account identifier (sub), email address, name and profile picture.
• We persist only the email address and the account identifier, in the central store registry, to link your sign-in to your store.
• The name is kept only in a signed cookie, for seven days, to display "signed in as…". The profile picture is never stored.
• Authorization is requested with access_type=online, so no refresh token is issued or stored — we have no ongoing access to your Google account after sign-in.

4.Connecting a Google account for marketing channels

Separately from sign-in, a merchant may connect their Google account to link the store to Merchant Center, Google Ads and Google Analytics. This is a completely separate OAuth client, and the connection is started by the merchant from the "Marketing channels" screen in the store admin.

Here authorization is requested with access_type=offline, so a refresh token is issued and stored — that is what lets synchronization continue without asking you to sign in again each time.

5.Which scopes we request, and exactly what we do with them

https://www.googleapis.com/auth/userinfo.email

One call to oauth2/v3/userinfo. From the response we keep only the email address — to show you which account is connected and to detect if the connection was re-linked to a different account. The "test connection" button makes the same call.

https://www.googleapis.com/auth/adwords

Two uses. Read: a call to customers:listAccessibleCustomers, which returns a list of Google Ads account IDs and nothing else, so you can pick which account the store is associated with; a daily job which calls googleAds:searchStream three times, with three queries against three resources, all scoped to the account you selected: campaign returns your own campaigns for the last 30 days — id, name, status, type, budget id, bidding strategy type, and per-day cost, impressions, clicks, conversions and conversion value (the same query is also sent for one campaign when you press "target ROAS", so that we can refuse to write a target onto a campaign whose bidding strategy is a different one); shopping_performance_view returns the same metrics broken down per product, so you can see which of your own products the spend went to; and asset_group_asset returns a snapshot of that campaign's asset groups — each asset's id, field type, the performance label Google gave it, and, for text and image assets, your own ad copy and the URL of your own creative image. Without the text, the "replace a low-performing asset" screen could only show you an id. That is your advertising data: it is stored in your own store database, shown back to you in your own admin, never aggregated across merchants, never shared, and never written back to Google. And, for each such account, a single googleAds:search query against the customer resource, which returns that account's display name, currency code, time zone and whether it is a manager account. The name is shown so you choose an account by name rather than by number; the time zone is required because Google Ads records a conversion against that account's own calendar day, so a timestamp sent in any other zone lands on the wrong day with no error; and the currency is read so we can decline to compute a profit figure when your store and your ads account report in different currencies, instead of dividing one currency by another. And where one of those accounts is a manager account, one further query per manager, FROM customer_client, returns the same four fields for that manager's child accounts — an account reachable only through a manager answers the direct query with a permission error and would otherwise appear in your picker as a bare number. That one runs when the channel is connected and on "refresh assets", i.e. before you have selected anything. Write — each of these only when you press the button, in your own store admin. None of them runs on connect, on a schedule, or from any background job. googleAds:mutate creates a Performance Max campaign in your own account, from a wizard you fill in yourself: the campaign, its budget and its asset group are sent as one atomic operation, always after avalidateOnly preflight so Google's own objections are shown to you before anything exists, and the campaign is always created with status PAUSED — it cannot begin serving without a further, separate action by you: enabling it from the campaign controls in your own store admin, or inside Google Ads. campaignBudgets:mutate sets the daily budget of a campaign you selected; campaigns:mutate sets its target ROAS, pauses and enables it when you press the toggle — pausing stops serving and spending and can be undone at any time — and removes a campaign permanently, only after you confirm a dialog stating that a removal at Google cannot be undone and that we cannot bring the campaign back; campaignCriteria:mutate adds negative keywords and never removes any, so a list you maintain inside Google Ads is untouched; assets:mutate creates an asset in two shapes — a text asset when you replace one Google itself labelled low-performing, and an image asset carrying the bytes of a product image from your own storefront, uploaded when you build a campaign in the wizard (up to the twenty marketing images plus logos Performance Max accepts); that image is fetched from your own store through the same SSRF guard the rest of the platform uses, its type is verified from its opening bytes rather than from a filename, and it is sent base64-encoded; and googleAds:mutate sends that replacement as a single atomic operation attaching the new asset and detaching the low one together — either both happen or neither, because an asset group that drops below Google's minimum stops serving with no error anywhere. Apart from those uploaded images, every field we send is content you typed or a number you chose, and each update carries an explicit updateMask so no other field on the resource changes. Write: once you have configured a conversion action, we upload offline conversions on your behalf via customers:uploadClickConversions, so that a purchase which began with an ad click is credited to that ad. Each upload contains the Google click identifier (gclid, or its gbraid/wbraid equivalents), the order value, the currency, the time of purchase and the order number. No email address, phone number or any other personal identifier of the shopper is included in these uploads. Both uses require an approved Google Ads developer token and are skipped entirely without one.

https://www.googleapis.com/auth/content

Two uses. Read: a call to accounts/authinfo, which returns Merchant Center account IDs, so you can pick which account receives the store's product feed. Write: registering the feed URL as a primary data source on that account and triggering its fetch (dataSources and dataSources:fetch — Google pulls the file from your store's URL; we never upload a file to them), and creating a supplemental data source, and updating price, sale price and availability for products that changed (productInputs:insert), so that what Google shows does not lag behind your store. The response carries each item's status at Google, which is what the channel sync panel displays to you. From the same screen you can also withdraw an update we pushed (productInputs.delete) — that deletion is limited to the supplemental data source we created on your account, so it removes the price and availability we pushed and not the product itself: a product carried by your primary feed stays in Merchant Center and returns with the feed's own values at the next fetch. Further reads, for diagnostics only: accounts/…/homepage (whether your website is claimed), accounts/…/issues (any account-level policy issues Google records), accounts/…/businessInfo (the business address Google currently holds on the account, so you can see what they have before deciding whether to send yours), accounts/…/relationships (which Google Ads accounts are linked), accounts/…/businessIdentity (the business identity you have declared on the account — for example women-owned or small business, and whether you consented to Google using it in their programs. We read it only: a declaration about your business is not something we fill in on your behalf), accounts/…/regions (which shipping regions — postal code groups — are already defined on the account, so we can verify that a rate table refers to a region that actually exists there)dataSources with fileUploads/latest (whether the scheduled fetch of your feed succeeded, how many items were processed, and the errors Google returned), and reports:search (what Google says about each individual product — which items it disapproved or demoted, and why. This is one reporting query per day and it changes nothing on the account: it is a POST only because the query travels in the request body. Without it the panel would show "all synced ✓" while your products do not appear in Shopping). That information is shown to you on screen; it is never written back, aggregated or shared. Six writes you initiate: claiming your store's address for the Merchant Center account you selected (accounts/…/homepage:claim); updating the business address on that account (accounts/…/businessInfo) from the structured address you entered in your store settings — street, city, postal code, region and country, and nothing else; and sending the shipping settings you defined on the "shipping settings for Google" screen (accounts/…/shippingSettings:insert) — service name, destination country, currency, the delivery-days window and the rate table by order value, and nothing else; and sending the return policy you defined on the "return policy for Google" screen (accounts/…/onlineReturnPolicies) — country, policy type, the return window in days, who pays for return shipping, and a link to the policy page on your own store, and nothing else; and creating a shipping region on that account (accounts/…/regions) — the region name and the postal codes you typed on that screen, and nothing else — so that you can declare a different rate for a particular area; and opening a new Merchant Center account in your name (accounts:createAndConfigure), if you have no account and ask us to open one. That write has its own paragraph below, because it is the only one that creates an asset rather than changing an existing one. All six run only when you press the button in the admin, never on their own, not on connect and not from any scheduled job. We never take over another account's claim; and the address update is sent with a field mask (updateMask=address) that replaces the address only — no other field on your account is removed or changed. Shipping settings, by contrast, are replaced in full — that is how Google defines this resource, and it has no field mask. So we first read the settings already on the account and send back the warehouses you configured there yourself; a read that fails stops the send and writes nothing. A return policy is created and never deleted by us — Google's API has no update for this resource, so if a policy for that country already exists on your account we stop and say so rather than delete it or create a duplicate. A policy you have not filled in, or whose policy page is still a draft, is not sent at all — we do not declare a default you did not choose on your behalf, and we do not derive the fields from the page text. Shipping regions are created and never deleted or edited by us — a region on your account may be used by other settings of yours, and we cannot tell a region we created from one you defined yourself. A rate row that refers to a region which does not exist on the account stops the send and is reported to you by name, rather than being sent as a declaration covering the whole country. Opening a Merchant Center account in your name — only if you ask, and only after a consent screen. If you have no Merchant Center account, we offer to open one for you as a sub-account under the platform's advanced account (MCA). Before that happens you are shown a screen stating what will be created (the account name — your store's name — the account language and the time zone, and nothing else: Google's creation call has no field for an address or a phone number, and those are sent separately, by a separate button), under whom (our advanced account, which can manage the sub-account) and what that means — and only then a button. The account is yours: your own Google account is added as an administrator of it — it is the one making the request — and you can remove the link to our advanced account from inside Merchant Center and keep the account in full ownership. We never delete accounts and never unlink them for you. The action runs once and once only: if we already opened an account for you, or you already selected one, or an account with the same name already exists in your Google account, we do not create a second one — we tell you what is there instead. ⚠️ This route depends on the platform holding an approved advanced account at Google; where there is none it is not shown at all, and you pick an existing account from the list as before. All of this is your own store's data, and it is written only to the Merchant Center account you selected, or the one opened for you at your request.

https://www.googleapis.com/auth/analytics.readonly

Read only, in three places. accountSummaries returns GA4 property IDs and display names, so you can pick the store's measurement property; properties/{id}/dataStreams returns those properties' measurement IDs (G-XXXXXXX), so you do not have to type them in by hand; and the performance screen in your own admin area calls runReport and receives aggregate figures only for the range you pick on that screen — the last 7 or 30 days — sessions, conversions, transactions and revenue, plus an aggregate breakdown by traffic channel group (e.g. "Organic Search") and by product name. No user-level data is read, and no report is stored on our side.

https://www.googleapis.com/auth/webmasters

Search Console. webmasters/v3/sites returns the list of properties you have verified with Google and your permission level on each, so you can pick the one that belongs to this store; searchAnalytics/query returns aggregate search-traffic figures — clicks, impressions, click-through rate and average position, by page and by query, and we store them so we can show you a trend over time. sitemaps is used to show your sitemap's status and to submit it; urlInspection/index:inspect returns, for a page of your store, what Google knows about it — whether it is indexed, when it was last crawled, its robots.txt state, which canonical URL Google chose and how its rich results were judged. It runs two ways: when you inspect a particular URL, and in an automatic daily sweep of up to 60 of your own store's URLs per day, refreshing each one about every 30 days; Google's answers are stored in your own store's database so the screen can show a trend rather than a single snapshot. And sites is used, only when you explicitly ask for it, to add your own store's site to Search Console after you have verified it. We read only the property you selected, we never delete properties, and we never touch any other site in your account. Google offers no read-only permission that also allows submitting a sitemap, which is why this scope includes write access.

https://www.googleapis.com/auth/siteverification.verify_only

Site ownership verification, and only if you ask us for it from the SEO screen — for a merchant who has no Search Console property at all yet. siteVerification/v1/token returns a short text token, we add it as a meta tag on your store's home page, and siteVerification/v1/webResource asks Google to check that the tag is really there. The verification is recorded by Google against your own Google account — the platform does not become an owner of your site. This is the narrow form of the permission (verify_only): it does not let us read the list of sites you have verified in the past, and it does not let us manage them.

6.Where data is stored, and what is encrypted

• Every store has its own database (PostgreSQL on Neon, by default in the us-east-2 region). Channel connections and selected assets are stored in that store's database only — not in a table shared across customers.
• Access and refresh tokens are encrypted before being written, using AES-256-GCM (prefix enc:v2:). The encryption key exists only in the runtime environment and is never stored in the database.
• The connected account's email address, and the discovered account identifiers (Google Ads, Merchant Center, GA4 properties), are stored unencrypted — so we can show you in the interface what is connected and what is selected.
• Sign-in identity (email address and Google account identifier) is stored in the central store registry, not in any store database.

7.What we do not do with the data

• We do not sell or rent information received from Google.
• We do not transfer it to third parties, other than the infrastructure providers listed below.
• We do not use it to serve advertising, for ad targeting, or for profiling.
• We do not feed it to AI models. The platform uses two AI providers: Anthropic's API for translating store content and for the design assistant, and OpenAI's API for generating and editing images. Neither ever receives Google tokens, the connected account's email address, or any data retrieved from Google APIs, and none of this data is used to train models. ⚠️ Image editing sends the image itself to OpenAI — the product photo or section image you selected, from your store's own media storage — together with a description composed on our side; the result is written back to your store's storage and not kept at the provider. This is your own business media, and it contains no shopper information.
• No telemetry, analytics or session-recording tools are installed.
• A human reads such data only in the cases listed in the Google policy section below.

8.Compliance with the Google API Services User Data Policy (Limited Use)

In practice, this means:

• Information received from Google APIs is used only to provide or improve user-facing features that are prominent in the app's interface.
• It is not transferred to others except with your explicit consent, for security purposes, to comply with applicable law, or as part of a merger or acquisition with prior notice.
• It is not used for serving advertising, ad targeting or profiling.
• No human reads it, except with your explicit consent, for security purposes, to comply with applicable law, or where the data is aggregated and anonymized.

9.The log of writes to your Google account

Every write we make to your Google account is recorded in a log you can open: store admin → Marketing channels → Google write log. Each row records when the write ran, which operation was sent, to which Google API, the resource identifier Google returned, its status code, the response body, and who performed it. Every row carries a direct link to the place in Google's own interface where the result is visible — that link is built from the account identifier you selected, so a sub-account under a manager account leads to your account and not to the platform's.

The log holds no personal information and no tokens. Google's response body is stored as it came back except for identifying fields — address, phone and email are stripped before the row is saved, including when they are nested inside an object (businessInfo echoes back the address that was sent, and it is not stored). "Who performed it" is recorded as the internal user identifier in your own admin, not as an email address.

The log exists so that you can see what was sent on your behalf and when — and above all when a write failed part-way through a round. It is not shared with any third party and is not used for advertising.

10.Retention

• Access token — short-lived (about one hour), replaced on every refresh.
• Refresh token — until you disconnect, or until the store is deleted.
• The connected account's email address — until you disconnect.
• Selected account and asset identifiers — until the store is deleted. They are kept after a disconnect as well, so that reconnecting the same account restores exactly the setup you had.
• Sign-in identity in the registry — until the store is deleted.
• Sign-in cookie — seven days.
• The log of writes to your Google account — 180 days, and at most 2,000 rows per account. Older rows are deleted automatically.

11.How to disconnect

You can disconnect at any time: store admin → Marketing channels → Google → Disconnect. The action immediately deletes the access token, the refresh token and the connected account's email address from the database, and the platform stops calling Google on your behalf. Asset selections are kept so that reconnecting restores the same setup.

12.Deleting your data

To delete all of your data, contact us at noam.salomon@gmail.com from the email address registered on the account. Deleting a store deletes its entire database, its media files and its registry row — and with them every Google token, the connected account's email address and every stored account identifier. This is irreversible. We will action the request within 30 days.

Even after deletion on our side, revoking the grant on Google's side is done separately at myaccount.google.com/permissions.

13.Data sent to marketing channels from stores

When a merchant selects a GA4 property and supplies a Measurement ID and API Secret, the platform sends server-side ecommerce events to Google Analytics via the Measurement Protocol. These are authenticated by the property's API Secret, not by any OAuth token — which is why they keep working after the Google account is disconnected.

• What is sent: the client identifier from the _ga cookie, the session identifier, the order identifier, item details (id, name, price, quantity), the value and currency, and a consent object derived from the visitor's cookie consent. And on a search event, the search text you typed (search_term), up to 200 characters. It is the only free-text value of yours in this payload.
• When the order belongs to an identified customer, an opaque internal customer identifier from the store's own database (external_id) is also sent, in GA4's user_id field. It is meaningless outside that store.
• The events sent from the server are view_item, search, add_to_cart, begin_checkout, add_payment_info, generate_lead and purchase. page_view is sent from the browser only, by the measurement tag itself on page load — it has no server-side counterpart.
• No email address and no phone number are sent.
• When consent is denied, the event is blocked before dispatch.

Separately, when a merchant has configured a Google Ads conversion action and an approved developer token exists, a purchase that originated from an ad click is reported to Google Ads as an offline conversion. That call is authenticated with the merchant's OAuth token, so it stops when the account is disconnected.

• What is sent: the Google click identifier (gclid, gbraid or wbraid) captured from the landing URL, the order value, the currency, the time of purchase and the order number.
• This upload carries no email address, phone number, name or any other personal identifier of the shopper.
• Here too, an event whose consent was denied is blocked before dispatch.

Enhanced Conversions — off by default. In the store admin, under Marketing channels → Google → Settings, the merchant can turn on a switch named "Enhanced conversions". While it is off — the default in every store — no email address, phone number or name is sent to Google at all, neither from the server nor from the browser.

• When the switch is on, the order confirmation page — and only that page — attaches to the Google Ads conversion event the email address and first name only. No phone number, last name, address or postal code is ever sent to Google.
• The send is also conditional on the shopper's consent: a visitor who declined the cookie banner sends nothing — the values never leave the browser.
• The send happens from the shopper's browser through Google's gtag.js tag, which hashes the values with SHA-256 before they leave the browser. The plaintext value is never sent, and our server takes no part in this call.
• Its only purpose is to attribute a purchase to the ad that led to it when cookie-based attribution fails.
• The switch governs both halves together: while it is off, the allow_enhanced_conversions flag is not set on the tag configuration and the shopper details are not attached to the event.
• Here too — when tracking consent is denied, the tag is not granted permission to use the data for advertising.

Meta (Facebook and Instagram) — Conversions API. When a merchant connects a Meta account and selects a pixel, the store's commerce events are also sent server-side to Meta, alongside the pixel running in the browser. Both copies carry the same event identifier so that they are counted once. The call is authenticated with the merchant's OAuth token, so it stops when the account is disconnected.

• The events sent from the server are ViewContent, Search, AddToCart, InitiateCheckout, AddPaymentInfo, Lead and Purchase. PageView is sent from the browser only, by the pixel itself on page load — it has no server-side counterpart.
• Sent with every event: the event identifier, its time and the page URL where it occurred, the IP address and user agent, Meta's pixel cookies (_fbp, _fbc), item details (id, name, price, quantity), the value and currency, and for a purchase also the order number. And on a search event, the search text you typed, up to 200 characters, so the advertiser can see which searches lead to a sale. It is the only free-text value of yours in this payload, and it is sent as typed rather than hashed.
• Email address, phone number, first name, last name, city, zip code and country are sent only as SHA-256 hashes — the plain value never leaves the server. Hashing is the format Meta defines for audience matching, and it is one-way. We also send an opaque internal customer identifier from the store's own database (external_id), which is meaningless outside that store.
• When consent is denied, the event is blocked before dispatch and is not sent.

TikTok — Events API. When a merchant connects a TikTok account and selects a pixel, the store's commerce events are also sent server-side to TikTok, alongside the pixel running in the browser. Both copies carry the same event identifier so that they are counted once. The call is authenticated with the merchant's OAuth token, so it stops when the account is disconnected.

• The events sent from the server are ViewContent, Search, AddToCart, InitiateCheckout, AddPaymentInfo, SubmitForm and CompletePayment. Pageview is sent from the browser only, by the pixel itself on page load — it has no server-side counterpart.
• Sent with every event: the event identifier, its time and the page URL where it occurred, the IP address and user agent, TikTok's click identifier (ttclid) and its pixel cookie (_ttp), item details (id, name, price, quantity), the value and currency, and for a purchase also the order number. And on a search event, the search text you typed, up to 200 characters, so the advertiser can see which searches lead to a sale. It is the only free-text value of yours in this payload, and it is sent as typed rather than hashed.
• Email address and phone number are sent only as SHA-256 hashes — the plain value never leaves the server. Hashing is one-way, and the phone number is first normalised to the E.164 international format. We also send an opaque internal customer identifier from the store's own database (external_id), which is meaningless outside that store. Name, city, zip code and country are not sent to TikTok at all.
• When consent is denied, the event is blocked before dispatch and is not sent.

Product data is not shopper data. Separately from the above, and at the merchant's choice, the store's catalogue data — product title, description, images, price and availability — is sent to their own Merchant Center account and Meta catalogue. This is the merchant's business data rather than information about visitors, and it reaches the provider both through a public feed whose URL we register and through direct updates over the API. Catalogue updates contain no visitor or customer data at all.

And what is read back from the ad account. When a merchant connects an ad account, we read and store its performance metrics — spend, impressions, clicks, frequency, and the conversion count and conversion value Meta attributes (plus account-level ROAS), by day, by ad and by product — in order to show the merchant their own dashboard. We also read the list of item ids in their catalogue, so that a per-product report knows which product it is describing. These are advertising-account and catalogue metrics, and they contain no data about visitors or customers. At product level Meta reports no conversions or revenue at all, so there we never receive them; the revenue and profit figures on the per-product board are computed from the store's own orders.

And what is written back to the ad account. Where the permission is granted, the ads board lets the merchant do two things to an existing campaign in the account they selected: pause or resume it, and change its daily budget — a POST on the campaign id. Both run only when you press the button in the admin, never on their own, not on connect and not from any scheduled job, and each re-checks the permission against Meta rather than against a cache. We never create, duplicate, delete or archive a campaign, ad set, ad, creative or audience, and we change no other setting on the account. None of this carries any visitor or customer data.

And when Meta is disconnected, the platform asks Meta to revoke the permission itself. Disconnecting the channel sends a DELETE on the permissions of the user who connected the account, before the token is deleted on our side, and the grant is removed at Meta — that is, the app stops appearing as connected in your account. This is the only write we make to Meta that removes rather than adds, and it touches no campaign, catalogue, pixel or other asset. If Meta refuses the request, the disconnect on our side completes regardless, the screen tells you the permission was not revoked, and you can remove it by hand in your Meta account settings.

For this data the merchant is the controller, and their store's privacy policy is the one that applies.

14.Third-party AI agents the merchant connects (MCP)

A merchant can connect an external AI agent — Claude, or any other client that speaks MCP (Model Context Protocol) — to their store through the store's MCP server, which is served on the store's own domain. That client is a recipient of store data, and it is not one of our infrastructure providers: the merchant chooses it, the merchant grants it permissions on a consent screen (or creates an API key with permissions for it), and the model running it belongs to the vendor the merchant chose — not to us.

• What it can receive: only what the permissions the merchant granted allow — catalogue, inventory, orders, discount codes, sales and email summaries, and the store context — and only from that store's own database. One store's key does not exist in another store's database.
• Shopper information: by default a customer's name is reduced to initials, email and phone are masked, and the address is reduced to city and country. Full email, phone and address are exposed only when the merchant explicitly ticks the "customers' personal details" permission, and then every such read is written to the agent log — who read what, and when — which the merchant can see.
• What it never receives: Google, Meta or TikTok tokens; the email address of the connected Google account; or any data retrieved from Google APIs — Google Ads, Analytics, Merchant Center and Search Console figures are exposed to no tool of the MCP server. The section "What we do not do with the data" applies to such agents in full.
• The platform sends nothing to the client on its own: the client reads from the server with the key the merchant gave it. We keep no copy of what it received, and every destructive write (archiving products, cancelling an order, marking as paid, bulk repricing) requires the merchant's explicit confirmation on every call. The one exception is the order webhook the merchant themselves registered on a buyer-agent key — see "Buyer agents that shop on a customer's behalf" below.
• Control: the merchant can revoke a key or disconnect a client at any time under Settings → "API keys for agents"; a revoked token is refused from the next call, and every agent call is recorded as a run in the store's agent log.

How the external client uses the data — including whether it stores it or feeds it to a model — is governed by that client's own privacy policy, not by this one.

15.Buyer agents that shop on a customer's behalf (ACP)

A merchant can let a buyer-agent platform — a shopping assistant a customer talks to — order from their store directly, over ACP (the Agentic Commerce Protocol) and the store's public MCP server. Here too the merchant is the one who creates the key and its permissions; we connect no agent on our own initiative.

• An order can be created from outside the store's website. An agent the merchant authorised builds a checkout session and completes it, and the result is a real order in the store — the same order the site's own checkout creates, in the same transaction and the same numbering. The details the customer gave the agent — name, email, phone and shipping address — reach us from the agent and are stored on the session and on the order exactly as in any other order. No payment is taken at this point: the platform has no payment provider, the order is kept "awaiting payment" for the merchant to collect, and we neither receive nor store any payment instrument.
• What the agent sees of the store: active products only — title, description, images, price, and availability as a status (in stock / low / out of stock). The exact stock count and the merchant's cost price are never exposed. It sees no customers, no orders it did not create, and no other key's session.
• The session is time-limited: the customer's details live on the checkout session until the order completes or the session expires (six hours), and are then deleted by a periodic sweep.
• And hence the second statement — here, and only here, we send data out. If the merchant registered a webhook address on the key, we send an event to it when an order created through that agent is created or changes status. The address belongs to the merchant and to the platform they chose, not to us, and the data leaves the platform for it. Sent: the order id and session id, the status, the order lines and totals, and a link to the order page. Not sent: the customer's name, email, phone or address — the receiving platform already holds them. Every delivery is signed with a secret created alongside the key so the receiver can verify it really came from us, and the address goes through the same SSRF guard every outbound fetch goes through. A merchant who registered no address gets nothing sent.

16.Infrastructure providers

The platform relies on the following providers, each receiving only what its role requires:

• Vercel — running the application and serving traffic.
• Neon — databases; a separate database per store.
• Cloudflare R2 — storage for stores' media files.
• Anthropic — store content translation and the design assistant. Receives no Google data whatsoever.
• OpenAI — image generation and image editing (background removal, generated backdrops and lifestyle shots). Receives the description, and for an edit also the image you selected from the store's media storage. Receives no Google data whatsoever and no shopper information.
• Resend — sending email.
• Google — the services the merchant chose to connect.
• Meta — Facebook and Instagram, when the merchant chose to connect them.
• TikTok — advertising and measurement, when the merchant chose to connect them.

17.Security

• Tokens are encrypted at rest (AES-256-GCM).
• All traffic is encrypted in transit with TLS.
• A separate database per store, so one store cannot reach another store's data.
• Session cookies are signed with HMAC-SHA256.
• Rate limiting on sign-in routes and public endpoints.

We hold no security certifications and make no such claim. No system is completely secure.

18.Your rights

Under the Israeli Protection of Privacy Law, 5741-1981, you have the right to review the information we hold about you, to request its correction and to request its deletion. Contact details are at the end of this document.

19.Children

The platform is a business service, is not directed at anyone under 18, and we do not knowingly collect information from them.

20.Changes to this policy

We will update this document from time to time; the last-updated date appears at the top. We will notify the account's registered email address of any material change.

21.Contact

Infinity AI Solutions · noam.salomon@gmail.com · infinity-ai-solutions.com