Privacy Policy · CARTT.AI

This Privacy Policy explains how CARTT.AI (ABN 71 393 051 974) of Byron Bay, New South Wales, Australia ("CARTT.AI", "we", "us", "our") collects, uses, discloses, and protects your personal information.

1. Introduction

CARTT.AI is bound by the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs). This Privacy Policy is designed to comply with our obligations under those laws.

This policy applies to:

Visitors to cartt.ai and our marketing website
Subscribers (the businesses that have signed up for our platform)
Authorised users of Subscriber accounts (employees, contractors)
Prospects who have provided contact details for sales or marketing purposes
End Customers — the shoppers who buy from a storefront a Subscriber operates on our Service — to the extent we hold their personal information, as sections 3.7 and 9 describe

Personal information that a Subscriber collects about its own End Customers through a storefront it operates on our Service is governed in the first instance by that Subscriber's own privacy policy, which you should read on their storefront — the Subscriber decides what is collected, why, and how it is used. But we hold that information on our infrastructure, and under the Privacy Act 1988 an entity that holds personal information has obligations of its own regardless of whose behalf it holds it for. Section 9 therefore sets out what we do with End Customer information and what you can ask of us directly.

2. Who we are and how to contact us

Entity: CARTT.AI (ABN 71 393 051 974)
Location: Byron Bay, New South Wales, Australia
Privacy contact: legal@cartt.ai

If you would prefer to write to us by post, email legal@cartt.ai and we will provide a postal address for your enquiry.

3. What personal information we collect

We collect personal information in the following categories.

3.1 Account and identity information

When you sign up or are added as an authorised user of a Subscriber account, we collect:

Full name
Business name and ACN/ABN (if you are signing up on behalf of a business)
Email address
Phone number
Postal address
Date of account creation
Username and authentication credentials (passwords are stored in hashed form only)

3.2 Billing and payment information

We collect:

Billing name and address
Tax registration details (ABN where applicable)
The last four digits and expiry date of your payment card (we do not store full card numbers — these are held by our payment gateway provider)
Invoice history
Refund and chargeback history

3.3 Usage information

When you use the Service, we automatically collect:

IP address
Device and browser information (user agent string)
Referring page
Pages visited within the admin panel
Actions taken (which features used, which buttons clicked)
Timestamps of access
Error logs

3.4 Communications

When you contact us (support tickets, sales enquiries, email correspondence), we collect:

The contents of your communication
Any attachments you provide
Metadata about the communication (date, time, channel)

3.5 Information from third parties

We may receive information about you from:

Payment gateway providers (transaction status, fraud indicators)
Identity verification services (where used for high-value account verification)
Analytics providers (aggregated traffic patterns)
Public sources (for example ABN lookups against the Australian Business Register)
Social sign-in providers. Where a shopper chooses to sign in to a store with Google or Facebook instead of setting a password, that provider sends us a profile in exchange for the shopper's consent. We keep the account identifier the provider issues, the email address on the account and, where one is supplied, the name, and use them to create or match the customer record and for nothing else. One further field is kept in a narrow form: where Google tells us the email address on the account has been verified, we record the customer's email as verified so the shopper is not asked to confirm an address their provider has already confirmed. Facebook does not tell us, so a Facebook sign-in is treated as unverified. We never receive the password. We should be plain that the profile the provider sends is wider than the part we keep: Google's includes the profile picture and any nickname, and Facebook's also includes gender, whether the account is verified, a link to the profile and the profile picture. Those fields arrive with the response and are discarded rather than stored. The provider necessarily learns that the shopper signed in to that store, and the exchange happens on the provider's own infrastructure, which is overseas for both.
Social and advertising platforms a Subscriber connects. Where a Subscriber links their store's Facebook, Instagram, TikTok, X or LinkedIn account so they can publish or advertise from the admin, we receive the account or page identifier, the page name, the page's profile picture, the permissions granted, and the access token that lets us act on their behalf until they disconnect it. Where those platforms report on advertising, we also receive the performance figures they attribute to the Subscriber's campaigns.

3.6 Cookies and similar technologies

Our website and admin panel use cookies and similar technologies to:

Keep you signed in across sessions
Remember your preferences
Measure how the Service and our own websites are used. Some of this is aggregate reporting, but not all of it: our first-party analytics records individual events — pages viewed, links clicked, how far down a page you scrolled — against a visitor session, together with the IP address, browser and device the request came from and any campaign parameters in the link you arrived by. We use no third-party advertising or analytics trackers on our own websites, but we would rather not describe our own measurement as merely aggregate when it is event-level
Attribute a sale to the advertising that produced it. Where a visitor arrives by a link carrying a Google or Meta click identifier or utm_ campaign tags, our platform stores those parameters in an encrypted, server-readable-only cookie for 30 days, on our own site and on Subscriber storefronts alike; if an order follows within that window, the parameters are copied onto the order record so the merchant can see which campaign produced the sale. It captures those link parameters and the time it captured them, and nothing further — no name, no contact details, no record of what was browsed. That describes the cookie's contents rather than their destination, and the distinction matters: once the parameters are written onto an order they sit beside the name and address of an identified customer, and an advertising identifier attached to a named order is personal information in that context even though it identifies nobody on its own. Two things about who sees it. It is not sent back to Google, Meta or any other advertising provider — nothing leaves our servers. But the merchant does see it, because attribution is the entire point: once it is written onto the order, it is part of that merchant's own order record and is visible to their staff like any other order detail. This is the one cookie we set whose purpose is marketing rather than function, which is why it is named here rather than folded into the line above
Detect security threats. One part of that is not ours: the enquiry forms on our marketing site, and storefront forms where a Subscriber has enabled it, run Google reCAPTCHA Enterprise, which loads a script from Google and sends Google information about the device and the browsing session so that the request can be scored for whether it is automated. That is a disclosure to Google in the United States — section 7.1 names it — and it happens on page load, not only when you press submit

