Privacy Policy

1. Who is responsible for your data

The controller of the personal data described here is [LEGAL ENTITY NAME], a [LEGAL FORM, e.g. SARL] registered in Cameroon under RCCM number [RCCM NUMBER AND REGISTRY TOWN], taxpayer number [NIU TAXPAYER NUMBER], with its registered office at [REGISTERED OFFICE ADDRESS, CAMEROON]. "We" and "us" mean that company throughout.

For anything about your data, write to [DATA PROTECTION CONTACT EMAIL]. That address reaches the person responsible for data protection here, and it is the address to use for a request to see, correct, export or delete your data. Use it rather than the general support address, so that a rights request is never lost in a queue about bookings.

This policy covers this site, the booking service on it, and the emails and WhatsApp messages we send about a booking. It does not cover an airline's own site, an operator's own app, or anywhere else a link takes you.

We are established in Cameroon and not in Europe. Where the General Data Protection Regulation reaches us because we offer this service to travellers in the European Economic Area, it also requires us to name someone inside that Area who can be written to in our place. Our representative in the European Union is [EU REPRESENTATIVE, NAME AND ADDRESS]. For the United Kingdom, whose rules require a separate one, it is [UK REPRESENTATIVE, NAME AND ADDRESS]. Naming them takes nothing away from you: you may write to them or to us, and either reaches us.

One thing you are entitled to know rather than discover. Cameroon's Law No. 2024/017 on the protection of personal data makes processing subject to the prior authorisation of a Personal Data Protection Authority that the same law creates, and the decree establishing that Authority had not been issued at the date shown at the top of this page. The authorisation therefore cannot yet be applied for. We will apply as soon as it can be, and this clause will say so when we have.

2. What we collect

This is the whole of it, taken from what this service actually records rather than described in general terms.

• Your account. A WhatsApp number, an email address, or both, and whether each has been confirmed by a one time code. Optionally a first and last name. Your language, your theme, your clock preference and whether you want flight reminders.
• Sign in. A one time code is stored only as a cryptographic digest, never as the code itself, along with which channel it was sent to and when it was used or expired.
• Sign in with Google, if you use it. Google returns your Google account identifier, your email address, whether Google has verified that address, and your name. We keep the identifier so the button works next time, and the email address as an identifier of your account like any other. We never receive a password and we get no access to anything else in your Google account.
• Error reports. When something breaks, the platform sends the error to our monitoring service with the technical detail needed to fix it: the page, the exception, the code path. It carries your account's database identifier and role, and the booking reference if the error happened inside a booking. It is configured never to attach your name, email, phone or any request parameter that has been marked sensitive.
• Your sessions. When you sign in we record the IP address and the browser user agent of the device that signed in, and we set one signed cookie. This is what keeps you signed in, and what lets you see and end a session you do not recognise.
• Passengers. For every person on a booking: given names, surname, date of birth, gender, nationality, passport number and passport expiry date, and for the lead passenger a contact email and phone number. All of it as printed on the passport, because an airline will not accept anything else.
• Your bookings. The itinerary, the fare, the airline, the reservation record locator, the ticketing deadline, the flight segments, the e ticket numbers, and the state the order is in.
• Payments. The Mobile Money number of each payer, the amount, the time, the operator's transaction reference, and the outcome. We never see or store a PIN, and we do not hold card numbers because we do not accept cards.
• Refunds. The same, in the other direction, including the reason a refund was made.
• Messages. The notifications we sent you about a booking, what they said, and whether you have read them.
• The audit trail. Every change of state on an order, an invoice, a payment, a refund or a reservation, recorded with who made it and when. It has its own clause below.

We do not collect special category data. A passport number is a national identification number rather than a special category of data, but it is one of the most sensitive things you can be asked for, and it is treated accordingly here. We do not ask for special assistance requests or meal preferences, because those would reveal health or belief and would need your explicit consent; if we ever offer them, they will be asked for separately and you will be told why.

Passenger details are not optional in the way a preference is. They are what the airline requires before it will issue a ticket and what a border requires before it will accept a passenger. If you do not give them, we cannot book the flight. That is the only consequence: nothing else changes, and nothing is held against you.

3. Why we use it, and on what legal basis

Two laws can govern the same processing here, and they do not offer the same list of legal bases. Cameroon's Law No. 2024/017 makes your consent the rule, and lets us do without it only where a legal obligation, a task in the public interest, or the protection of someone's life requires it. The General Data Protection Regulation, which reaches travellers in the European Economic Area, adds performance of a contract and legitimate interests. We name the basis under each rather than quoting whichever is more convenient.

