How we handle data on Korufi.

Korufi is a trading name of Peopleamp Tech Ltd, a private company registered in England & Wales. We operate the platform at korufi.com and the tenant subdomains under it (for example, kwames.korufi.com). When this policy says “we”, “us”, or “Korufi”, it means Peopleamp Tech Ltd.

For privacy questions or anything else, write to hello@korufi.com. It reaches the founder directly and is replied to within four hours during the workweek.

Korufi sells software to restaurants. Restaurants then use that software to take orders and reservations from their guests. Two relationships, two different roles for us under data-protection law:

Operator data: we are the controller.

When a restaurant operator signs up, that operator is our customer. We decide why and how we hold their account, billing and dashboard data, so we are the controller for that data and this policy is the full picture for them.

Diner data: we are the processor.

When a guest places an order on a tenant subdomain, the restaurant is the controller of that guest's data. We process it on the restaurant's behalf, under the contract the restaurant agreed to when they signed up. The restaurant's own privacy notice (usually linked from their tenant site) is the source of truth for diners.

If you are a diner trying to find out what one of our restaurants does with your data, ask the restaurant first. If you cannot reach them, write to hello@korufi.com and we will help you find them.

• Your name, work email, and the name of your restaurant.
• Your subdomain, brand colours, hours of service and menu. Everything you have configured in the operator dashboard.
• Your Stripe Connect account ID. We never see your card numbers, your bank account, or your customers' card numbers. Stripe holds those.
• Your subscription status with us (active, past due, cancelled), the plan you are on, and the invoices we have raised against you.
• Server logs of how the operator dashboard is being used: timestamps, IP addresses, user-agent strings, the routes you visited. We use this for security, support and capacity planning.
• Anything you choose to email us in support tickets.

When a guest orders, reserves, or signs up for loyalty on a tenant subdomain, the restaurant is asking us to handle the following on their behalf:

• Name, email address and phone number, when given.
• Delivery or table address, when relevant to the order.
• Order history, basket contents, dietary notes and any guest-side messages.
• Loyalty balance and reward redemption history.
• A magic-link session cookie so the diner can return without a password.
• Stripe payment metadata: we see a token and the amount, never the card number.

Diners can ask the restaurant to delete or export their data at any time, and the restaurant can fulfil that request directly inside the operator dashboard. If a diner asks us instead, we will route the request to the restaurant within seven days.

To run your account.

We need your email and restaurant details to give you a working dashboard, send you receipts, and keep your subdomain pointing at the right data. Lawful basis: performance of the contract we have with you.

To take payment.

We bill the monthly subscription via Stripe. Stripe holds the card data; we hold the invoice record. Lawful basis: contract.

To keep the platform safe.

Server logs, rate limits and crash traces help us spot abuse, debug outages and protect every other restaurant on the platform. Lawful basis: legitimate interest.

To improve the product.

We look at aggregate usage: which dashboard pages are visited, where operators get stuck, what loads slowly. We do not sell this and we do not profile individuals from it. Lawful basis: legitimate interest.

To meet our own legal obligations.

Tax, accounting, anti-fraud checks. Lawful basis: legal obligation.

We keep the sub-processor list short on purpose. Every name on this list has a written contract with us that includes data-protection terms. We do not sell data to anyone, ever, full stop.

Stripe (Ireland / United States).

Card payments, subscription billing and Stripe Connect payouts. PCI-DSS Level 1.

Vercel (United States).

Hosting, edge compute and content delivery for korufi.com and the tenant subdomains.

Sentry (United States).

Error and crash monitoring. Stack traces are scrubbed of obvious personal data before they leave the browser.

Database hosting (European Union).

The application database (operator data, diner orders, loyalty balances) sits on managed Postgres inside the EU.

Transactional email provider.

Order receipts, magic-link emails and operator notifications. Subject line and body pass through; bodies are not retained beyond delivery.

When we add or change a sub-processor we update this page. Operators on a paid plan are notified by email at least thirty days before a new sub-processor goes live for their data, except where a change is required to keep the service running safely.

The application database sits inside the European Union. Some of our sub-processors (Stripe, Vercel, Sentry) operate from the United States. Where a transfer to a country outside the UK or EEA happens, we rely on the UK International Data Transfer Addendum or the EU Standard Contractual Clauses, plus the additional technical safeguards each provider publishes.

• Operator account data: while you are a customer, plus seven years afterwards for tax and accounting records.
• Operator dashboard logs and crash traces: ninety days, then automatically deleted.
• Diner order data: held under the restaurant's instruction. Default is two years from the last order, then archived; the restaurant can shorten this in their dashboard.
• Magic-link session cookies: thirty days from last use.
• Marketing-site analytics: aggregated, no individual identifiers retained beyond fourteen months.
• Support emails: kept for two years from the last reply, so that we can give continuous answers if you come back.

Whether or not the law in your country requires it, you can ask us to do all of the following and we will do it within thirty days:

• Tell you exactly what we hold about you.
• Send you a copy in a portable format (JSON or CSV).
• Correct anything that is wrong.
• Delete it. For operators with active subscriptions this means closing the account; we will explain what we have to keep for tax reasons before we delete the rest.
• Stop using it for a particular purpose, for example marketing.
• Object to a piece of processing that you think is not justified, and we will stop unless we can show a good reason to continue.

To exercise any of these rights, write to hello@korufi.com. If you are in the United Kingdom or the European Union, you can also complain to your local data-protection regulator. For the UK, that is the Information Commissioner’s Office. We would rather you came to us first.

On korufi.com (this marketing site) we set no third-party tracking cookies, no advertising pixels, and no cross-site identifiers. We use a single first-party cookie to remember whether you have dismissed a banner, plus whatever Vercel sets to keep the site running.

Inside the operator dashboard and on tenant subdomains we set a session cookie when you sign in (so you stay signed in) and a CSRF token (so other websites cannot post on your behalf). Stripe Checkout sets its own cookies when you reach the payment step. Stripe controls those and explains them in its own privacy notice.

Operator accounts are for restaurant staff and so are restricted to people aged eighteen and over. Tenant subdomains may take orders from any age the restaurant decides is appropriate under local law, but we do not knowingly collect data from anyone under thirteen. If you believe a child has signed up, write to hello@korufi.com and we will investigate and delete.

• All traffic is encrypted in transit with TLS 1.2 or better.
• Database storage is encrypted at rest.
• Access to the production database is restricted to a small number of named individuals and is audit-logged.
• We do not store passwords for diners. They sign in by magic link.
• Stripe holds payment-card data; we hold a token only.
• We have a written incident-response process and will notify affected operators within seventy-two hours of a confirmed personal-data breach that is likely to affect them.

If we change anything material on this page we will email every active operator at least thirty days before the change goes live, and we will note the change in the public changelog. The date at the top of this page is always the current effective date.