Recpt helps you organise your work-related expenses. Receipt images are personal data, so we let you encrypt them on your device with a passkey. This page explains exactly what that means, what we can still see, and what we cannot.

This page describes our security design and intent in good faith. It is not a guarantee or warranty of any kind. Software has bugs and security is an ongoing effort. Your use of Recpt is governed by our Terms, including the disclaimers and limitation of liability.

The short version

• Encryption is opt-in. You enable it from the security prompt after sign-up, or any time from Privacy settings.
• When on, receipt images are AES-256-GCM ciphertext at rest in our object store. The key is wrapped under your passkey.
• Only your device (with your passkey) or your recovery code can unwrap the key.
• Expense metadata (vendor name, amount, date, category) is not encrypted. We need it plaintext so the app works.
• We do not market this as “end-to-end encrypted”. See the Scan window below.

What gets encrypted (when you enable it)

• Receipt photos uploaded via the web app.
• Generated thumbnail images for the same.

If you don't enable encryption

Without opt-in encryption, your receipt images are stored with standard server-side protections (encrypted disks, access controls, audit logs). Authorised Recpt staff can technically read them if needed for support or compliance, and they would be readable to anyone who broke into our database. If you'd rather make that impossible, enable passkey encryption from Privacy settings. Once on, the keys never leave your device.

What does not get encrypted

• Expense rows: vendor, amount, date, category, work-use percentage, notes.
• Tax profile answers (occupation, work setup, etc.).
• Account metadata: email, sign-in method, plan.

Encrypting that metadata would break expense totals, CSV export, search, and the categorisation engine. We chose practical privacy over a marketing slogan.

How the encryption works

When you enable encryption, your browser generates an X25519 keypair. The private half is wrapped under two separate keys and uploaded to us in wrapped form only:

• A device key derived from your passkey via the WebAuthn PRF extension (HKDF-SHA-256). Different on every device.
• A backup key derived from a 24-character recovery code via Argon2id. The recovery code is shown to you once and never to us.

Each receipt image is encrypted with a fresh 256-bit Data Encryption Key (DEK) via AES-256-GCM. The DEK is wrapped under your X25519 public key using HPKE (RFC 9180, DHKEM-X25519 + HKDF-SHA-256 + AES-256-GCM). We store the wrapped DEK next to the ciphertext object. Without an unwrapped private key, the ciphertext is opaque.

The Scan window

When you upload a new receipt, our backend needs to read the image in cleartext for a few seconds in order to:

• Run vision OCR on it (vendor, amount, date, line items) through our AI model provider.
• Categorise the expense for review.
• Generate a thumbnail.

During that window the plaintext bytes live in our process memory. We then encrypt them with your public key, write the ciphertext to storage, and drop the plaintext. The bytes are not written to disk in cleartext, but they are visible to the operating-system process during the scan call.

This means: for the few seconds between upload and scan completion, the receipt bytes exist in plaintext in our running process. Standard infrastructure protections (process isolation, audit logs, no plaintext on disk) apply during this window, but it is theoretically possible to read the bytes through a runtime compromise or authorised internal access. As soon as the scan completes, the plaintext is dropped, and the only thing left is ciphertext plus a key that only your device or your recovery code can unwrap. This is the one period where the design isn't fully zero-knowledge, which is why we don't market the feature as end-to-end encrypted.

AI model provider / cross-border processing

Receipt images are sent to our AI model provider during the scan window for OCR and categorisation. That request is currently served from the United States. The provider states they do not retain customer data after processing. We rely on that contractual commitment; we cannot independently verify it. This is disclosed under the Privacy Act 1988 (Cth), APP 8, on our Privacy page. The specific provider is named on our Privacy page.

Who can read your encrypted images (by design)

• You, from any device where you have a Recpt passkey enrolled.
• You, using your one-time recovery code.
• Nobody else (including Recpt staff, the hosting provider, or anyone who gains access to our database) without a passkey or recovery code.

This is the design. Real-world security depends on the design holding up against implementation bugs, supply-chain compromise, and other risks no provider can fully eliminate. The Scan window above describes the one period where we hold plaintext.

Threat-model FAQ

If you lose every passkey and your recovery code, can Recpt restore my receipts?

No. There is no recovery path. The wrapped DEKs become unrecoverable, and the ciphertext stays opaque. Your metadata (vendor, amount, date) is still readable and your records aren't lost, but the original receipt images cannot be opened by anyone. This is the trade-off for the privacy guarantee.

What happens if Recpt's database is compromised?

An attacker would get expense metadata (vendor, amount, date, category, profile answers), wrapped public keys, and wrapped DEKs. They would not get the receipt images themselves, which are stored in object storage as ciphertext. They would also not get usable private keys, since both wrap copies require either your passkey PRF output (device-bound) or your recovery code (user-held).

What happens if Recpt's object storage is compromised?

Ciphertext only. Useless without per-user device keys or recovery codes.

What if both are compromised at the same time?

Same as the database-only case for your images. The metadata leaks are the documented limit of this design.

Does Recpt see my passkey?

No. WebAuthn assertions never expose the underlying key material to a website. We only see a signature and, for encryption, an opaque PRF output used to derive a key inside your browser.

Does encryption slow down receipt scanning?

Negligibly. Encryption happens after the scan completes; the user-visible latency is dominated by the vision call.

Why a recovery code AND a passkey, instead of just one?

Passkeys are device-bound. Losing a phone shouldn't lock you out forever. The recovery code is a portable backup that lives outside any device. Write it down or save it in a password manager.

Can I turn encryption off?

Not at the moment. You can remove individual passkeys and regenerate your recovery code. A “turn off encryption” flow would require us to decrypt and re-upload every encrypted object, which we have not built. If you need that, contact us.

Standards and cryptographic primitives

Component	Standard
Passkey	WebAuthn Level 3
PRF extension	WebAuthn PRF
Wrap KDF (passkey)	HKDF-SHA-256 (RFC 5869)
Wrap KDF (recovery code)	Argon2id (t=3, m=64MiB, p=1)
Public-key encryption	HPKE — DHKEM-X25519 / HKDF-SHA-256 / AES-256-GCM
File encryption	AES-256-GCM, 12-byte random nonce
Data location	Australia
Hosting provider	Certified to ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 1/2/3, and PCI DSS for physical and operational security

Report a security issue

Email help@recpt.com.au. We acknowledge within 2 business days and aim to give you a substantive response within 14 days.

Safe harbour for good-faith research. We will not pursue civil or criminal action against researchers who, in good faith:

• Test only against their own test account (message us and we'll provision one).
• Do not access, modify, exfiltrate, or destroy data belonging to other users.
• Do not run denial-of-service tests or sustained automated scanning against production.
• Do not social-engineer Recpt staff or contractors.
• Give us a reasonable window to fix before public disclosure (we aim for 90 days for non-critical issues, sooner if mutually agreed).

We don't currently run a paid bug bounty, but we do credit researchers who want recognition.

Limits of these statements

The technical descriptions on this page reflect the current implementation and are subject to change as we improve the system. They describe design intent and standard cryptographic primitives in current use. They are not a warranty of security, accuracy, or fitness for any purpose, and they are not, and do not create, a contractual promise beyond what is in the Terms. We will update this page when the implementation changes materially.

Not tax advice. Recpt is a record-keeping tool. Verify before claiming; consult a registered tax agent.