Our Cookie Notice describes the cookies set by the cartt.ai marketing site. The CARTT.AI admin panel and merchant storefronts also set cookies and use similar browser storage for functional purposes — keeping you signed in, remembering a sign-in between sessions where you asked us to, remembering a trusted device so it can skip the second factor, holding your consent choices, retaining cart contents, remembering whether an administrator wants the front-end toolbar shown, and varying cached pages. The Cookie Notice names the admin-panel ones individually, including the cross-site request forgery token and a developer diagnostic that only a verified platform super-administrator can activate. If you want a full inventory for a specific site, ask us at legal@cartt.ai.

3.7 End Customer information we hold for a Subscriber

Everything above concerns information about you as a Subscriber, authorised user or prospect. We separately hold personal information about the End Customers of the storefronts our Subscribers run, because those storefronts run on our infrastructure. The Subscriber decides what its storefront collects and why; we set out here what we hold, so that the disclosure does not depend on reading their policy. Depending on which features the Subscriber has switched on, that information can include:

Identity and contact details — name, email address, phone number, and the shipping and billing addresses given at checkout or in a customer account
Account credentials — where the storefront offers customer accounts, a username and the credential for that account. Passwords set on this platform are stored as a one-way hash. Where a Subscriber migrated an existing customer base onto the Service from an older system, the credentials imported with it are held in the form that system used until that customer next signs in, at which point the credential is replaced with a modern one-way hash
Order and transaction records — what was bought, when, at what price, the delivery and fulfilment status, tracking details, returns and refunds, and the card metadata described in section 7.4 of the Subscription Terms of Service — what we keep is the gateway's token for the card plus its brand, last four digits, expiry and cardholder name, never the full number
Wholesale and trade details — business name, ABN, assigned customer group and credit terms, where the storefront sells B2B
Communications — enquiry and contact-form messages, product reviews and questions, support conversations, and the transcripts of chatbot conversations
Marketing information — subscription and unsubscribe status for email and SMS lists, consent records, and campaign engagement such as opens and clicks
Behavioural and device information — pages and products viewed, cart and abandoned-cart contents, search terms, IP address, user agent, and the cookies and similar storage set by the storefront
Loyalty and rewards information — points balances, vouchers and referral records, where those features are enabled

There is one path where a full card number does reach us, and the shopper on the other end of it has no way of knowing that, so we would rather say it here than leave it to the fine print of someone else's document. If a shopper gives their card details to a Subscriber's staff over the phone and those staff key them into the admin panel — a MOTO order — the card number and security code are submitted to our servers and passed straight to the Subscriber's own payment gateway inside that same request. We hold them for the life of that request and no longer: they are not written to any database field, and the gateway's error messages are scrubbed of them before they reach a log file or an admin screen. It is a collection all the same, which is why it is named here rather than left out on the ground that nothing was kept. The path exists only for staff-entered phone orders, only where the Subscriber's gateway supports charging a card that way, and it is the Subscriber — not us — who decides to take orders over the phone at all. Everywhere else, including every checkout on a storefront, the card number is never readable by us — though on one gateway it is not quite true to say it never passes through us either, and the distinction belongs here rather than in a footnote. Where a Subscriber uses eWAY for on-site card payment, the shopper's browser encrypts the card number and security code with eWAY's own public key before the form is submitted, and that ciphertext travels through our servers on its way to eWAY. We hold no private key for it and cannot read it, but it does pass through, and "never passes through us" would be the wrong sentence for that path. On every other on-site gateway the card either goes to the gateway's own hosted page or is exchanged for a token in the shopper's browser, and does not reach us in any form.

We collect it in the ways described in section 4, and we use it only for the purposes in section 5 — which for End Customer information means running the storefront as the Subscriber has configured it, plus the narrow set of things we must do in our own right to keep the Service secure, working and lawful. Section 9 sets out the division of responsibility between the Subscriber and us, and how an End Customer can make a request directly to us.

3.8 Accounting and banking records a Subscriber puts into the Service

Where a Subscriber uses the accounting, expense or bank-reconciliation features, we hold the financial records it imports into them. Much of that is company data rather than personal information — but not all of it, because a bank statement names the people and businesses an account paid, and a receipt names who spent the money. This is a different category from the card metadata in section 3.2 and from the End Customer commerce records in section 3.7, so we name it separately:

Bank account information — the account name and identifying digits as they appear on the statement, its currency, and the opening and statement balances with their dates. We hold no banking credentials and have no access to any bank account (see below)
Bank transaction records — for each line: the date, the amount, the statement narrative, the counterparty read out of that narrative, the balance after the transaction, and the match, GST treatment, category and confidence the reconciliation assigns — including where a line is classified as an owner's personal expense or drawing
Payer and supplier identities — the counterparty names the reconciliation learns, and the aliases that map a bank narrative to a customer or supplier record
Receipts and expense documents — the images or PDFs uploaded, and the supplier, date, amount and GST read out of them

It is imported, not connected. A Subscriber uploads a CSV or PDF statement, or connects a reporting source such as PayPal, and we hold the result. We do not have bank feed access, we never ask for internet-banking credentials, and nothing here lets us move money.

Parts of it can be read by AI, and only if the Subscriber asks for that. Where a bank issues PDF statements but no usable CSV, a Subscriber can have the pages read by Anthropic's Claude (United States) — which means the whole rendered statement page, every transaction and every name on it, is sent overseas for that request. The same applies to a receipt image put through automatic capture, and to the transaction narratives sent for automatic categorisation. None of those run on their own: each is a button a person presses, the deterministic matching that runs after an import sends nothing to any AI provider, and a Subscriber that would rather no financial record left Australia can import CSV statements and categorise them by hand. Section 7.1 sets out the overseas position, subject to the note at the end of it.

4. How we collect your personal information

We collect personal information:

Directly from you, when you sign up, configure your account, contact us, or use the Service
Automatically, when you access the Service (usage information)
From third parties, as described in section 3.5
From Subscribers, when a Subscriber adds you as an authorised user of their account

We collect the End Customer information described in section 3.7:

