A card field is not a card reader
A web form with a card number, an expiry, and a CVV looks, to a driver, like paying. To the payment network it is the weakest, most expensive, most fraud-exposed way money can move: card-not-present. Nobody proved a physical card was there. Nobody proved the cardholder was either. The page is just typing numbers into a box and hoping the gateway on the far end vouches for them.
A contactless tap against a certified terminal is a different event entirely. The card — or the phone holding it — runs a cryptographic conversation with a piece of certified hardware before a single byte reaches an acquirer. That conversation is the whole point. It is also the thing a browser physically cannot do, no matter how clean the form looks.
This is the gap between a real card reader and a QR code that drops you into a web checkout. Both can be AFIR-compliant; only one is card-present. AFIR is why card readers are arriving on chargers at all: on a high-power DC unit a contactless reader is now mandated, while on lower-power AC a QR or payment-link path is still permitted. But compliance is not the argument here. The argument is what each rail costs you and what it exposes you to — and that turns on an EMV kernel running on a certified device.
What the kernel actually does
EMV is not “chip and PIN.” It is a state machine that runs at the moment of tap — locally, on the terminal, in the fractions of a second before the driver has moved their hand away.
The contactless interface wakes the card over NFC. The terminal’s EMV kernel selects the application on the card, reads its data, and asks the card to generate a cryptogram: a one-time value signed with a key the card never exposes and the terminal never sees. The kernel then runs terminal risk management — floor limits, velocity checks, whether this transaction can clear offline or must go online for authorization. It decides cardholder verification: for a low-value tap at an unattended charger, typically no PIN; above a limit, a step-up. Only then does anything leave the device, and what leaves is the cryptogram plus the transaction context, signed and bound to this one charge.
The acquirer and the issuer validate that cryptogram. Because it is unique to this transaction and signed by the card, a captured authorization message is worthless to replay. That is the property a CVV typed into a form does not have and cannot acquire:
A stolen card number works on a web form repeatedly, until someone notices. A captured cryptogram authorizes once, for one amount, and never again.
None of this is software you write. It is software you certify.
”Certified terminal” is a specific, load-bearing claim
When we say Bolt runs a terminal application on certified hardware, every word is doing work.
- The hardware is a secure cryptographic device with a tamper-responsive boundary: pry it open and the keys zeroize. It holds keys in a protected processor, not in general-purpose memory, and it is evaluated against a hardware security standard before it can be trusted to carry a payment kernel.
- The kernel on it is certified to the network’s contactless specifications — the L1 (electrical/RF) and L2 (kernel behavior) levels — so the cryptogram handshake is provably correct across the messy reality of thousands of card variants.
- The payment application that drives that kernel and talks to the acquirer is itself certified end to end (the L3 level), against the specific acquirer and network it settles into.
A browser has none of these. No tamper boundary, no protected key store, no certified kernel, no card present at all. It is a rendering engine. You can wrap it in TLS and a tokenization vault and it is still card-not-present, because the architecture cannot manufacture the one fact that matters: a real card, physically here, that just signed for this charge.
This is why “certified” is not branding. It is the line between two payment rails with different rules, different liability, and different cost.
What the certified moment buys the operator
Step back from the teardown and look at what the operator actually gets when the tap lands on certified hardware. The same five seconds that prove the card buy three distinct things at once — and they are usually sold to you as if they were three separate projects:
- A security posture — a cryptogram a thief cannot replay.
- A better rail — the network the transaction settles on.
- A smaller compliance footprint — a clear PAN confined to the secure device, where raw card data is allowed to live tightly bounded.
A web form forces you to assemble all three by hand, badly. The certified terminal hands you all three as the byproduct of doing the tap correctly. The next two sections take the rail and the footprint in turn.
Why certification is the economics, not a tax on them
The instinct is to read certification as overhead — hoops, audits, delay. It is the opposite. Certification is what unlocks card-present economics.
Card-present and card-not-present are priced as different risks because they are different risks, and the acquirer prices accordingly. The card-not-present rail carries the markup that pays for the fraud it structurally invites. On a fast DC session that markup is annoying. On a small, frequent AC session it is the difference between a viable transaction and one the surcharge quietly eats. Run enough small sessions through a web form and you are donating a slice of every charge to the cost of not proving the card was there — even where AFIR would have let you use that form.
A certified terminal proves it, so the session settles on the better rail. And because Bolt is non-MoR, those card-present economics land where they belong. The operator stays the merchant; funds settle to the operator’s own acquirer; the money never routes through us. There is no intermediary taking a cut for holding float it doesn’t need to hold. The kernel earns the rate; the operator keeps it.
Why certification is also the compliance story
PCI-DSS scope is mostly a question of where raw card data lives. On a web form, the answer is “in your application’s blast radius,” and you spend your life shrinking that radius — tokenization, vaults, scoped networks, audits of all of it.
A certified contactless terminal changes the question. The PAN is still read — the kernel needs it — but it is captured and encrypted inside the secure device, at the hardware boundary, and the clear PAN never enters the surrounding application at all. The terminal does the dangerous part inside a box built and evaluated for exactly that. The architecture minimizes scope by construction rather than by perpetual cleanup. To be precise: PCI-DSS here is an architectural posture and a scope-minimization strategy — not a certificate Bolt waves around.
So the same certification buys the three things named earlier in a single move: the cryptogram a thief cannot replay, the card-present rail, and a clear PAN confined to the secure device. They are not three features. They are one architectural decision, paid for once.
Where Bolt sits, and where it deliberately doesn’t
Bolt runs the terminal application on the certified device and bridges everything around it. The charger talks to its CSMS over OCPP; Bolt bridges the money over OCPI so the same terminal logic works against any charger, any CSMS, any acquirer — never a bespoke POS welded to one charger model. The tap proves the card. The kernel signs the transaction. Bolt’s application carries it from the certified device through pre-authorization, capture, the refund of an unused hold, the country-specific fiscal round trip, and reconciliation — the parts the protocol never specified, and that you only discover when a session drops mid-charge.
What Bolt does not do is reimplement EMV. The kernel is certified hardware doing certified work; reinventing it would be both impossible and pointless. Bolt’s job is to make that certified moment usable at an unattended charger: to put a real card reader where a web form would have been, then run the entire money flow behind it correctly and keep it correct as acquirer APIs, network specs, and CSMS releases move underneath.
A driver walks up, taps a card or a phone — Apple Pay and Google Pay ride the same contactless rail, so they just work — keys in an amount, and charges. It feels as simple as the web form. Underneath, it is present, signed, and settling on the right rail. And that certified moment is the one thing you cannot bolt on afterward: the rail, the security posture, and the compliance footprint are all decided at the instant of tap. Whether a reader or a form sits at that instant is an architecture choice you make once — not a UI detail you can revisit when the bills arrive.