That is why this service asks rather than assumes. You consent when you hand us an identifier and ask for a code, when you enter passenger details, and when you approve a payment. You can withdraw a consent at any time and the clause on your rights says how. Withdrawing it after a ticket has been issued cannot undo the ticket: the airline holds those details too, in its own right, and we cannot reach into its systems.

• Creating and holding your account, and signing you in. Cameroon: your consent, given when you hand us an identifier and ask for a code. GDPR: performance of a contract with you.
• Searching fares, holding a reservation, issuing a ticket and delivering it. Cameroon: your consent, given when you enter the passenger details and confirm the booking. GDPR: performance of a contract with you. This is the purpose that needs the passport details, and without them there is no ticket.
• Taking payment, applying it to your invoice, and refunding it when a ticket cannot be issued. Cameroon: your consent, and our legal obligation to keep accounting records. GDPR: performance of a contract, and compliance with a legal obligation.
• Telling you what is happening to your booking. Cameroon: your consent. GDPR: performance of a contract with you.
• Knowing who we are dealing with, and reporting a transaction that looks suspicious. Both: a legal obligation, this one from the CEMAC rules against money laundering and terrorist financing, which name travel agencies among the professions they bind.
• Keeping the audit trail and reconciling money against tickets. Both: our legal obligation to keep commercial and accounting records, which is also what lets us prove where a payment went.
• Keeping connection and traffic data. Both: a legal obligation, from Cameroonian law on cybersecurity, which requires whoever runs an information system to retain them.
• Keeping the service secure and defending it against fraud and abuse, including the rate limits on search and sign in and the automated abuse check on the sign in and sign up screens. Cameroon: our own security obligations under the cybersecurity law. GDPR: our legitimate interest, and yours, in a service that is neither used to launder money nor to book with someone else's. Fraud prevention is named in the Regulation's own recitals as a legitimate interest, and defending a login form is that.
• Signing you in with Google, when you choose that button rather than a code. Cameroon: your consent, given by pressing it. GDPR: performance of a contract with you, since it is one of the two ways this service authenticates the account you asked for.
• Finding out that the platform has broken, and fixing it. Cameroon: our security and availability obligations under the cybersecurity law. GDPR: our legitimate interest in a service whose failures are noticed by us rather than reported by you, which is why the error report carries an account identifier and no name.

We do not sell personal data, we do not share it for anyone else's advertising, and we do not make decisions about you by automated means that produce legal effects for you. Issuance is automatic, but issuing the ticket you asked for and paid for is the performance of your contract, not a decision about you.

4. Passport and identity data

Passport number, date of birth and nationality are encrypted at rest in our database, with keys held outside it. They are never written to an application log, and the fields that carry them are filtered out of error reports before those reports are stored.

Passport data is collected for one reason: an airline will not issue a ticket, and a border will not accept a passenger, without it. It is sent to the airline and to its distribution system for that purpose and no other.

A member of agency staff can see a passenger's details in the internal console where their role requires it, for example to correct a booking or to resolve a failed issuance. Every such access is against an account that belongs to a named person, and staff accounts are created by invitation only.

5. Payment data

Payments are collected through MTN Mobile Money. You approve each payment in the operator's own prompt, on the payer's own phone. Your PIN is never seen by this platform, never transmitted through it and never stored by it.

What we store is the paying number, the amount, the time, the operator's transaction reference and the outcome. The paying number is stored because it is the address a refund goes back to, and because an invoice settled by three relatives has to be refundable to the three of them in the proportions they paid.

A payer who is not the account holder is still a data subject here. If someone paid towards your booking from their own number, this policy covers them too, and they can write to [DATA PROTECTION CONTACT EMAIL] about their payment.

6. The audit trail

Every change of state on an order, an invoice, a payment, a refund and a reservation is recorded permanently: what changed, from what to what, when, and which account or which automated process did it. This is an append only record. It is not edited and it is not deleted when a booking ends.

It exists because money moves through this platform on your behalf. Being able to show, months later, that a payment was received at a given minute and became a ticket or a refund is what protects you in a dispute as much as it protects us. It is also what our accounting obligations require.

A request to erase your data does not erase the audit trail, and the clause on your rights explains why the law allows that. What we do instead is described there.

7. Sessions, cookies and devices

