Payment details in Olik Split are encrypted on your device with a key that never leaves your hardware keystore, sent to our server already encrypted, then encrypted again with a separate server key. We literally can't read them. And neither can anyone else.
Three uncomfortable truths about how payment data usually gets stored
Most apps mean: encrypted with a server-side key the company holds. If their database leaks, your IBAN goes with it. If a rogue engineer queries it, they can read every entry.
"How do I pay you back?" is friendly. "Here's a list of every payment method 12 friends have used in 2026" is a target for phishing. The list shouldn't live anywhere readable.
Trust is a single point of failure. The better answer: make it technically impossible to read the data, even with full database access. That's what we built.
Step 1: on your device, we generate a random 256-bit AES-GCM key and store it in your phone's hardware-backed keystore (Android Keystore / iOS Keychain — backed by the Secure Enclave when present). This key never leaves your phone. We use it to encrypt your payment details before they even touch the network. Step 2: the server receives an already-encrypted blob, and encrypts it a second time with its own server-side key. Two layers, two separate keys, neither knows the other.
Mark a payment method private and it's double-encrypted as above — only your own device sees it. Mark it public (e.g. the PayPal you share with your roommate group) and it's encrypted server-side only, with access scoped to specific group members. You decide which.
PayPal, Revolut, Venmo, Cash App, Wise, Monobank, PrivatBank, raw IBAN, raw card number, raw phone — pick what you actually use. Add a label (e.g. "EU IBAN" vs "UK IBAN"), set it as default for a currency, and group members can copy or open the deep-link with one tap when settling up.
| Olik Split | Splitwise | Tricount | |
|---|---|---|---|
| Hardware-backed key on device | Yes | — | — |
| Double encryption in transit + at rest | Yes | — | — |
| Server can decrypt your data | No (private) | Yes | Yes |
| Group-scoped sharing | Per-method choice | — | — |
You share rent with three flatmates. You want them to have your IBAN so they can pay you on time every month — but you don't want it sitting in a third-party database that might leak in 2027. So you add it as a public payment method scoped to your roommates group. They see it inside Olik, they can copy it, they can't share it outside. The server stores it encrypted; we couldn't show it to anyone else even with a warrant for that row.
Then you add your private backup card details — separate, encrypted with the device key only you have. You can see it; the server stores it as opaque bytes. If the database is dumped tomorrow, that field is unreadable noise.
Private (device-encrypted) methods are bound to your phone's hardware key. If the phone is lost and you log in on a new device, those entries show as encrypted blobs and need to be re-entered. Public methods (group-shared) re-sync normally. This is by design — losing the phone means losing the key.
For private methods: no. The server only sees ciphertext encrypted with a key it doesn't have, then encrypts the ciphertext again with its own key. There is no path to decrypt without your device. For public methods: the server can decrypt to deliver to group members, but the value is still encrypted in storage with the server key.
Yes. Android encryption code lives in shared/src/androidMain/.../security/AndroidPaymentEncryption.kt, iOS in the equivalent Swift wrapper. Both use platform AES-GCM with hardware-backed key material. We'll publish a security review when we cross 100k installs.
Defense in depth. If a future cryptographic flaw breaks the server-side layer, the device-side layer still protects private entries. If the device-side layer's key material leaks (e.g. via a kernel exploit), the server-side layer still protects against unauthorized DB access. The two failures are independent.
