Security Policy

All traffic between the Uven apps or website and our servers is encrypted using Transport Layer Security (TLS). On our production systems, plain unencrypted connections are redirected to secure ones, and browsers are instructed to use a secure connection for our domains from then on. Session and security cookies are marked secure so they are not sent over an unencrypted connection.

Real-time chat runs over an encrypted connection as well. Encrypted transport protects a message while it is moving; it does not mean the message is unreadable once stored — see section 04.

Some data is encrypted a second time inside our database, so that reading the database is not enough to read the value.

Encryption keys are held outside the application code and are supplied to our systems through protected configuration. They are never committed to our code repository.

We publish this split rather than claiming that everything is encrypted. A blanket claim would be untrue, and an untrue security claim is itself a risk to you.

Uven chat is not end-to-end encrypted. Messages travel over an encrypted connection but are stored on our servers in readable form, so that they can be delivered across your devices, reviewed for safety, and used as evidence in a dispute.

Messages are permanently deleted 90 days after they are sent. Authorised staff may read message content where there is a legitimate reason, such as a dispute, an abuse report, or a legal request. Automated moderation may flag messages for review.

Treat Uven chat as you would a written record. Do not send passwords, one-time codes, card numbers or identification documents through it.

We never store your password. Passwords are put through a modern, deliberately slow one-way hashing algorithm before they are saved. Nobody at Uven can read your password, and we can never send it back to you — we can only help you set a new one.

When you choose a password, we check it against a minimum length, reject passwords that appear on published lists of common passwords, and reject passwords made only of digits.

We verify your phone number with a one-time code sent by SMS. A one-time code is also required for sensitive account operations, such as joining a Google sign-in to an existing account. Codes expire and are consumed once used, so a code cannot be replayed.

We currently do not offer app-based two-factor authentication. Until we do, the strongest protection for your account is a password you use nowhere else, plus control of your phone number. If you sign in with Google, protect that Google account with Google's own two-step verification.

Sign-in, one-time code and password-reset endpoints are rate limited, so an attacker cannot guess at speed.

Signing in creates a session. We record which device, platform and app the session belongs to, along with the IP address and the city and country we infer from it, so you can recognise your own sessions and we can spot ones that do not look like you.

If you change your password, we recommend ending your other sessions at the same time.

Uven does not store your full card number, your card security code, or your mobile money PIN. Those details are entered on the secure pages of our payment processors, Paystack and Moolre, who are licensed and regulated to handle them.

If you save a payment method, the processor returns a reference that lets us charge it again. We store that reference encrypted, together with display-safe details only — the card brand, the last four digits, and the expiry month and year.

Money for a booking is held by the platform in escrow rather than passing straight to the provider, and it leaves escrow only through two controlled paths in our systems, each checked against what you agreed to pay. Amounts are recorded in whole minor units, money operations are atomic and can be safely retried without paying twice, and correctness rules such as one payout per job are enforced by the database itself rather than by application code alone. When funds are released, and on what conditions, is set out in our Terms of Service.

Keeping payments on the Platform is itself a security control. A payment made outside Uven has no escrow behind it, no record we can examine, and no route into our dispute process.

Access to personal data is limited to staff whose work requires it. Permission checks run through a single decision point in our systems rather than being re-implemented feature by feature, so a role means the same thing everywhere.

• Support and trust & safety staff can see account details, bookings and payment records needed to answer a query or investigate a report, and can read chat content connected to a dispute or safety case.
• Finance and operations staff can see transaction, payout and dispute records to settle money and resolve cases.
• Engineers work against test data by default. Access to production data is restricted and granted for a specific purpose.
• Other users never see more than the Platform is designed to show. Evidence and comments on a dispute are visible only to the parties to that booking and to our staff. Some information is withheld by design — for example, a crew member working on a job is not shown the customer's total price.

Administrative actions on accounts and money are recorded. Staff accounts are individual, never shared.

Uven runs on managed cloud infrastructure. Production is kept separate from our development and test environments, each with its own configuration and credentials, so work in progress cannot reach real user data.

Uploaded files are held in access-controlled cloud storage and are not publicly listable. They are served through links that expire after a short time, so a link that leaks does not stay usable.

Credentials and secrets live in protected environment configuration, never in our source code, and are not written to logs. Application dependencies are kept up to date, and changes are reviewed before they reach production.

We rely on third parties for payment processing, push notifications, cloud storage, messaging and AI processing. The Privacy Policy names each of them and what they receive. We contract with them to protect the data they handle for us and to use it only on our instructions.

We monitor our systems continuously for errors, unusual load and suspicious behaviour. Requests carry a correlation identifier so a single event can be traced across services when we investigate.

• Security events, such as a token presented from an unexpected device, are logged in a structured form and counted so we can see a pattern rather than a single line.
• Our interfaces are rate limited to blunt automated abuse and credential-guessing.
• Money movements are reconciled by automated checks that hold or flag anything that does not add up, rather than letting it pass quietly.
• Logs are retained for a limited period for security and debugging, and access to them is restricted. We avoid writing personal data into logs.

We have an internal process for handling security incidents: contain the problem, work out what happened and what was affected, fix the cause, and notify the people who need to know.

Breach notification. Where personal data has been accessed or acquired by someone unauthorised, we will notify the Data Protection Commission of Ghana and the affected users, as required by the Data Protection Act, 2012 (Act 843). We will do this without undue delay once we have confirmed what occurred. Our notice will describe what happened, what data was involved, what we have done about it, and what you should do — for example, change a password or watch for a specific kind of scam.

We will tell you directly where we can reach you. Where we cannot, or where a very large group is affected, we will also publish a notice on this website.

If you believe you have found a security flaw in Uven, tell us at security@uven.app. Please include what you found, how to reproduce it, and what an attacker could do with it. We aim to acknowledge a report within three business days and to keep you updated until it is closed.

While you are testing, please:

• Use only accounts and data that belong to you.
• Stop as soon as you have confirmed a problem — do not read, change or remove another person's data.
• Do not run denial-of-service tests, send bulk spam or phishing, or attack our staff or our suppliers.
• Give us a reasonable chance to fix the issue before you make it public.

If you follow this policy in good faith, we will treat your report as authorised research, work with you on it, and will not pursue legal action against you for it. We do not currently run a paid bug bounty, but we will credit researchers who ask to be credited.

If you think your own account has been accessed by someone else, do not wait: change your password, end your other sessions, and contact security@uven.app or our support team straight away.

Most account compromises we see start outside our systems. These steps prevent nearly all of them:

We update this policy as threats and our systems change. The date at the top shows when it last changed, and we will tell you in the app or by email about a change that materially affects you.

This Security Policy is governed by the laws of the Republic of Ghana, including the Data Protection Act, 2012 (Act 843).

If you have a complaint, email security@uven.app or privacy@uven.app first. If your complaint concerns a booking, a payment or a provider, use the dispute process in our Terms of Service: raise it with the other party through Uven chat, then submit a formal dispute claim through the Platform for Uven to decide. You can complain to the Data Protection Commission of Ghana at any time, and any claim that cannot be resolved through those routes is subject to the courts of Ghana.