This site sets one cookie. It is called session_id, it holds a signed reference to your session and nothing else, it is marked HttpOnly and SameSite, and it expires thirty days after you sign in. It is strictly necessary: without it you cannot stay signed in, and there is no way to offer the service without it.

There is one script on this site that is not ours. On the screens where you sign in, sign up, type a one time code or ask for another, on the staff console door and on the password reset request, we load Google's reCAPTCHA. Its job is to score whether a request comes from a person or from a machine, and the only way it can do that is by observing signals from your device and from how you interact with the page, and by setting Google's own cookies on it. It runs on those screens and nowhere else: not on a search, not on an offer, not anywhere in the booking funnel, and on no page you see once you are signed in.

Apart from that check there is no third party script here at all. No analytics cookie, no advertising cookie, no tracking pixel, no Google Analytics or anything like it. We do not build a profile of you and we do not share behavioural data with anyone, because we do not collect it.

Which leaves the question of consent, and we would rather answer it than bury it in a banner. Cameroonian law and European law both require your prior agreement before information is stored on or read from your device, and both carve out what is strictly necessary to provide the service you have asked for. We rely on that carve out for two things and only two: our own session cookie, without which you cannot stay signed in, and the abuse check on the doors, which exists to stop credential stuffing and mass account creation and which is confined to the doors for exactly that reason. Asking someone to consent to being defended from an attack on their own account is the wrong shape, and a defence that can be switched off by whoever is attacking is not a defence.

That position is reasoned, and it is contested. The strictly necessary carve out was written with the site's own functional storage in mind, and a supervisory authority may well take the view that a script loaded from a third party needs consent whatever it is for. We think the security ground is the better reading for a check that never leaves the login screens, but we are not going to pretend the question is settled, and if it is decided against us we will put the check behind a choice on those screens rather than argue. If you object to it in the meantime, write to [DATA PROTECTION CONTACT EMAIL] and say so: an objection is something we have to weigh, not a form to file.

With each session we store the IP address and the user agent of the device that signed in. We keep them so that an unfamiliar sign in can be recognised, by you and by us. Signing out deletes the session record.

Our servers keep ordinary technical logs of requests, which include IP addresses. Passport data, one time codes and payment credentials are filtered out of them before they are written.

8. Who else sees your data

We share personal data only with the parties below, only with what each of them needs, and only for the purpose named. Each acts either as a processor under our instructions or as a controller in its own right, which is stated for each.

• The operating airline. It receives the passenger details, the itinerary and the contact details needed to reserve and to issue a ticket, and it decides for itself what to do with them afterwards, as a controller in its own right.
• Amadeus IT Group, whose global distribution system is how this platform reaches airline inventory. Amadeus is not our processor: it states that it is an independent controller of the traveller data in its system, and it publishes its own privacy notice, which governs what it does.
• MTN Mobile Money, as the payment operator, which receives the paying number and the amount and returns the outcome. It is a controller in its own right for the payment, and regulated as such.
• Postmark, which delivers our transactional email. It receives the recipient address and the contents of the message, as a processor.
• The WhatsApp Business API, operated by Meta, which delivers one time codes and booking notifications to a WhatsApp number. It receives the number and the message, as a processor for that delivery, and as a controller for the WhatsApp service itself under its own terms.
• Our hosting provider, which runs the servers and the database this service lives on, as a processor, and which does not access the data in the ordinary course.
• Sentry, our error monitoring service, as a processor. It receives the error reports described above: technical detail, your account's database identifier and role, and a booking reference where there is one. It is configured to send no personal identifiers of its own accord and to collect no performance traces, and the parameter filter that feeds it scrubs mobile numbers and payment party identifiers before anything leaves the server.
• Google, for the automated abuse check that guards the doors: the sign in and sign up screens, the one time code screen and its resend, the staff console sign in, and the password reset request. Nowhere else. The script it loads observes how the request behaves and scores it, which necessarily means device and interaction signals and Google's own cookies. Google acts here as our processor, on our instructions and under its cloud data processing terms, which means we answer for this and not Google: since April 2026 it no longer runs the check as a controller in its own right, and the badge on those screens no longer points you at Google's policies for it. This policy is what accounts for it.
• Google, again and separately, if you use Continue with Google. It authenticates you and returns your Google account identifier, email address, verified flag and name. It is a controller for the authentication itself.

We may also disclose data where the law requires it: to a court, to a regulator, to a tax authority, or to a border or aviation security authority whose requirements attach to your journey. We disclose only what is required and we tell you where we are allowed to.

If the business is ever sold or reorganised, personal data may pass to the acquirer, which inherits this policy and cannot quietly widen it.