Directly from the End Customer, when they place an order, create a customer account, join a marketing list, submit a review or enquiry, or use a storefront chatbot
Automatically, when they browse a storefront — the behavioural, device and cookie information in section 3.7
From the Subscriber, where they import an existing customer list, migrate records from a previous system, or key an order in on a customer's behalf
From a connected third party, where the Subscriber has connected one — a marketplace passing buyer and delivery details through with an order, a point-of-sale system passing an in-store sale through, or a payment gateway returning a transaction result

Where it is reasonable and practicable, we collect personal information from the individual directly.

5. Why we collect your personal information

We collect, hold, use, and disclose personal information for the following purposes, using the categories of information shown:

To provide the Service to you — account, identity, usage
To process payments and issue invoices — billing and payment
To provide customer support — account, communications
To send service notifications (billing, security, outages) — account
To send product updates and marketing emails, where you have opted in or where permitted by law — account
To detect and prevent fraud, abuse, and security threats — usage, IP address, account
To comply with our legal obligations (tax, regulatory, court orders) — all categories as relevant
To improve and develop the Service — aggregated, de-identified usage
To enforce the Subscription Terms of Service and protect our rights — all categories as relevant
To run the accounting features a Subscriber has chosen to use — matching bank lines to invoices, bills and expenses, categorising them, assigning GST treatment and producing that Subscriber's own financial reports — accounting and banking records (section 3.8). This is bookkeeping we do for the Subscriber on its instruction; we make no other use of those records, and we do not use them to train AI models

We will not use your personal information for any other purpose without your consent or where permitted by law.

End Customer information is narrower. We collect, hold, use and disclose the information described in section 3.7 for these purposes only:

To operate the storefront the Subscriber has configured — taking and fulfilling orders, running customer accounts, calculating freight and tax, and processing payments, refunds and returns
To carry out the Subscriber's instructions — sending the transactional and marketing messages they have configured, running the features they have enabled, and exchanging data with the integrations they have connected, as described in sections 6 and 7.1
To keep the Service secure and available — fraud and abuse prevention, spam filtering, diagnosing faults, and backups
To comply with our legal obligations and to respond to a request an End Customer makes to us under section 9

The last two purposes are ours rather than the Subscriber's, and we would rather name them than let the word "only" do work it cannot do: keeping the Service secure and lawful is something we must do in our own right, whatever a Subscriber instructs, and it necessarily involves End Customer information — an abusive checkout attempt or a fault in an order cannot be investigated without looking at the order.

Outside those purposes, we make no independent commercial use of End Customer personal information. We do not sell or rent it, do not market to End Customers on our own account, do not build profiles of individuals for our own purposes, do not combine one Subscriber's customer data with another's, and do not use it to train AI models. Where we use data to improve the Service, we use it in aggregated or de-identified form.

6. Disclosure of personal information

We disclose personal information only as set out below.

6.1 Service providers (data processors)

We share personal information with carefully selected service providers who help us operate the Service. We require them to handle your information in accordance with this policy and applicable law. Categories include:

Cloud infrastructure — hosting providers (located in Australia)
Payment gateway providers — for processing your subscription payments
Email infrastructure providers — for sending transactional and marketing emails
AI providers — for generating content (descriptions, images, recommendations) where you use AI features; see section 7.4 for details
Email verification services — for checking whether an address on a marketing list is deliverable, which requires sending that address to the verification provider
SMS gateways — for sending the transactional and marketing messages a Subscriber has configured
Accounting, inventory, point-of-sale and shipping systems — where a Subscriber has connected one, so that customers, orders, invoices, stock and consignments stay in step between the Service and that system. Contact and delivery details necessarily go with the order
Marketplaces and other selling channels — where a Subscriber sells through one, buyer and order information is exchanged in both directions
Dropship suppliers — where a Subscriber sells a dropshipped product, the customer's delivery details are passed to the supplier so that the supplier can ship directly to them
Messaging channels — where a Subscriber enables messaging or verification over a channel such as WhatsApp, or routes support alerts to a chat service, the message and the destination identifier go to that provider
Mapping and address lookup — where an order confirmation shows the delivery destination on a map, or where a Subscriber's store or listing address is converted to map coordinates, that address is sent to the mapping provider; and the background imagery of any map is fetched by the viewer's own browser from the tile provider named in section 7.1, which receives that browser's IP address and the area being viewed
Analytics and advertising services — for measuring Service usage. A Subscriber can also add its own analytics or advertising tags to its storefront (for example Google Analytics, Google Tag Manager or the Meta pixel), which sends storefront browsing information to that provider. Those tags are the Subscriber's choice and are covered by the consent banner and cookie disclosures on their storefront
Customer support tools — for managing support tickets
Identity and fraud-prevention services — for security

Section 7.1 names the providers in these categories that process information outside Australia, together with the country each is likely to process in. The list is not exhaustive of every provider we may use — it names the ones that matter for the question of where information goes — and we will provide the current full list of named third-party processors on request to legal@cartt.ai.

6.2 Disclosures required or permitted by law

We may disclose personal information when:

Required by law, regulation, court order, or government request
Necessary to prevent or investigate fraud, security incidents, or breaches of the Subscription Terms of Service
Necessary to protect our rights, property, or safety, or the rights, property, or safety of others
In connection with a merger, acquisition, or sale of our business (subject to appropriate confidentiality safeguards)

6.3 Social and advertising platforms a Subscriber has connected

Where a Subscriber connects a social or advertising account so they can publish or advertise from the admin, we send that platform what they have asked us to send. This is a disclosure the Subscriber directs and we perform, and it is worth naming separately because the flow runs outward rather than inward:

Published content. The caption, the images or video, and any link in a post are transmitted to the platform it is being published to — Facebook or Instagram (Meta), X, TikTok or LinkedIn. If a Subscriber writes a person's name, a customer's words or a photograph of an identifiable person into a post, that goes with it, and once published it is on that platform under that platform's terms, not ours.
Advertising instructions and audiences. Where a Subscriber runs ads through a connected account, the campaign settings, budgets and targeting they choose are sent to the platform, and the performance figures it attributes to those campaigns come back.
The connection itself. The access token the platform issued, and the account or page it belongs to, are used on every such call so the platform knows whose account is acting.

