A payment platform that answers in a local language handles two sensitive things: money and conversations. Here are the measures in place, and the limits of each.
The principle
The first security measure of any service is not its encryption, it is what it chooses not to keep. That is where we start. Phone numbers and email addresses are encrypted in the database and are never readable by an analytics query. The views feeding our internal dashboards contain no personal data: no identity, no free text, no IP address. They carry only technical identifiers, used to join rows without saying who is behind them.
In practice, someone looking at our usage statistics sees volumes, costs and durations. They do not see conversations. That separation is written into the database itself: analyses go through a read-only access that cannot reach the encrypted data. A tired day cannot change that.
Our commitments, and what they do not cover
A commitment with no written limit is not a commitment. Each one below is followed by what it does not promise.
Encryption of personal identifiers
Email addresses and phone numbers are encrypted in the database. They are decrypted only at the strictly necessary moment, to send you a sign-in code or process a payment.
The content of your conversations must remain readable by the service in order to be returned to you. It is protected by access control, not by end-to-end encryption.
Encrypted transport, without exception
All traffic runs over HTTPS with automatically managed certificates, on both domains. No page and no interface request is served in the clear.
That protects the link between your device and our servers. It does not protect an already compromised device, nor a network capturing your keystrokes before they are sent.
A security review after every update
An automated review runs after each deployment and checks what breaks most often: exposed secrets, vulnerable dependencies, missing headers, over-broad permissions. Its result is recorded.
An automated review catches known mistakes. It does not replace an external audit, which we will have conducted before opening the service to companies.
Separation of access
Analytics run under a read-only access that can neither write nor read sensitive data. Administrative access is individual and logged.
The separation applies to the database. Access to the server itself remains full access: that is why it is kept to the minimum number of people.
Payments handled by licensed institutions
We store no card number and no mobile money PIN. Payments are processed by our providers, who hold the licence and the industry compliance.
We keep a record of transactions: amount, currency, date, status, and the identifier the provider returns. Accounting requires it.
Backups and retention
Data is backed up encrypted, away from the servers, with a key the host does not hold; every backup is verified and logged. Analysis exports are deleted after thirty days.
Thirty days is the retention of analytics exports, not of your account data. The retention period for your data is set out in the privacy policy.
Found a vulnerability?
Write to our security address before publishing anything.
We acknowledge within three business days, keep you informed until the fix ships, and we do not pursue researchers who stay within the scope of responsible disclosure.
The servers are hosted in the European Union, with an established provider, with automatically renewed certificates. From East Africa, latency stays acceptable, the cost is under control, and European data protection law applies.
We know this point will be debated, and that hosting on the continent would be preferable in several respects. We will move when capacity and reliability there are comparable, and we will say so on this page the day it happens.
The list of the companies involved, by category, what each one actually sees and where it is established, is published on the Subprocessors page; names are provided on written request. It is dated and updated whenever it changes.