Privacy policy

The state of the product

Schoolamer is not yet in service. No school is using it to collect fees, no live payment has been taken, and no message has been sent to a parent. We are publishing this policy now, before any of that happens, because a school deciding whether to trust us with its families' data should be able to read what we would do with it first — and because our WhatsApp integration cannot be reviewed by Meta without it.

This document is written in the present tense about the software as it is built. Where something is designed but not yet switched on, it says so.

What this policy covers

It covers personal data processed by the Schoolamer school management application, which runs at schoolamer.app, and the handful of payment-link pages a parent may open there.

This website — schoolamer.com — is not the application. It is a set of static pages describing the product. It has no login, holds no session, sets no cookies, runs no analytics and stores nothing about you. Reading this page creates no record of you beyond the ordinary server logs described under processors.

Who we are

Schoolamer is operated by Qovah Technologies, registered in Ghana with the Registrar-General's Department under Business Registration Number BN389841026. Its registered office is 4th Street, Ablekuma North, Accra, Ghana.

In this policy, “we” and “Schoolamer” mean Qovah Technologies. “A school” means a school that holds an account with us. “The app” means the application at schoolamer.app.

The school's role, and ours

The factual arrangement is this. A school decides which pupils to enrol, what to record about them, which guardian is responsible for a fee, what the fees are, and who is messaged. We supply the software that holds those records and carries out those instructions. We do not decide what a school collects about a child, and we do not use a school's pupil, guardian or payment records for our own purposes.

For data about a school's own staff accounts and about the school's subscription to us, we act for ourselves: we decide what an account needs in order to exist and be billed.

Children's data

A school using Schoolamer records personal data about children, and we hold it on the school's behalf. For each pupil that means their first and last name, the admission number the school gave them, the stage and year they are in, which class they sit in, whether they are a day or boarding pupil, whether they are enrolled, withdrawn or graduated, which adults are registered as their guardians, and — the part that matters most to a family — every invoice raised against them, every payment made, and what they still owe.

We think two things are worth stating plainly rather than leaving in a list.

First, what we deliberately do not hold about a child. There is no date of birth, no age, no sex or gender, no photograph, no home address, no national identification number, no nationality, no religion or ethnicity, no medical, health, allergy or disability record, no special-educational-needs flag, no biometric data, no attendance record, and no marks, grades or report cards. These are not fields we have chosen to leave empty — they do not exist in the system, so they cannot be filled in, exported or leaked. A pupil's own email address is the one optional contact detail, and most pupils have none.

Second, that a fee balance is sensitive even though no law lists it. What a family owes a school is, in practice, one of the most socially damaging facts a school holds about that family. We treat it accordingly: it is visible to the staff whose job is to collect it and to the teacher of that child, not to everyone who can sign in, and a payment link reaches one child's invoice and no other.

Children do not interact with Schoolamer. There is no pupil login, we do not market to children, and we do not profile them or make automated decisions about them.

One exception to the minimalism above deserves naming, because it is the one place a school can put data about a child that we did not ask for. When a school imports its pupils from a spreadsheet, the uploaded file is stored as submitted, including any columns we do not recognise and therefore never read. If a school's own spreadsheet carries dates of birth, addresses or medical notes in extra columns, those land in that stored copy. A school can avoid this by removing columns it does not need before importing.

What is held, and about whom

There are three groups of people whose data the app holds, plus the school itself.

Pupils

As set out under children's data: name, admission number, stage and year, class membership for each academic year, day or boarding, enrolment status, optional email address, the guardians linked to them and each guardian's relationship, and their full invoice, payment, discount and credit history. Where a pupil is given an individual fee arrangement — a scholarship or a family on particular terms — the fact that they were singled out for it is recorded.

Guardians and parents

First and last name, a mobile number in international format, and optionally an email address. That is the whole contact record: no address, no date of birth, no national identification number, no occupation, no second number.

In addition, and attached to that record:

• Which pupils they are a guardian of, the stated relationship, and which of them is the paying guardian.
• Every message we attempted to send them: the channel, the category, the phone number or email address it went to as it read at the time, when it was sent, whether it was delivered, failed or was blocked, and the message identifier our provider returned. We do not store the text of the message — it is rendered at send time from a fixed template and the figures involved — but we do store those figures, so a message can be reconstructed.
• A record of consent to be messaged on each channel, who on the school's staff recorded it, when, any note they added as evidence, and, if it was later withdrawn, when and by whom. See messages to guardians.
• Payments they made or that were recorded against them, and payment links issued to them.

Guardians have no account and no password. There is nothing for a parent to log into, and that is a deliberate design decision rather than a feature not yet built.

School staff

Name, email address, whether that address has been confirmed, and a securely hashed password — we never hold a readable password. If a school signs in with Google instead, we hold the tokens that sign-in produces.

• Which school they belong to and their role in it, which classes they are assigned to teach, and the invitation that brought them in, including the email address it was sent to.
• Sign-in sessions, which include the IP address and browser user-agent recorded when the session was created. This is the only place the product stores an IP address.
• An audit trail of consequential actions they took — recording or reversing a payment, adjusting an invoice, generating invoices, importing pupils, changing a colleague's role, changing settlement details — stamped with their name and role as they read at the time. This trail is deliberately kept intact even after the record it describes is deleted, which is why it holds a copy of a pupil's name and admission number as free text. It cannot be edited, by us or by the school.

The school as an organisation

The school's name, and the details needed to pay it and to bill it: the bank or mobile-money account its fees settle to, including the account number in full and the account holder's name as the payment provider resolved it; the commercial terms agreed for transaction fees; its subscription plan, status and billing history; and, if it pays us by card, the card's last four digits, brand and expiry together with a reusable payment token held by our payment provider. We never hold a full card number, a security code, or a mobile-money PIN — for a school or for a parent.

What it is used for

Each category is held for a stated job, and not used for anything else:

• Pupil and guardian records — to produce correct fee invoices, to match payments to the right child, to tell the responsible guardian what is owed, and to give the school its register and its accounts.
• Guardian contact details — to send fee notices, payment links, receipts and corrections for that guardian's own children.
• Financial records — to keep the school's fee accounts, to reconcile what the payment provider settled, to handle reversals and refunds, and to leave an auditable trail.
• Staff accounts and sessions — to let the right people sign in, to limit what each can see, and to attribute actions that move money.
• School and subscription records — to settle fees to the school's own account and to bill the school for its subscription.
• Aggregate counts and totals — to run our own business, for example to know how many pupils a school's subscription should be billed on. These are counts and sums, not records about identifiable people.

We do not sell personal data, we do not share it with advertisers, we do not use it to train machine-learning models, and we do not make automated decisions that have a legal or similarly significant effect on anyone.

The basis for processing it

The companies that process it with us

We do not run our own servers. These are the companies that hold or handle personal data in order for Schoolamer to work. Each is listed with what actually reaches it.

Convex — database and application backend

Holds effectively all of it: pupil records, guardian records and contact details, staff accounts, sessions, invoices, payments, messaging records, consent records, the audit trail, and the stored copies of imported spreadsheets. Convex is where the application runs and where the data lives.

Cloudflare — hosting, content delivery and server logs

Serves both the application and this website, so it handles every request made to either, including a parent opening a payment link. That means it sees IP addresses, browser user-agents and the addresses requested. We have request logging switched on, so Cloudflare retains those logs for us.

Cloudflare — transactional email

Sends the email the product sends: fee notices and payment links to guardians, payment receipts, email-address confirmations and staff invitations, and billing notices to school administrators. Cloudflare therefore receives the recipient's address and the message itself, which for a fee notice contains the guardian's name, the child's name, the invoice number, the amount outstanding and the payment link. It also keeps a copy of that message for about a week — see where it is stored.

Paystack — payments