All of these platforms are overseas — Meta, X and LinkedIn process in the United States, and TikTok's parent, ByteDance, is Chinese-owned with processing that may occur outside Australia and outside the United States. A Subscriber who does not connect an account makes none of these disclosures. Section 7.1 lists these among the overseas recipients.

6.4 Aggregated or de-identified information

We may share aggregated or de-identified information (which cannot reasonably be used to identify you) for any purpose, including industry research and marketing.

6.5 With your consent

We will disclose personal information for any other purpose with your consent.

7. Storage, location, and security

7.1 Where your information is held

Your personal information is stored on infrastructure located in Australia, including our databases, file storage and backups. We do not move your stored records offshore.

Some information is nonetheless sent overseas to be processed. Storage and processing are different things, and we would rather be plain about the difference than let "hosted in Australia" imply more than it means:

AI features. When you or your customers use an AI feature, the input for that request — which may include product data, uploaded images, page content, or the text of a customer conversation — is transmitted to the AI provider that serves the model, and those providers operate globally. The providers currently used, and the countries in which each is likely to process the request, are OpenAI (United States), Anthropic (United States), Google (United States), Black Forest Labs (Germany and the United States), fal.ai (United States), ElevenLabs (United States — voice narration), Sapling (United States — receives generated text so that it can be scored for how machine-written it reads, before that text is saved or shown to you), Stability AI (United Kingdom and the United States — image editing), Runway (United States — image-to-video) and three video models developed in China: Kling (Kuaishou), Seedance (ByteDance) and Hailuo (MiniMax). We call those three out because they are the models in this list whose owners sit outside the United States and Europe. How a request reaches them depends on which tool you used, and the distinction is worth stating rather than smoothing over: Video Studio reaches all three through fal.ai, and where fal serves a request from the model owner's own infrastructure the source image and the prompt you wrote are processed in China; the Social Video generator, where Kling is offered as one of two choices, posts the source image and the prompt directly to Kling's own API, so on that path they go to Kuaishou in China without an intermediary. A merchant chooses which video model to use, and the choice is shown in the admin. A provider may process in another country in which it operates. This list changes as providers do; section 7.4 explains how to obtain the current one. Section 7 of the AI Content Disclaimer sets out what we have contracted for with them and what we have not.
Payment processors. Where a Subscriber has connected Stripe or PayPal, payment data is processed in the United States and, for Stripe, may also be processed in Ireland. eWAY, Fat Zebra and SecurePay are Australian gateways and process here. The two buy-now-pay-later methods do not belong in that group, and we would rather separate them out than let one word carry them: when a shopper chooses Afterpay or Zip at checkout, we send that provider the shopper's name, email address and phone number along with the order reference and amount, and each sits in a corporate group that extends beyond Australia — Afterpay is owned by Block, Inc., a United States company, and Zip operates through overseas group companies and service providers. Where each of them then processes that information is governed by its own privacy policy rather than ours: Afterpay's and Zip's. If the answer matters to you, read them before you enable the method. We add and retire gateways over time, so treat this as the current position rather than a closed list, and ask us if the location of a specific gateway matters to you.
SMS gateways. Where a Subscriber has connected Twilio (United States) or Vonage (United Kingdom and United States), message content and recipient numbers are processed there. MessageMedia and Kudosity process in Australia.
Email address verification. Where a Subscriber uses list verification, the email addresses being checked are sent to Bouncify (United States).
Marketplaces and other selling channels. Where a Subscriber has connected eBay or Amazon, buyer and order information is exchanged with those platforms in the United States. Where they have connected Shopify, customer and order records are exchanged with it in Canada and the United States.
Dropship suppliers. Where a Subscriber sells a dropshipped product through our AliExpress integration, the order is placed with the supplier through AliExpress, which means the End Customer's name, delivery address and contact details are sent to AliExpress (Alibaba Group) and processed in Singapore and China. This only happens for orders containing a dropshipped line.
Messaging channels. Where a Subscriber enables WhatsApp for verification codes or messaging, the recipient's phone number and the message go to Meta (United States). Where support or alert notifications are routed to Telegram, the notification content and the destination chat identifier go to Telegram (which operates from the United Arab Emirates and other jurisdictions).
Accounting, inventory, point-of-sale and shipping integrations. These are connected by the Subscriber, and the customer, order, invoice and delivery information needed for the integration to work is sent to the provider they choose. Of those we currently support, QuickBooks Online (Intuit) and Lightspeed Retail process in the United States; MYOB, Retail Express, Datapel and Shippit are Australian; Xero, Cin7 Core, Unleashed and Starshipit are New Zealand providers that may process in New Zealand, Australia or the United States. We state each position as the provider publishes it, and a provider can change its own hosting without telling us. If the processing location matters to you for a particular integration, ask us at legal@cartt.ai before you connect it and we will confirm the current position in writing.
Mapping and address lookup. Two paths send an address to Google (United States). Where a storefront shows the delivery destination on a map on the order-confirmation page, the End Customer's delivery address is sent to the Google Maps API from their own browser so the map can be centred on it. And where a Subscriber lists store locations, each location address is sent to Google's geocoding API from our servers to obtain its coordinates. Neither path sends payment details or order contents. The map those coordinates are drawn on comes from somewhere else again, and it belongs here rather than in a footnote about pictures. The background imagery for the store locator on a storefront, and for the activity map on the admin dashboard, is fetched tile by tile from CARTO (United States) by the browser that displays the map. Those requests carry that browser's IP address and the usual request metadata, together with the coordinates of the tiles being asked for — which is to say, the area of the world the map is showing. Where a visitor uses find my nearest store, their device's position is read by their own browser and stays there: the distances are worked out on the visitor's own machine, and the position is not sent to us or to CARTO as a location. What the map then does is recentre on it, so the tiles it goes on to request describe roughly where the visitor is. We would rather set that out than let "the map" sound like a picture we serve ourselves.
Storefront analytics and advertising tags. Where a Subscriber adds a Google Analytics, Google Tag Manager or Meta pixel tag to its storefront, the browsing information those tags collect goes to Google or Meta in the United States. This is a disclosure the Subscriber has chosen to make from their storefront rather than one we make, but it happens through our systems, so we name it here.
Bot protection on forms. Our marketing enquiry forms, and storefront forms where a Subscriber has enabled it, run Google reCAPTCHA Enterprise. Google's script loads with the page and sends Google (United States) information about the device and the browsing session — not the contents of the form — so that the request can be scored for whether it is automated. Google's handling of that data is governed by its own privacy policy and terms of service. When a form is submitted we make a second call to Google, from our own servers rather than the visitor's browser, to read the score; that call carries only the token Google's script issued, and nothing the person typed. It is a small disclosure, but it is one that happens to every visitor of a page carrying a protected form rather than only to people who submit one, which is why we name it rather than leaving it inside "security".
Social and advertising platforms a Subscriber has connected. Publishing a post or running an ad sends its content and settings to the platform concerned, as section 6.3 sets out. Meta (Facebook and Instagram), X and LinkedIn process in the United States; TikTok's parent ByteDance is Chinese-owned and its processing may occur outside Australia and outside the United States. Sign-in providers sit on the same footing: a shopper who signs in with Google or Facebook authenticates on that provider's own infrastructure in the United States, and the provider necessarily learns they signed in to that store.
Web fonts on our own marketing site. The pages at cartt.ai load their two typefaces from Google Fonts (United States). No script and no cookie is involved, but fetching a file is still a request to Google, and it carries what any request carries: the visitor's IP address, their browser and operating system, and the fact that the request came from cartt.ai. It does not carry which page of cartt.ai they were reading — we send a Referrer-Policy of strict-origin-when-cross-origin on every response, so a request leaving our site for another domain discloses our domain and not the address of the page. It applies to every page of cartt.ai, including this one. We would rather name it than let a reader assume our own site talks to nobody. It does not apply to Subscriber storefronts, whose templates serve their fonts from the store's own domain.
Script and asset hosts in the admin panel. The admin panel loads some of its assets from public networks rather than from our own servers, and this is a good deal more than charting on a few reporting screens, so they are named individually below rather than summarised. jsDelivr is the largest of them, because it serves the JavaScript framework the admin panel is built on — which means every admin page fetches from it, not merely the reporting ones — along with the charting library on the dashboard and the CRM, SEO and forecasting reports, the guided-tour library, the chart on a campaign's report, and the text renderer in the infographic studio. It is operated from the United Kingdom. Google Fonts serves the admin panel's typefaces on every page, and the theme, changelog and email editors load a further set so a template or campaign can be previewed in the typeface it will be sent in. Google's asset host serves the chart loader used by one panel on the dashboard. CDNJS, operated by Cloudflare, serves the layout library on the product listing screen. UNPKG serves the surface image for the globe on the dashboard's activity map, which loads only if that view is opened. And placehold.co supplies the stand-in product images in the previews of transactional email templates — so where a Subscriber sends themselves a test of one of those templates, the images in it are fetched from there when the test is opened — and the same stand-in is the starting image in a page-builder section until it is replaced. Three more load only on the screen that needs them, and only where the relevant connection is configured. Stripe's payment script and PayPal's JavaScript software development kit load on the Wallet top-up page, and Stripe's also on an agency's billing page, so that the card and PayPal fields can be rendered by the gateway rather than by us; what those fields then send to the gateway is the payment-processor arrangement described above, but the loading of the script itself is a request to Stripe or PayPal that happens as soon as the page opens, whether or not a payment follows. Google Maps serves the map on a customer's record in the CRM, together with the marker icons drawn on it. Google, Cloudflare, Stripe and PayPal are United States companies; the rest operate outside Australia. One qualification applies to all of them: an asset network answers from whichever of its edge locations is nearest the browser, so the request itself may not leave the country, but the operator receives it either way. As with fonts, no personal information is deliberately sent, but fetching a file is still a request, and it carries the IP address, browser and operating system of the staff member whose browser makes it, together with the domain their admin panel is served from — but not, for the reason given in the fonts entry above, the address of the particular admin page they were on. This is a Subscriber-staff exposure rather than a shopper one, with the single exception noted above: the stand-in image left unreplaced in a page-builder section would be fetched by whoever views that page, and the same is true of anyone who opens a test email containing one. We consider serving these files from our own domain the better arrangement and intend to move to it; until then we would rather name the recipients than describe our admin as self-contained.
Operational access. Some service providers may access information from outside Australia for limited operational purposes, such as support staff.
Email delivery involves more than one country, and the word "delivery" hides most of them, so they are set out here. We submit mail through Amazon SES, and which country that happens in is a Subscriber's own configuration rather than a fixed property of the platform. A Subscriber connects their own SES account and picks the region it sends from; we offer twelve, and the default is ap-southeast-2 (Sydney). The rest are Singapore, Tokyo, Mumbai, Ireland, London, Frankfurt, Canada, São Paulo and four in the United States. Whatever a Subscriber chooses is where their mail is submitted and processed — transactional mail and marketing campaigns alike, since campaigns use the same connection — and some stores on this platform are on a United States region today. If you deal with a particular store and want to know where its mail is submitted, that store can tell you, and section 9 explains why the answer is theirs to give rather than ours. Three qualifications follow. First, the layout of an email is rendered by the MJML API, operated by Mailjet (part of the Sinch group) and processing in the European Union: we send that service the message markup and it returns the finished HTML. What is in that markup depends on how the email was built, and the difference matters enough to set out. An email built from a stored template — an order confirmation, a shipping or delivery notice, an invoice, an abandoned-cart reminder, a marketing campaign — travels as a template: the recipient's name, the order lines and the totals are merge fields our own servers fill in after the layout comes back, so those details never reach Mailjet. An email composed as a one-off message has no such separation: an enquiry acknowledgement and the store's copy of that enquiry, a support ticket notification, and a message an operator writes and sends from the admin all have their real wording — the names on it, the subject, the text of what was written — built into the markup before it is sent, so for those Mailjet receives the content. It renders and returns markup rather than sending anything, but it is an overseas recipient of that content and belongs on this list. Second, a message is then delivered to the recipient's own mailbox provider, which is wherever that provider is — email addressed to an overseas mailbox necessarily leaves Australia, and no sender can change that. Third, a Subscriber can point their store's transactional email at their own SMTP relay instead of SES, in which case the message is submitted wherever that relay is; that is their configuration choice, and only they can tell you where it sits.

