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.
More we can add to your workspace
- A processor or terminal reference on a card payment, so reconciliation against an acquirer settlement stops being manual and done by amount and time.
- 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.
- A tokenized card-on-file capability for your customers, which some retail models need and which would be a real build with real scope.
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 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 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. 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 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 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 how point of sale works