Privacy Policy

This policy says what CactusStay collects, where it is kept, who can see it, and for how long. It is written for the hotel owner or bookkeeper deciding whether to upload a month of records, so it names the specific systems involved rather than describing them in general terms.

What we collect

Account and organisation. Your name and email address, and the name of your organisation, through Clerk, our sign-in provider. Which organisation each person belongs to and their role in it.

Property details. The property's name, city, state, timezone, which property management system it runs, and how it is paid for Booking.com stays.

The records you upload. Each file you upload is kept, and for each one we record its name, size, a cryptographic hash of its contents, and the month and property it belongs to. From its contents: reservation and confirmation numbers, arrival and departure dates, amounts, channel, status, and — where the export includes them — guest names and the last four digits and brand of a card. Guest names are stored whenever an export includes them, because they are how Booking.com stays are matched to your PMS records. Leave them in where your agreements allow; if your agreements require you to remove them, delete the name column rather than overwrite it with a placeholder.

Files we cannot yet read. An export whose columns we do not recognise is kept, with its first few lines stored alongside it, so that we can write the mapping that reads it. It is not used in any comparison until that mapping exists. You can ask for such a file to be deleted at any time.

What the comparison produces. Every exception, every record it cites, every deadline computed for it, and every decision a named person in your organisation took about it. The decision log is append-only: it can be added to, never edited or deleted, because it is the audit trail an OTA dispute rests on.

Billing. Your Stripe customer and subscription identifiers and the email address invoices go to. Card details are entered on Stripe's pages and never reach us.

Support. What you send to our support address, which is handled in Freshdesk.

What we refuse

A full card number. Every CSV, Excel and PDF file you upload is scanned for card-number patterns before it is hashed, stored or queued. A file containing one is refused, the message names the line (and, where it can, the column), never the digits, and nothing from the file is kept. There is no field in our database a card number could be written to.

Text is decoded before it is scanned, so a file saved as UTF-16 ("Unicode Text") is read correctly rather than slipping past the scan. A file whose encoding cannot be told for certain — one with NUL bytes and no marker, such as unmarked UTF-16 or a binary file renamed to .csv — is refused with nothing stored, and you are asked to save it as CSV UTF-8. Only CSV, Excel and PDF files are accepted.

The reconciliation engine scans every file again before it reads a line. If that scan finds a card number, or a PDF has no text that could be scanned, the file is deleted and the run reports which file was refused. That second scan is the one that always applies: if the PDF reader ever fails to load at upload, the PDF is held in quarantine (below) without the first scan, and the upload message says so.

Where it is kept

• Supabase (Postgres database and file storage), hosted on AWS in the us-west-1 region (Northern California). Your records, the comparison results and the decision log are in the database. Each uploaded file is kept once, in a private storage bucket, under a name derived from its own hash (an Excel workbook is kept as the text of the sheet that was read); runs read it from there by reference, so re-running a month needs no re-upload.
• Vercel, which hosts the web application you sign in to.
• DigitalOcean, San Francisco region, which runs the reconciliation engine. The engine has no public address; it reads jobs from the database and writes results back.
• Clerk, which handles sign-in and holds your name and email.
• Stripe, which holds your card and issues invoices.
• Loops, which sends email: the daily deadline brief, the weekly virtual-card reminder, the email when a run finishes or fails, and the monthly digest to the addresses on your account, and operational alerts to the CactusStay administrators. An alert about a file we could not recognise carries only the line we identify as that file's column row, with any digits masked, never the rest of the file; an alert about a refused card number carries only line numbers. Alerts also name the organisation, property, month and file.
• Freshdesk, which holds the support email you send us.

Two short-lived holding areas exist inside the same private bucket:

• Staging. Larger uploads go from your browser straight to a private staging area, where they wait only until our server has scanned them. The staged copy is removed whether or not it passes; one that is never finished, because a tab was closed, is deleted after two hours.
• Quarantine. A PDF waits in a quarantine area that no account can read until the engine has scanned it. It is then moved to its permanent place, or deleted if it fails. A quarantined PDF whose month is never run is deleted after seven days and has to be uploaded again.

We use no advertising trackers and sell nothing about you to anyone.

Automated processing

Amounts, matches and deadlines are computed by deterministic code. We may use automated models to read a document you upload — for example to extract the line items from a commission invoice PDF — and to propose a label from a fixed list of causes. A model never computes an amount, applies a match, or takes an action, and your records are not used to train models.

Who can see it

People in your organisation, according to their role. Osonwanne Group staff, to run the service, to write a mapping for a file we could not recognise, and to help you when you ask. Every read and write the application makes is scoped to your organisation. The database has row-level security switched on, and the policies that would make it a second, independent check are written but not yet switched on; until they are, the application's own scoping is what keeps one customer's records from another, and we say so here rather than claim two layers where there is one. Access is never granted to another customer. The providers above, each only for the part of the service it runs.

We disclose records to no one else unless the law requires it, in which case we tell you unless we are prohibited from doing so.

How long we keep it

Your uploaded files, your records and the comparison results are kept for as long as your organisation's account exists, because an evidence pack has to be reproducible from the original inputs years after the month it covers. Files we could not recognise are kept the same way, so that they can be run once a mapping exists, unless you ask for them to be deleted.

We have not yet set a fixed deletion period after an account closes. Until we have, we say so here rather than quote one: on closing your account you can ask for your records and files to be deleted, and we will delete them, apart from the minimum billing history we are required to keep.

Your rights

You can ask at any time for a copy of what we hold about your organisation, for a correction, or for deletion. Requests go to support@osonwanne.freshdesk.com.

Changes

If this policy changes materially we will email the organisation's owners before the change takes effect.