This list is maintained rather than exhaustive. It names the recipients that matter for the question of where personal information goes, and we update it as we add and retire integrations. If you want the position for a provider not named here, or want to be certain of the current position before you switch a feature on, ask us at legal@cartt.ai and we will tell you in writing.

Where we disclose personal information to an overseas recipient, we take reasonable steps to ensure they handle it consistently with the Australian Privacy Principles, including through contractual commitments where the provider offers them. We cannot, however, guarantee that an overseas recipient will handle your information in a way that satisfies the APPs, and by using AI features you accept that the input for those requests is processed overseas. If you do not want the input to an AI request leaving Australia, do not use the AI features; contact legal@cartt.ai and we can discuss disabling them for your account. We would rather not let that offer imply more than it delivers. Switching the AI features off stops the AI disclosures described above and nothing else: the payment gateway you connect, the SMS gateway you select, the marketplaces, carriers, accounting and inventory systems you integrate, the bot protection on your enquiry forms, the service that renders your email layouts, and the asset hosts that serve this platform's typefaces and admin charts all sit overseas as well, and they are listed above precisely because they keep operating whether or not a single AI feature is enabled. There is no one switch that keeps everything onshore, and we would rather say so than offer you one that does not exist.

7.2 How long we keep your information

We retain personal information only for as long as needed to fulfil the purposes for which it was collected, or as required by law. The periods below are the retention targets we work to — the point from which we consider the information no longer needed, so that you can require us to delete it.

