A Till That Cannot Store a Card Number
The card-data question every point-of-sale buyer should ask is not how the data is encrypted. It is whether there is anywhere to put it. Our payments table has seven columns and none of them is a card — which is the strongest position available, and it has a price we would rather state than let you find.
Ask a point-of-sale vendor how they protect card data and you will get an answer about encryption. It is the wrong question, or rather it is the second question, and asking it first lets everybody skip the first one. The first one is: what do you keep? Encryption is a control over data you hold. The strongest position is not holding it, and that is a schema question with a yes-or-no answer that anybody can check in about a minute.
This is a North American post because the card-brand standard is where the sharpest version of this question gets asked, and because in the United States and Canada a small merchant is far more likely to meet it through an acquirer questionnaire than through anything a government sends them. But nothing here is specific to either country. The schema is the schema everywhere.
What the standard actually asks, and what it is not
The Payment Card Industry Data Security Standard is not law. It is a contractual standard published by a council the card brands founded, and it reaches you through your acquiring bank and your merchant agreement rather than through a statute. That distinction matters commercially: the consequence of falling short is not usually a prosecution, it is your acquirer, your fees and in the worst case your ability to take cards at all.
Two of its rules do most of the work for a system like ours. Sensitive authentication data must not be retained after the payment is authorised — the full contents of the magnetic stripe or chip, the verification value printed on the card, and the PIN or its encrypted block. Not retained even encrypted. And where the card number itself is stored, it has to be rendered unreadable wherever it is kept.
The consequence people miss
Both rules are about data you have. Neither of them applies to data you never took. That is why the design question comes before the security question: every control, every rotation policy, every key-management argument and every line of an assessor's questionnaire follows from the answer to "what is stored", and the cheapest answer to maintain is nothing. A system that cannot hold a card number does not need a good story about how it protects one.
To be exact about what we are not saying: we make no compliance claim for this product. Scope is decided by an assessor looking at an entire environment — the terminal, the network, the people, the processes — and not by reading one table definition. What follows is a description of a schema, which is ours to give. The status is not.
Our payments table, in full
A point-of-sale payment in our product is a row with seven meaningful columns, and it is short enough to list without summarising.
| Column | What it holds |
|---|---|
| The sale | Which sale this payment belongs to |
| The cash session | Which till session it was taken in, so a drawer can be reconciled |
| The method | One of three values: cash, mobile money, card |
| The reference | The M-Pesa code or card authorisation code the tender was settled with — a pointer to the processor’s record, not card data |
| The amount | How much |
| The date | When |
| Actor and timestamps | Who recorded it and when the row was written |
That is the whole table. There is no card number column, no cardholder name, no expiry, no verification value, no truncated last four and no token. The reference holds an authorisation code, which means nothing to anyone without access to the processor. It is free text, up to a hundred characters, so it is the one field a careless cashier could put a number into — train the till that it takes the short code on the slip and nothing else. And the method is not a free-text field where somebody could put one — it is constrained at the database level to exactly three values, so the column will refuse anything else rather than accept it and hope.
The question is not how the card number is protected. It is that there is nowhere to put one.
We went further than reading that one table before writing this, because a claim like the above is worth nothing if a card number is sitting in some other corner. Every column in the database was scanned for the obvious patterns — card, PAN, verification value, cardholder, last four, expiry, token. Two places matched, and they are worth disclosing precisely rather than leaving for somebody to find.
The two that did match, and why they are not the till
The first sits on the organization record and relates to our own subscription billing — you paying us, not your customer paying you. It holds the last four digits of the card and its brand, which arrive from the payment processor that takes the payment, so that a billing screen can say which card is on file.
The second is saved payment methods for your customers, used to charge a recurring invoice automatically. When a customer pays one of your invoices online by card, the processor (Paystack) returns a reusable authorisation token, and we keep that token — encrypted at rest and never shown in any screen or API response — alongside the last four digits, the brand and the expiry month and year, so a screen can say which card will be charged. We never see or handle the full card number or the verification value: the card is typed into the processor’s page, not ours, and only the token comes back. That is card-on-file in the sense the standard cares about, and it is the processor that holds the card.
The last four digits, the brand and the expiry are, deliberately, the things the standard treats least restrictively — a truncated number is not the number — and a processor token is useless to anyone without the merchant’s processor account. We are naming them anyway. A post that says "we store no card data" while those columns exist is the kind of half-true statement this corpus exists to avoid, even when the omission would be defensible.
What storing nothing costs, which is the part vendors leave out
Here is the trade, and it is a real one. A card payment in our product records that a card was used, for how much, in which till session, at what time, and — if the cashier types it — the authorisation code from the slip. It does not receive a terminal identifier or a processor transaction reference from the terminal itself, because the till is not connected to the terminal: the card is taken on a standalone machine and the result is keyed in.
So when your acquirer's settlement arrives — a list of card transactions with their own references and their own timings — the authorisation code is the one field that can match, and only where the cashier keyed it. Reconciling the two is still done by a person: by reference where there is one, and by amount and time where there is not, with the usual difficulty that produces — two sales of the same value in the same afternoon, a refund that nets against a sale, a transaction authorised on one day and settled on the next.
That is not a security problem and it is not a compliance problem. It is an operations problem, it lands on whoever closes the till, and it is the direct price of a till that is not wired to its terminal. A reference captured by the terminal rather than typed, and a settlement file imported and matched against it, would fix the reconciliation without weakening anything. That is the honest thing to want from us next.
Questions worth asking a point-of-sale vendor
Show me the table your payments are stored in. All the columns.
What you will hear
A short list you can read in one screen, with nothing card-shaped in it.
How to read it
Ask for the columns, not for a description of the security. Anybody can describe security. The column list is a fact and it takes a minute.
Is the payment method a fixed set of values or free text?
What you will hear
A fixed set, constrained in the database.
How to read it
A free-text method column is somewhere a card number can end up — not by design, but because a field that accepts anything eventually receives everything.
What is the longest-lived thing you keep about a card transaction?
What you will hear
Either nothing beyond the amount and the method, or a processor reference and a truncated number, named exactly.
How to read it
The answer "it is encrypted" is a non-answer to this question. Encrypted data is still data you hold, and the question was what you hold.
How do I reconcile your card takings against my acquirer's settlement?
What you will hear
A shared reference on both sides, or a straight admission that it is manual.
How to read it
This is the question that finds out whether "we store nothing" was a design decision or an absence. Ours is a reference the cashier keys from the slip, matched by a person — partway there, and we would rather say so.
Do you store anything about MY card, as your customer, and where?
What you will hear
A direct answer. Almost every vendor stores something for their own billing.
How to read it
A vendor who has not thought about the difference between your customers' card data and your own has not thought about this carefully. Ours are named above: last four and brand for our own billing, and a processor token with last four, brand and expiry for your customers’ saved cards.
What AWRA OpsHub does today
- A point-of-sale payments table with no card column of any kind — no number, no name, no expiry, no verification value, no truncated digits, no token.
- A payment method constrained at the database level to three values, so a number cannot be typed into it.
- A reference on each till payment for the M-Pesa code or card authorisation code it was settled with.
- Saved cards for your customers, for automatic charging of recurring invoices — the processor’s reusable token, encrypted at rest, plus last four, brand and expiry, and never the card number or verification value.
- Till sessions, so a drawer can be counted and reconciled against what was recorded in it.
- A live tax-authority integration on the sales side for another market, which puts a receipt number, a signature and a machine-readable code on a document — evidence that authority-facing work does get finished here.
More we can add to your workspace
- A terminal-captured reference and an acquirer settlement import matched against it, so card reconciliation stops being done by hand.
- A card-present integration in the United States or Canada. A terminal driver and a processor connector for either market, which is a scoped build against a published interface.
Where we point you to a specialist
- The card-brand standard is a contractual matter between you, your acquirer and the brands. We will describe exactly what our software stores; what your obligations are, and whether you meet them, is a question for them and for you.
- We will not call this product compliant, ready or out of scope. Scope is an assessor's determination about an environment, not a vendor's claim about a table.
- We have yet to serve a customer in the United States or Canada, and we would rather you heard that from us.
A settlement import matched against the reference already stored on each card payment — not card data, a pointer — so that till takings reconcile against an acquirer settlement automatically rather than by hand. That is the item this post identifies in ourselves and it is small. A terminal or processor integration for a named North American acquirer is a genuine build and we would scope and price it on the usual terms: a written specification, a timeline and a price agreed before anything starts, and a date in a quote rather than on a public page. Card-on-file for your customers already runs through Paystack, with the processor holding the card; another processor for it is a connector, scoped the same way. The precedent that we finish payment and authority work is Kenya, where mobile money and a live tax-authority integration both run in production today.
The manual reconciliation is the price of the schema above, and we would rather publish it beside the strength than let the strength read as an unqualified win.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsOur take
Ask for the column list. It is the fastest question in a point-of-sale evaluation and almost nobody asks it, because the conversation is set up to be about encryption instead. Ours has no card in it, which is the answer to want — and because the till is not wired to the terminal, our card takings do not reconcile themselves against your acquirer, which is the part we would rather you heard from us.
If you take cards over a counter
Tell us which acquirer and which terminals you use and we will tell you plainly what would have to be built, and what would still be manual afterwards.
See how point of sale works