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 six 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 six 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 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, no authorisation code and no token. 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. Two columns 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
Both sit on the organization record and both relate to our own subscription billing — you paying us, not your customer paying you. They hold the last four digits of the card and its brand, and they arrive from the payment processor that takes the payment. We never see or handle the full number; those two values come back from the processor so that a billing screen can say which card is on file.
The last four digits and the brand are, deliberately, the two things the standard treats least restrictively — a truncated number is not the number. We are naming them anyway. A post that says "we store no card data" while two columns say otherwise 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. It does not record an authorisation code, a terminal identifier, or a processor reference, because storing none of those was the same decision as storing no card data.
So when your acquirer's settlement arrives — a list of card transactions with their own references and their own timings — there is no field in our record that matches a field in theirs. Reconciling the two is done by amount and by time, by a person, 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 the position described above. A processor reference is not card data — it is a pointer that means nothing to anyone without access to the processor — and storing one would fix the reconciliation without weakening anything. We have not built it, and it is the honest thing to want from us.
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 an absence in this one respect 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 is two columns and they are named above.
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.
- 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.
What it does not do
- Any processor or terminal reference on a card payment, so reconciliation against an acquirer settlement is manual and done by amount and time.
- Any card-present integration in the United States or Canada. There is no terminal driver and no processor connector for either market.
- Any tokenized card-on-file capability for your customers, which some retail models need and which would be a real build with real scope.
- Any assessed compliance status, and we will not describe ourselves as holding one.
Not ours, by choice
- The card-brand standard is a contractual matter between you, your acquirer and the brands. We can describe what our software stores; we cannot tell you what your obligations are or whether you meet them.
- 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 no reference customer in the United States or Canada.
A processor reference stored against a card payment — not card data, a pointer — so that till takings reconcile against an acquirer settlement automatically rather than by hand. That is the gap 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 no dates on a public page. Tokenized card-on-file is a larger piece and the one where we would want to talk about who holds the token before anybody talks about a schedule. 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 reconciliation gap is the price of the schema above and we would rather publish it beside the strength than let it read as an unqualified win.
Our 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 the same decision means 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 plans & pricing