They are targets, not automatic expiry timers, and we would rather say so than imply a machine is enforcing them. Some categories are pruned automatically on a schedule; others are reviewed and cleared periodically by a person, which means information in those categories can persist past the mark below. What the periods do give you is a firm entitlement: once a period has passed, you can ask us to delete that information under section 8 and we will do it, without needing to give a reason. A request is the reliable route, and it is actioned when you make it rather than waiting for a cycle.

Active account information — for the life of your subscription
Billing and tax records — 7 years after the transaction. Australian tax law generally requires records to be kept for 5 years from when they are prepared, obtained or the transaction is completed, with longer periods in particular cases; we keep 7 years as our own margin over that, so treat the 7 years as our policy and the 5 years as the statutory floor
Support communications — 3 years after the matter is closed
Sales and marketing enquiries — 24 months from your last contact with us. These are cleared on review rather than by a scheduled job, so a record can outlive the mark; a deletion request under section 8 is the reliable route
Analytics and usage logs — 24 months in identifiable form, after which we aggregate or delete them on review
Marketing preferences — until you opt out, then retained as a suppression-list record
Backups — our backup rotation is designed to age copies out within 35 days

When you cancel your account, we retain your data for at least 30 days so that you can export it. After that period it becomes eligible for deletion and is removed from our active systems. Deletion of a cancelled account is a reviewed step rather than an automatic one, because it is irreversible and we would rather be slow than delete a merchant's store by mistake — so it may happen some time after the 30 days rather than exactly on the day. If you want your data deleted promptly at the end of the export period, tell us at legal@cartt.ai and we will action it. Once active-system deletion is done, the backup rotation is designed to age the remaining copies out within 35 days, on the same basis as the backup entry above.

7.3 Security measures

We take reasonable steps to protect your personal information from misuse, interference, loss, and unauthorised access, modification, or disclosure. These measures include:

Encryption of data in transit (TLS 1.2 or above) on every connection we control — our websites, admin panel, storefronts and API. One narrow set of addresses is treated differently, and it is worth naming rather than absorbing into the word "every": paths beginning /.well-known/, which exist so that certificate issuance and renewal, and the domain-association files payment and platform providers fetch to confirm we control a domain, can be validated before or without a certificate. On our own platform hosts those paths answer over plain HTTP by design; on Subscriber storefronts it depends on how that site's web server was configured, and both arrangements are in use across the estate. What is true of all of them is that nothing personal is served from those addresses — they hold validation tokens, domain-association files and our security contact details
Encryption at rest of the third-party credentials a Subscriber stores against an integration connection, subject to the qualification set out below
Hashed (one-way) storage of passwords using industry-standard algorithms
Access controls limiting employee access to personal information to those who need it
Regular security reviews and updates
Incident response procedures
Backup and disaster recovery procedures

Two qualifications are worth stating plainly rather than leaving inside a general claim. The first concerns email in transit: if a Subscriber points their transactional email at their own SMTP relay, the security of that hop depends on what the relay supports. Our default is an encrypted connection, but a relay that offers no encryption can be selected, and some relays present certificates we cannot verify.