Takes the payment. When a guardian opens a payment link and pays, they are handed to Paystack's own checkout, and Paystack — not us — collects the card details or mobile-money authorisation. What we send Paystack is the amount, the currency, our own reference for the payment, the school's settlement account, and an email address for the receipt. We deliberately do not send a parent's phone number. Paystack also holds the school's own settlement account details, which it verifies, and the school's business name. Paystack settles each school's fees directly to that school's account.

Meta Platforms — WhatsApp messages (not yet switched on)

Intended to deliver fee notices and receipts over WhatsApp. This is built but not operating: it requires message templates approved by Meta in advance, none has been approved, and no message has ever been sent. When it is switched on, Meta will receive the guardian's WhatsApp number and the values filled into the template — which include the guardian's name, the child's name, the invoice number, the amount outstanding, the school's name and the payment link. All schools would send through a single Schoolamer WhatsApp business number.

Google — sign-in for school staff, if enabled

Where a school's staff sign in with a Google account rather than a password, Google handles that sign-in and we receive the resulting tokens and the account's name and email address. This applies to staff only; parents have no account. Not yet supplied: decide whether Google sign-in is offered in production ⟵ to supply

GitHub — source code and deployment

Holds the software's source code and runs its deployments. It is not sent pupil, guardian or payment data in the ordinary course of operating the product.

Who is not on this list, and might be expected to be. We use no analytics or product-tracking service of any kind — no Google Analytics, no tracking pixels, no session recording — on either the application or this website. We use no third-party error monitoring. We use no SMS provider. We use no third-party file or document storage. Nothing uses a third-party font or script loaded from someone else's servers.

A feature that would render pupils' report cards as PDFs through Cloudflare's browser rendering service has been designed but not built. If it is built, it will put a child's marks through that service, and this policy will be updated to say so before it ships.

Payment links, and what a forwarded link shows

A parent pays through a link sent to them. It is worth being precise about what that link is, because it is the one part of the system a person can hold without signing in.

• Each link is a long random token that reaches exactly one invoice. It carries no account access, exposes no internal identifiers, and cannot be altered to reach another child's invoice.
• It expires 30 days after it is issued, and the school can revoke it at any time and issue a new one. The number of payment attempts it will accept in a window is limited.
• We store only a one-way digest of the token, never the token itself. A copy of our database would not let anyone open a payment link.
• Anyone holding the link can see what it shows. That is the school's name, the pupil's name and admission number, the term, the invoice number and due date, the invoice's line items and amounts, what has been paid, and the balance. We assume links get forwarded into family WhatsApp groups, because they will be. Nothing on that page reveals another child, and nothing reveals a contact detail — but it does identify one named child and what their family owes. A school should treat the link as it would treat a paper fee statement.
• Where a guardian gives no email address, the receipt address we hand the payment provider is a non-deliverable address derived from our own payment reference, because the provider requires the field. No mail is delivered to it.

Messages to guardians

A school records, against each guardian and each channel, that it has that family's consent to be messaged. A named member of staff records it with a date and may attach a note as evidence. Nothing is sent without such a record, with the one exception below, and a guardian's consent can be withdrawn, which stops reminders.

The exception is receipts. A payment confirmation, or a notice that a payment was reversed or corrected, is sent even where consent was withdrawn or was never recorded. Our reasoning is that a family that has just paid money is entitled to be told it arrived, and withholding that would do them harm rather than protect them. Every time that exception is used, it is logged. Fee reminders remain blocked.

Who can see what

Within a school, access to a family's contact details is deliberately narrow. A parent's phone number is visible to the staff whose job is collecting that fee, and to the teacher assigned to that child's class — the class assignment itself grants it. Other roles, including the registrar, see pupil names and class lists without contact details. This is enforced where the data is read, not by hiding it in the interface.

Across schools, the application gives Schoolamer's own staff counts and totals only. It will not show us an identifiable pupil, guardian or payment record belonging to a school, and that limit is enforced in the software rather than by policy. The practical consequence, which we accept deliberately, is that supporting a school means asking the school what it sees rather than looking at its data ourselves.

