1. The list
Each of these processes data on our instructions under a written agreement, is bound to confidentiality, and is held to security measures at least as strict as our own. This table is the same data as section 6 of the Privacy Policy — one list, rendered twice, so the two cannot drift apart.
| Sub-processor | What they do | What they get | Where |
|---|---|---|---|
| Stripe, Inc. and Stripe Payments Canada, Ltd. | Payment processing, card acceptance, payouts, identity and risk | Cardholder data, transaction records, payout and bank details, business verification records | United States, with regional processing |
| Twilio Inc. | Text messages: signup verification codes, receipts a customer asked for, booking confirmations, pay links, dispute alerts | The destination mobile number and the words of the message. No card number, no password, and no order detail beyond what the message itself says. | United States |
| Amazon Web Services, Inc. | Hosting, database, object storage, logging, and email delivery through SES | All application data at rest and in transit. For email, the destination address and the message. | United States (us-east-1) |
| Mapbox, Inc. | Address autocomplete on the signup form and on a store’s address | The partial address being typed, sent from our servers rather than from your browser, so Mapbox never sees your IP address | United States |
| Anthropic, PBC | The AI features: Catalog Studio, add-on suggestions, dispute drafting | Only the specific records needed for the request you triggered. Sent through the commercial API, which is not used to train models. | United States |
| Google LLC | Google Analytics 4 on our website, our documentation site and the signed-in console | Page views, IP address and user agent of people browsing those pages. No merchant record, order, customer or amount is ever sent to it, and no page a customer of yours sees loads it at all. | United States |
2. Card data, and what SAQ-A means
The card number is the part people worry about, so it gets its own section. It never reaches a Kessel server.
- On a reader, the card is read by Stripe’s own certified Terminal hardware and goes from there to Stripe. Kessel’s app on the reader asks Stripe to collect a payment and is told the result.
- On the web, the card fields are served by Stripe inside an iframe on our page. We cannot read what is typed into them; the browser sends the card to Stripe directly, and our code never sees it.
- What comes back, and all we store, is a token, the last four digits, the brand, the expiry, the entry method and the approval result.
In the card industry’s own language that is SAQ-A: a merchant who has outsourced all card handling to a validated third party, whose own systems neither store, process nor transmit a card number. It is the right description of Kessel and it is worth saying plainly, because it is the question a merchant actually wants answered and because it is why there is no PCI fee on your bill.
SAQ-A stopped meaning "nothing to do" in March 2025, when clauses 6.4.3 and 11.6.1 of PCI DSS 4.0.1 came into force: a page with an embedded payment form now needs an inventory of every script on it, a written reason for each, and monitoring for changes to the page. That is why the Kessel surfaces a cardholder sees — a pay link, a guest check, a booking page, a receipt — load nothing third-party except Stripe and the web font, and why analytics loads on signed-in console pages instead. A short inventory is easier to defend than a long one.
SAQ-A is a self-assessment, not a certificate somebody issued us. We hold no SOC 2 report and no PCI Level 1 attestation, and we will not imply either. Stripe holds the certifications that apply to the card path and publishes them; ours is the claim that the card never arrives here, and that one we will stand behind in writing.
3. What each one actually gets
Stripe. The payments themselves: card data captured by their hardware or their iframe, the transactions, payouts, your bank details, and the business verification records they are required to collect. You hold the connected account and the merchant relationship; we are not a processor, a bank or a money transmitter and we do not hold your money at any point.
Twilio. Text messages, and only what a text message is: the destination number and the words. Twilio’s logs hold the body, which is why a Kessel text never contains a card number or a password. A pay link carries a single-purpose token for that one bill and nothing else. Every message leaves on our own registered number rather than yours, for delivery reasons set out in the Acceptable Use Policy.
Amazon Web Services. The infrastructure: the servers, the database, object storage and the logs, in us-east-1. Email leaves through SES, which is the same vendor, which is why AWS appears here once rather than twice. Everything Kessel holds is held here, encrypted in transit and at rest.
Mapbox. The address box on the signup form and on a store’s address. What they see is the partial address being typed, and they see it from our servers rather than from your browser: the request is proxied, so Mapbox gets no IP address of yours and no token of ours reaches a browser. Typing the address by hand is always available, so a merchant who would rather not query them at all does not have to.
Anthropic. The AI features, and only the specific records needed for the request you triggered — the items you asked Catalog Studio to draft, the dispute you asked for a response to. It goes through the commercial API, whose terms prohibit training on submitted content. The assistant surface at /mcp is read-only by construction rather than by permission.
Google. Google Analytics 4 on our website, our documentation site and the signed-in console, counting page views. Google Signals and the advertising features are switched off, so nothing here builds an advertising profile. No merchant record, order, customer or amount is ever sent to it. It does not load on any page one of your customers sees — a pay link, a guest check, a booking page, a receipt — and a merchant’s own storefront carries no analytics at all. Separately, our web fonts are served by Google Fonts, which receives an IP address to deliver a font file and sets no cookie; the cookie notice says more.
4. Not in use yet, and listed anyway
Push notifications to a merchant’s own phone are built and are not switched on. The sender exists, the credentials do not, and nothing has ever been sent. When they are switched on, Apple (APNs) and Google (FCM) will receive a device token and the words of the notification, and this page will say so at least 30 days beforehand.
It is named now so that a review done today is not surprised by a deployment next month. Nothing else is waiting in the wings; if it were, it would be in this section.
5. Where the data is, and how transfers are covered
Our infrastructure is in the United States, and every sub-processor above processes there. If you are in Canada, the EEA or the UK, your data is transferred to the United States. For EEA and UK transfers we rely on the European Commission’s Standard Contractual Clauses and the UK Addendum with each sub-processor. For Canadian merchants, PIPEDA permits transfer to a service provider abroad with comparable protection, and this is your notice that it happens.
6. Changes, objections and the DPA
- A new sub-processor is posted here and emailed to you at least 30 days before it starts processing your data.
- If a new one is a problem for you, tell us at privacy@usekessel.com before it takes effect. You may also cancel without penalty, which you could do anyway and without a reason.
- A signed DPA, including the Standard Contractual Clauses, is available on request at no charge and on any plan.
- We answer security questionnaires. Send yours to security@usekessel.com.
- Removing a sub-processor is not announced in advance, because taking somebody out of the chain needs no notice period to be safe. It is reflected here when it happens.
7. What this document is
This is section 6 of the Privacy Policy in full and on its own page, because a list buried in a longer document is the list that goes stale — as this one did. The Privacy Policy governs; where the two differ, it wins and this page is the thing to fix.
Also: Terms of Service. Pricing is $49 a month and interchange + 0.90% + 30¢, described in full on the pricing page.