The second concerns which stored credentials are encrypted, and the honest answer is that it depends on the field rather than on the screen it was typed into. Five groups are encrypted at rest. The first is the credentials a Subscriber stores against a dedicated integration connection — marketplaces, shipping and freight carriers, point-of-sale terminals, EDI, the accounting and inventory systems a Subscriber connects, search and advertising accounts, video providers. The second is the payment-gateway fields our gateway definitions mark as secret: the eWAY password, the Fat Zebra token and shared secret, the PayPal client secret, and the Afterpay and Zip API keys and webhook secrets, in both live and sandbox form. Those are encrypted as they are saved and decrypted only when a payment or a webhook check needs them. The third is a set of individual settings encrypted one field at a time as their integrations were built: the Datapel password, and the MYOB client secret, cloud and local passwords, and OAuth access and refresh tokens. The fourth is a small set of credentials that live against a record rather than on a settings screen, and are easy to overlook for exactly that reason: an agency's own SMTP password under the white-label programme, the payment configuration stored against a Wallet, and the PayPal reporting client secret held against a connected bank account. The fifth belongs to the setup wizard, and has two halves. While the wizard is still running, the credentials typed into it — a Stripe secret key, a PayPal secret, a SecurePay password, a REX API key, an MYOB password, an SMTP password and a freight carrier API key — are held encrypted in the wizard's own working store, and that store is emptied once provisioning has consumed them, so that half is temporary by design. Two qualifications belong with that rather than in a footnote. The emptying happens when provisioning completes, so a run that is abandoned part-way through leaves what was typed sitting in the working store until the wizard is finished or the account is torn down. And the encryption was added to that store after it was first built, so a value written before that change is read back in the form it was stored rather than failing — no row of that vintage exists on the platform today, but the fallback is in the code and we would rather name it than let "encrypted" stand unqualified. When provisioning then writes those values into settings, the Stripe secret key, the PayPal client secret, the REX API key, the MYOB password and the freight carrier API key are written encrypted; the SecurePay password is not, because the service that charges through SecurePay reads it as plain text, and it is named in the unencrypted list below for that reason. One name in that list is doing double duty and deserves separating: the REX API key the wizard writes is not the same field as the REX SOAP API key entered on the gift-card and loyalty screens, which is stored unencrypted and appears below with the rest. That third group is the reason this section is written field by field rather than screen by screen — these sit on the same settings screens as credentials that are not encrypted.

Other credentials a Subscriber enters as a setting are held in a form our platform can read back, because the systems consuming them require the original value. Those include a Subscriber's own SMTP relay password, their SecurePay merchant identifier and password, the REX SOAP API key their gift-card and loyalty integration reads, an AI provider API key supplied for the storefront chatbot or for accounting automation, their reCAPTCHA secret key, their Telegram bot token and webhook secret, their site-audit API key, and the eWAY API key that accompanies the encrypted eWAY password. Two further qualifications belong here rather than in a footnote: a gateway secret entered before that field was marked secret may still be sitting in the older unencrypted form, because we read it either way rather than lock a Subscriber out of their own gateway; and not every Subscriber uses every one of these, so many are never filled in at all. Whatever is filled in sits inside the same access-controlled, Australian-hosted database as everything else, and is withheld by name from our admin AI assistant so a credential cannot be coaxed into a chat transcript. Within the Subscriber's own organisation it is reachable by staff holding the relevant settings permission. It is also reachable by us. A platform administrator at CARTT.AI can issue a one-time link that signs them in as a Subscriber's administrator — the mechanism that lets us diagnose a problem inside the account it is happening in, rather than asking a merchant to describe it — and while signed in they see the settings screens that Subscriber's own administrator sees. That access is used for support, provisioning and incident response rather than as a matter of routine, and is subject to the confidentiality obligations in our Subscription Terms. And there is a third group, which we would rather name than let the phrase "us" quietly cover. Where a Subscriber's account is managed by an agency under our white-label programme, the staff of that agency can open the accounts assigned to them by the same one-time-link mechanism, and while signed in they operate as that Subscriber's own administrator — which means they can see the customer records and the settings screens that administrator can see, credentials included. Two limits are built into it and are worth stating: an agency can only ever open a client that has been assigned to it, and it is signed in as the Subscriber's ordinary administrator rather than as a platform super-administrator, so the destructive and platform-level actions reserved to CARTT.AI stay reserved. Every entry of this kind is logged. If your account is managed by an agency, that agency is the party you engaged and this is the access that arrangement carries; if you would rather it did not, the assignment is what to change, and you can ask us at legal@cartt.ai. We would rather set all three out than let "your staff only" imply a wall that is not there. What is true without qualification is that these credentials are not encrypted at rest, and we would rather draw the line where it actually falls than let a blanket sentence cover the whole of it.

Despite these measures, no system can be guaranteed completely secure. You are responsible for keeping your account credentials confidential.

7.4 AI providers and your data

Where you use AI features, your inputs (prompts, source content, images) are transmitted to third-party AI providers for processing, which may occur overseas as described in section 7.1. Where the provider offers such commitments, we have obtained them, namely that:

They will not use your inputs to train their general AI models
They will retain inputs only as long as necessary to process them (typically deleted within 30 days)
They will apply security measures consistent with industry standards

Section 7.1 names the AI providers we currently use and the countries in which each is likely to process a request. That list is published there rather than held back for anyone who asks, because you should not have to write to us to find out where your information goes. It does change from time to time, so if you are relying on it for a decision, confirm the current position with us at legal@cartt.ai and we will tell you.

7.5 Data breaches

If we become aware of a data breach that is likely to result in serious harm to you, we will notify you and the Office of the Australian Information Commissioner (OAIC) as required by the Notifiable Data Breaches scheme.

8. Your rights

Sections 8.1 to 8.5 and 8.7 set out rights you hold under the Australian Privacy Principles and, for New Zealand, the Privacy Act 2020 (NZ). Section 8.6 is different, and we would rather mark it than let it borrow authority it does not have: the Australian Privacy Principles contain no general right to erasure — APP 11.2 obliges us to destroy or de-identify information we no longer need, which is an obligation on our side rather than a right on yours. The deletion right in section 8.6 is one we grant you in this policy. It is no less binding on us for that; it simply comes from us rather than from the Act.

8.1 Access