That is the whole list, and it is short on purpose. This platform uses no analytics provider and no advertising network, and it is not part of anyone's audience measurement. Nobody on that list receives your data in order to sell you something, and nobody pays us for it. If the list grows, this clause grows first, before the service does.

9. Sending data across borders

A flight is an international product, so the data that books it crosses borders by nature. If you fly from Douala to Paris, your passenger details reach a European carrier because the carrier cannot board you without them.

Our own systems are hosted in Europe. Our recipients operate in the European Union, the United States and Cameroon. So data moves between Cameroon, the European Economic Area and wherever an airline or a supplier operates.

Giving us your details yourself is not, under European guidance, a transfer at all: we collect them from you directly rather than receiving them from an exporter, even though we sit outside the Area and even though the Regulation still governs everything we then do with them. What counts as a transfer is what we send onward.

For those onward disclosures out of the European Economic Area, we rely on the European Commission's standard contractual clauses with the recipient, together with an assessment of the law of the country it sits in, or on an adequacy decision where one covers that country. Cameroon is not covered by an adequacy decision, and neither is any other African country. Where we send passenger details to a carrier outside the Area for a booking you asked for and no such clauses are in place with it, we rely on that transfer being necessary to perform the booking. Amadeus sits inside the Area, in Spain, so reaching it is not a transfer out.

Two of the recipients named earlier are worth a line of their own here. Our error monitoring service is hosted in the European Union, chosen that way deliberately, so an error report does not leave the Area at all. Google is established in the United States, and for what it receives from the abuse check on the sign in screens and from Continue with Google we rely on the transfer mechanism Google makes available to its customers, being the European Commission's standard contractual clauses or whichever framework arrangement is in force and covers it on the day. We do not name one here, because that is exactly the kind of statement that goes stale; ask us and we will tell you which it is.

Cameroonian law adds a requirement of its own, in the other direction: Law No. 2024/017 makes a transfer of personal data out of Cameroon subject to the prior authorisation of the Authority named earlier in this policy, which is not yet in a position to grant one. The clause on who is responsible for your data explains where that stands.

You can ask us at [DATA PROTECTION CONTACT EMAIL] which safeguard applies to a particular transfer, and get a copy of it, and we will tell you.

10. How long we keep it

Not "as long as necessary", which says nothing. These are the periods, and where a period is long it is because a law makes it long.

• Account records: for as long as the account exists, and for one year after you close it, so that a booking made just before closure can still be answered.
• One time codes: minutes. A code expires shortly after it is sent and is destroyed once used or expired. Only the digest is ever stored.
• Sessions: until you sign out, or thirty days, whichever comes first.
• Passenger and passport details: for the life of the booking and for five years after the last flight on it, which covers the period in which a claim about the journey can still be brought. The industry rules that let us issue tickets require at least two years of e ticket records, and this is longer.
• Bookings, invoices, payments, refunds and the audit trail: ten years from the end of the financial year they fall in. Cameroonian law on electronic commerce requires an online contract above a low threshold to be preserved for ten years and made available to the customer on request, and our commercial and tax record keeping duties point the same way. This is the period that survives a deletion request, and it is the reason it does.
• Notifications: three years, so that what we told you and when can be shown.
• Connection and traffic data: ten years, because Cameroonian law on cybersecurity requires whoever runs an information system to retain them for that long. We would keep them for far less if we could.
• Application logs and error reports, which carry no passport or payment data: ninety days.
• The link between your account and your Google account, if you made one: for as long as the account exists, or until you tell us to break it, whichever comes first.

At the end of a period the data is deleted, or irreversibly anonymised where an aggregate is still needed. Because your booking record is one of the things we must preserve, you can ask us for a copy of it at any time within those ten years and we will send it.

One tension is worth admitting rather than hiding. A ten year retention duty and a data protection law built on keeping no more than necessary do not sit comfortably together, and Cameroon now has both. We have written the longer period because it is the one backed by a criminal penalty, and this clause will change if the law is reconciled or if counsel advises that we have read it too broadly.

11. Your rights, and how to use them

You have the rights below under the Cameroonian law on the protection of personal data, and, if the General Data Protection Regulation applies to you, under Articles 15 to 22 of that regulation. They are the same rights described twice, so we describe them once.