That is a statement about the application, and it is not the whole picture. We would be misleading you if we stopped there. Schoolamer is software we operate, and operating it means holding the administrative credentials to the database it runs on. Those credentials are not bound by the permission rules described above: a person holding them can reach a school's records directly, including records the application would refuse to show them. The same credential is held by our automated deployment pipeline, because publishing new code requires it.

This is true of essentially all hosted software, and it is the reason the paragraph above is worth less than it first appears. What we can honestly say is this: that access exists, it is limited to the people who operate the service and the deployment pipeline, the credential is scoped to a single deployment and held as a secret rather than shared around, and reaching a school's data that way is not something the product makes routine or convenient. We have not had those controls independently audited, so we are not calling them more than they are.

A school's records remain the school's. We do not share one school's data with another, and we do not disclose personal data to anyone outside the processors listed above except where we are legally required to, in which case we will tell the school unless the law forbids it.

How long it is kept

While a school is using Schoolamer, its records are kept so the school can use them. When a school stops using Schoolamer, its access is suspended, its data is kept so it can be exported, and then:

• Personal data — pupils, guardians, contact details — is deleted 90 days after the school leaves. The 90 days exist to give the school time to export its records, not as a reason to keep them.
• Financial records are kept for six years. Invoices, payments and adjustments are the records a school may be required to produce for tax or audit purposes, and deleting them early could destroy something the school is obliged to have.

The asymmetry is the point: holding children's family data for no longer than necessary pulls one way, and keeping financial records pulls the other, so the two have different clocks and both run from the date the school left.

Two honest caveats about those numbers.

The first is that six years is our own reading, not legal advice. It is the span over which tax and audit rules generally reach back. We have not been advised on it and we are not citing a statute for it, because we do not have one to cite. If the period turns out to be legally prescribed as something else, that is the number we will correct.

The second is that the audit trail is designed to outlive what it describes. When a pupil's record is deleted, entries recording who recorded a payment or changed a status remain, and they contain a copy of that pupil's name and admission number as text. This is deliberate — an audit trail that dissolves is not one — but it means deletion of a pupil record is not the erasure of every mention of that pupil.

Where it is stored

None of it is stored in Ghana, and none of it can be. That is the honest headline, and it is not a choice we made casually — no provider in this stack offers storage in Ghana. Convex offers four regions, none in Africa. Cloudflare can confine certain data to the EU or the US and nowhere else. WhatsApp's only African storage region is South Africa. A school's records therefore leave the country, and you should know that before you decide to use us.

What each provider's own documentation says, and where it says nothing:

Convex — the database holding nearly everything

Convex runs on Amazon Web Services and lets a region be chosen when a deployment is created, from US East (N. Virginia), Europe (Ireland), Asia Pacific (Sydney) and Canada (Central). A deployment's region cannot be changed afterwards. Data at rest is encrypted with AES-256. Not yet supplied: the region our production deployment was created in ⟵ to supply

Convex publishes a subprocessor register, and it names Amazon Web Services as its infrastructure provider. So AWS holds this data too, indirectly — Convex is our processor, and AWS is Convex's. The register does not give a country for it: it states the location of that processing is as determined by the customer's selection of deployment region, which is the same unanswered question as the gap above. The register also names a long list of further subprocessors, almost all in the United States, that Convex uses to run its own business — support, billing, observability and analytics tooling.

Cloudflare — serving the site and the app

A request is handled at whichever of Cloudflare's data centres is nearest the person making it. The site and the app store nothing at rest with Cloudflare — there is no database, file store or key-value store attached to either Worker. What is retained is the request logs, for up to seven days, and those can contain IP addresses and the addresses requested. Cloudflare does not document a country for them: by default such logs may be held in its core data centres anywhere in the world, and confining them would require a paid add-on offering only the EU or the US.

Cloudflare — sending email

This is the part we would most want a school to notice. Cloudflare retains the full content of each message it sends for about seven days — the body, the headers and any attachment — as a preview feature that is switched on by default for a new sending domain. For a fee notice that content includes a guardian's name, a child's name, the amount outstanding and the payment link. Cloudflare publishes no data-residency page and no retention policy for this product, which is in beta, so we cannot tell you which country those copies sit in.