You may request access to the personal information we hold about you. We will respond within 30 days. There may be limited circumstances where we cannot grant access (for example, where doing so would unreasonably impact another person's privacy); in those cases we will explain why and offer alternative means where possible.

8.2 Correction

You may request correction of any personal information we hold about you that is inaccurate, out of date, incomplete, irrelevant, or misleading. Much of this information can be corrected directly through the admin panel; for other corrections, contact us.

8.3 Anonymity and pseudonymity

Where lawful and practical, you may interact with us anonymously or under a pseudonym. However, we cannot provide the Service to you anonymously — we need at least your name and email address to operate your account.

8.4 Marketing opt-out

You may opt out of marketing communications at any time by:

Clicking the unsubscribe link in any marketing email
Contacting us at legal@cartt.ai

Opting out of marketing does not opt you out of service-related communications (billing notices, outage notifications, security alerts, terms changes), which we will continue to send while you have an account.

8.5 Complaints

If you believe we have breached your privacy rights, you may complain to us at legal@cartt.ai. We will acknowledge your complaint within 5 business days and aim to resolve it within 30 days.

If you are not satisfied with our response, you may complain to the Office of the Australian Information Commissioner (OAIC):

Website: oaic.gov.au
Phone: 1300 363 992
Post: GPO Box 5288, Sydney NSW 2001

8.6 Deletion

Section 7.2 gives you an entitlement to ask us to delete personal information we hold about you once its retention period has passed, without needing to give a reason, and this is where to do it: email legal@cartt.ai saying what you want deleted. We will respond within 30 days, and we will tell you what we deleted rather than simply confirming that we acted.

Two limits, which we would rather state than discover with you afterwards. The first is that we may need to keep some of it, and where we do we will say which parts and why — a tax or accounting record we are required by law to retain, a transaction record needed to resolve a dispute or chargeback, or material we must preserve for a legal, regulatory or law-enforcement obligation. The rest is deleted regardless. The second is that where the information is End Customer information held for a Subscriber, the Subscriber decides what happens to its own customer records: we will pass the request to them and help them action it, and section 9 sets out how that division works. Deleting personal information we hold about you as a Subscriber is separate from closing your account — section 11 of the Subscription Terms of Service covers that, including the export window that runs first.

8.7 New Zealand subscribers

If you are based in New Zealand, you have similar rights under the Privacy Act 2020 (NZ). You may complain to the Office of the Privacy Commissioner of New Zealand at privacy.org.nz.

9. End Customer data (data held on behalf of Subscribers)

A significant portion of the personal information held within our Service is the personal information of End Customers — that is, the customers of our Subscribers' storefronts.

Both the Subscriber and we have obligations for it, and we would rather be clear about that than hide behind a label. It is common for a platform to describe itself as a mere "processor" acting for a "controller" and to disclaim the rest. That vocabulary comes from European law and does not appear in the Privacy Act 1988, which turns on whether an entity holds the information. We do hold it. So the division is one of roles, not of responsibility:

The Subscriber decides what personal information its storefront collects, for what purposes, how long it is kept, and which integrations and AI features are switched on. Those are its decisions, not ours, and its privacy policy governs them
We hold the information, keep it secure and available, and act on the Subscriber's instructions and configuration. Beyond that, we use it in our own right only to keep the Service secure, working and lawful, as section 5 sets out. We make no independent commercial use of it: we do not sell it, do not market to End Customers, and do not use it to train AI models
Where a Subscriber has enabled a feature that sends data to a third party — an AI provider, an SMS or email gateway, a payment processor, a marketplace, a shipping or accounting integration — that disclosure is made through our systems, so sections 6, 7.1 and 7.4 of this policy describe it and apply to it. This includes disclosures to overseas recipients
The security measures in section 7.3, the breach-notification commitment in section 7.5, and the storage locations in section 7.1 all cover End Customer information

If you are an End Customer, contact the store you dealt with first. They hold the commercial relationship, they can see your orders, and they can usually resolve an access, correction or deletion request faster than we can. Their details are on their storefront's privacy or contact page.

But you are not stuck with that route. If the store does not respond in a reasonable time, or you cannot reach them, or your concern is about how the platform itself has handled your information, write to us at legal@cartt.ai and we will deal with it. Where we need the Subscriber's involvement — because the request concerns data they control or an instruction only they can give — we will approach them on your behalf and tell you what happened. We will not use "the store is responsible for that" as a reason to do nothing, and you retain your right to complain to the Office of the Australian Information Commissioner about either of us. We also assist Subscribers in meeting their own obligations to their End Customers, as set out in the Subscription Terms of Service.

10. Children

The Service is not directed to children under 16 years of age. We do not knowingly collect personal information from children. If you believe we have collected information from a child, please contact us and we will take prompt steps to delete it.

Subscribers must ensure their own storefronts comply with applicable laws regarding the collection of children's information.

11. Changes to this Privacy Policy

We may amend this Privacy Policy from time to time. The version number and effective date shown at the top of this page indicate when it was last changed.

Where the change is material (it significantly affects how we collect, use, or disclose your personal information), we will:

Publish it as a new numbered version, so the current version number, effective date and content hash shown on this page change. Publication is the step that always happens, and it is the one you can verify for yourself on this page at any time
Email the administrators on your account. This is a step we carry out ourselves rather than something the platform sends automatically, so treat the published version on this page — not your inbox — as the authoritative record of what is in force
Where we are able to give advance notice, give at least 30 days; where a change must take effect sooner, tell you why
Where the law requires your fresh consent before a change can apply to you, ask you for it directly and not rely on your continued use of the Service as consent

Non-material changes (clarifications, typo corrections, and factual corrections that narrow rather than widen what we do) take effect when published, and we do not email about them.

Every published version of this policy carries a version number, an effective date, and a content hash. The version number and effective date are shown at the top of this page, and an abbreviated form of the hash at the foot; the full hash is available on request. We retain the full version history and will provide any earlier version on request to legal@cartt.ai.

12. Contact us

Privacy enquiries, requests, and complaints can be made to our Privacy Officer at legal@cartt.ai. If you would prefer to write to us by post, email us and we will provide a postal address.

We aim to respond to all privacy enquiries within 30 days.

Reference: privacy-policy v42 · content hash 48e40db797fe133a. Questions before you accept: legal@cartt.ai.