• To be told what we hold about you, and to be given a copy of it.
• To have anything inaccurate corrected. A passenger name is the one to check first, and the fastest route is to write to us before the ticket is issued.
• To have data erased, where we no longer need it and no legal obligation makes us keep it.
• To have processing restricted while a dispute about accuracy or about our grounds is resolved.
• To receive the data you gave us in a machine readable form, and to have it sent to another controller where that is technically possible.
• To object to processing we base on a legitimate interest, in which case we stop unless we can show grounds that override yours, and to object to direct marketing at any time, which is absolute.
• To withdraw a consent you gave, at any time, without it affecting what was done before you withdrew it.
• To refuse the disclosure of your data to a third party for that party's own purposes, and to be told before it happens.
• Not to be subject to a decision taken about you by automated means alone, to have a person look at it instead, and to be told the logic behind it and what it means for you. We take no such decisions today.
• To leave instructions about what happens to your data after your death, which Cameroonian law provides for by name, and to have them followed.
• To complain to a supervisory authority, which has its own clause below.

Write to [DATA PROTECTION CONTACT EMAIL]. We answer within one month, and where a request is complex or there are several of them we may take up to two further months, in which case we will tell you inside the first month and say why. If we are not going to act on a request we will say so within a month, with our reasons, and tell you how to complain and how to go to court. We do not charge for any of this. We may ask you to confirm your identity, through the same one time code that signs you in, because handing an account's data to whoever asks for it would be the worse failure.

Two limits are worth stating plainly rather than burying. Erasure does not reach the audit trail or the accounting records, because the law requires us to keep them; what we do instead is restrict them so they are used only for that legal purpose and for nothing else. And we cannot erase from an airline's systems what an airline holds as a controller in its own right: for that, the airline is the one to ask, and we will tell you where to write.

12. Children, and passengers who are not you

This service is not for children. You must be an adult to hold an account, to make a booking and to pay for one.

Children do travel, and a booking often carries the passport details of an infant or a child. Those details are given to us by the adult making the booking, who confirms that they have the authority to give them. We treat a minor's data exactly as we treat an adult's, and we ask for nothing about a minor beyond what the airline requires to carry them.

The same applies to any adult you book for. You are telling us that they know and agree. If you are named on a booking someone else made and you would rather we did not hold your details, write to [DATA PROTECTION CONTACT EMAIL].

13. How we protect it

The measures below are properties of how this service is built, not aspirations, and each of them is testable.

• Passport number, date of birth and nationality are encrypted at rest, with keys held outside the database.
• There are no traveller passwords to steal. Access to an account requires a one time code delivered to a confirmed identifier, and codes are stored only as digests.
• All traffic to this site is encrypted in transit. The session cookie is signed, HttpOnly and SameSite.
• Staff accounts are created by invitation only, hold a separate password, and see only what their role allows. A traveller account can never become a staff account.
• Sensitive fields are filtered from logs and from error reports, and the filter list names the mobile number and payment party fields explicitly rather than relying on a generic rule. Payment PINs never enter the system at all.
• The error monitor is configured off by default for personal data: it sends no identifiers of its own accord and collects no performance traces, so what leaves the server is an account number, a role and a stack trace.
• Rate limits sit in front of search, sign in and the payment endpoints, and an automated abuse check guards the sign in and sign up screens themselves.

No system is perfectly secure, and a policy that claims otherwise is not worth reading. If a breach of your data occurs, Cameroonian law requires us to inform both the supervisory authority and you immediately, with no threshold of severity to hide behind, and that is what we will do. We will also tell you what it means for you and what to do about it.

14. If you are not satisfied

Write to [DATA PROTECTION CONTACT EMAIL] first. Most things are a misunderstanding about what we hold, and we would rather fix it than be told about it by a regulator.

We acknowledge a complaint about your data within thirty days and answer it without undue delay. That is a duty United Kingdom law now places on us by name, and there is no reason to treat anyone else worse.

You can complain to a supervisory authority at any time, and you do not have to come to us first. In Cameroon, the competent authority is the Personal Data Protection Authority created by Law No. 2024/017: [THE AUTHORITY'S CONTACT DETAILS, ONCE IT IS ESTABLISHED]. If you are in the European Economic Area you may complain to the supervisory authority of the country where you live, where you work, or where the matter arose. In the United Kingdom, that authority is the Information Commissioner's Office.

15. Changes to this policy

This policy changes when what we do changes, and never quietly. A new processor, a new purpose, or a change to how long we keep something appears here first, with a new effective date at the top of the page.

Where a change materially affects you, we will tell account holders by email, on WhatsApp or in the app before it takes effect. The Terms of Service are governed by their own clause on changes.