Paystack — taking payments

Paystack's privacy policy gives Amazon Web Services with servers in Ireland as an example of where it stores data, and its published sub-processor list names Ireland for its cloud provider, alongside providers in Nigeria, the United Kingdom, Germany and the United States. It does not state a region for the vault that holds card data specifically, so we are not going to name one. Paystack is certified PCI DSS Level 1 as a service provider and is a Stripe company.

Meta — WhatsApp, once it is switched on

Meta documents a maximum retention of 30 days for message data sent through the WhatsApp Cloud API, and says such messages are encrypted at rest with Meta holding the keys — so this is not end-to-end encryption. By default the messages are processed in Meta data centres with no country named. Regional storage can be requested for a business phone number, from a list of fourteen countries that does not include Ghana; South Africa is the only African option. Even then, message content may pass through Meta data centres elsewhere for up to an hour before being deleted from them.

How it is protected

These are measures that exist in the product today:

• Everything travels over encrypted connections.
• Passwords are stored only as a secure hash, with a minimum length of twelve characters.
• Payment credentials — card numbers, security codes, mobile-money PINs — are collected by our payment provider on its own pages and never reach our systems.
• Payment links and staff invitations are stored only as one-way digests, so a copy of the database cannot be used to pay anyone's fees or to join a school. Staff invitations expire after 48 hours and can be used once, by the address they were sent to.
• What a signed-in member of staff may read is checked where the data is read, so a gap in the interface cannot become a gap in access.
• Actions that move money or change a pupil's status are recorded in an audit trail that cannot be edited.
• Messaging is rate-limited per school and per family, so a fault cannot turn into a flood of messages to a parent.
• A school's settlement account number is masked wherever it is displayed alongside other information.

No system is perfectly secure. If a breach affects a school's data, we will tell that school. Not yet supplied: breach-notification procedure, and the timescale committed to, once counsel confirms what Act 843 requires ⟵ to supply

Your rights, and how to use them

Ghana's Data Protection Act gives people rights over their personal data, including to know what is held about them, to have inaccurate data corrected, to object to processing, and in some circumstances to have data deleted.

If you are a parent or guardian, the fastest route is your child's school: the school entered the records, the school can correct them, and the school decides what it holds. If you would rather come to us, or the school does not resolve it, write to us at the address below and we will work with the school.

If you are a member of school staff, your name, email address and session history are yours to ask about, and a school administrator can change your role or remove your access.

Requests about personal data should be sent to support@schoolamer.com, or by post to Qovah Technologies, 4th Street, Ablekuma North, Accra, Ghana.

You may also complain to Ghana's Data Protection Commission about how your personal data has been handled.

Cookies

This website sets no cookies at all — no analytics, no advertising, no preferences. There is nothing here to consent to.

The application sets one kind of cookie: the session cookie that keeps a member of school staff signed in. It is scoped to the application's own host, it is necessary for signing in, and there is no advertising or analytics cookie anywhere in the product. Parents are not asked to sign in and a payment link does not require a cookie.

Registration with the Data Protection Commission

Ghana's Data Protection Act requires data controllers to register with the Data Protection Commission.

Qovah Technologies is not registered with the Commission. We are not going to dress that up: there is no application number to quote, no date to point at, and we are not claiming the process is under way.

What makes that publishable rather than reckless is the state of the product: Schoolamer holds no school's data today. We are treating registration as something that has to be settled before a real school's pupil and family records are entrusted to us, not afterwards.

We would rather publish this and be asked about it than publish a policy that quietly omits it. When the position changes, this section will say so and will carry the number and the date.

Changes to this policy

When this policy changes materially we will update the date at the top of the page and, if the change affects schools, tell them. Because several of the questions above are genuinely open, this document should be expected to change as they are answered — the visibly marked gaps are the places where that will happen.

Contacting us

For anything about this policy or about personal data, write to support@schoolamer.com, or to Qovah Technologies, 4th Street, Ablekuma North, Accra, Ghana. For anything else, see the contact page.