Automatic fare collection (AFC) is shifting from paper tickets and closed-loop cards to open-loop payments, where a passenger simply taps the bank card, phone or wearable they already carry. Buses, metros, trams and ferries all benefit: boarding is faster, queues at ticket counters shrink, and visitors can ride without buying a local card first.
That convenience puts a heavy load on the technology underneath. Every tap must be read in a fraction of a second, approved or queued for later, priced by the fare engine and settled through an acquirer, all while card data stays protected. Two sets of rules decide whether an Automatic fare collection system can do this legitimately. EMV defines how a contactless payment works and how cards, devices and networks interoperate. PCI defines how payment environments, data, keys and devices must be secured.
This guide explains how EMV certification and PCI compliance fit into an Automatic fare collection project. It covers the main system components, the role of the contactless kernel, the certification stages, the PCI standards that apply, key management, validator security, SoftPOS, terminal management and the questions worth asking a technology partner.
Automatic fare collection system
An Automatic fare collection system is a chain of components, and a weakness in any link affects the whole journey. The main parts are:
- Validator: the device at the gate, door or platform that detects the credential and handles the tap.
- EMV contactless kernel: the software that talks to the card, phone or wearable and runs the contactless transaction logic.
- Payment application: the layer that manages the transaction flow around the kernel.
- Gateway and acquirer: the services that route the transaction to the card network and the issuing bank.
- Fare engine and transit backend: the systems that work out the correct fare, apply rules and keep the passenger’s travel record.
- Terminal Management System (TMS): the platform that provisions, configures, monitors and updates validators in the field.
No two projects share the same architecture. It depends on the transit model, the payment schemes accepted, the fare structure, the quality of network connectivity and the country. A metro with gated entry and a bus fleet with moving vehicles place very different demands on a validator, which is why EMV and PCI planning has to begin at design time rather than after the hardware has been chosen.
From tap to transaction in Automatic fare collection
A lot happens in the moment between a passenger touching a validator and the gate opening. A typical flow looks like this:
- The passenger taps a card, phone or wearable on the validator.
- The validator detects the credential.
- The EMV kernel processes the contactless interaction.
- The payment application manages the transaction.
- The gateway receives the transaction data.
- The acquirer and card network process it.
- The transit backend applies the fare logic.
- The result returns to the validator and the passenger.
Security controls operate at every step. Transit also adds demands that an ordinary shop counter rarely faces. Validators need fast processing, high throughput and reliable credential detection so that gates keep moving at rush hour. They need high availability and resilient connectivity, including some ability to keep working offline when the network drops. They also need secure software, useful diagnostics and a dependable way to receive over-the-air (OTA) updates. A design that is perfectly acceptable at a retail checkout can fail at a crowded gate.
EMV in Automatic fare collection: kernels and certification
EMV is the framework that defines how a contactless payment is carried out and how cards, devices and networks work together. In an Automatic fare collection system, validators use an EMV contactless kernel to process taps from bank cards, phones and wearables. Operators adopt EMV because it speeds up boarding, lets visitors pay with the card they already hold, removes friction, scales across large networks and leaves room for future mobility services.
The contactless kernel
The kernel is the core software component of the validator. A modern transit network usually needs to accept several schemes, such as Visa, Mastercard, American Express, Discover, JCB, UnionPay and RuPay. When comparing kernel options, look at performance, ease of integration, certification record, security and lifecycle management. A kernel that is quick in the lab but hard to update will cause trouble once thousands of validators are in service.
EMV & PCI Certification stages
Certification for Automatic fare collection can include several layers: EMV Level 1, Level 2 and Level 3 testing, scheme certification, acquirer and processor testing, application testing and end-to-end testing. These layers depend on one another, so the plan should be agreed before development begins. Leaving certification until the end is one of the most common reasons a transit launch slips.
Because the validator, kernel, payment application, gateway and fare engine all sit in one transaction path, a change in one can affect testing in another. Treat version and configuration changes as controlled events, and keep a clear record of which kernel and application versions were certified against which schemes.
PCI requirements for Automatic fare collection
EMV and PCI answer different questions, and an Automatic fare collection project needs both. Neither replaces the other.
| EMV | PCI | |
| Purpose | How a payment works and interoperates | How payment data, keys, devices and environments are protected |
| Typical evidence | L1, L2 and L3, scheme and acquirer testing | Environment assessment, device approval, software security |
| Relationship | Complements PCI | Complements EMV |
The PCI standards to check
- PCI DSS sets security requirements for any environment that stores, processes or transmits account data. Version 4.0.1 is the active version.
- PCI PTS sets security requirements for payment devices. The PTS POI Modular Security Requirements v7.0 apply, and each validator model should be checked to see whether it falls in scope.
- PCI MPoC matters when acceptance runs as software on a commercial mobile device, such as SoftPOS.
Key management at fleet scale
Cryptographic keys protect every transaction, and a transit operator may run thousands of validators. Plan for secure key generation and injection, Remote Key Injection (RKI), hardware security modules (HSMs), and routine rotation. Just as important are procedures for replacing, revoking and destroying keys, and secure communication between every device and the back end. Manual key handling does not scale to a large fleet, so decide early how keys will reach validators and how they will be refreshed over the years.
The certification path, step by step
Certification feels manageable when it is broken into stages that follow the build. A practical path for an Automatic fare collection programme looks like this:
- Define the scope. List the schemes, countries, validator types, fare model and acquirer involved.
- Choose the kernel and architecture. Pick a kernel that covers the required schemes and can be updated in the field.
- Build and integrate. Connect the kernel to the payment application, gateway, fare engine and backend.
- Complete EMV testing. Run the L1, L2 and L3 testing that applies to the device and software.
- Run scheme and acquirer tests. Confirm that each scheme and the processor accept the transactions.
- Test end to end. Follow a tap from the validator through to the fare result, including degraded and offline conditions.
- Gather PCI evidence. Document the environment scope, device status and key management procedures.
- Pilot, then roll out. Monitor early validators through the TMS before expanding to the full fleet.
Common pitfalls
- Starting certification after development instead of before it.
- Assuming PCI scope without checking each validator model.
- Treating key management as an afterthought.
- Testing only the ideal case and skipping poor connectivity.
- Having no safe plan for OTA updates after launch.
Most delays in transit projects trace back to one of these five habits. Fixing them early costs far less than fixing them with validators already installed.
Securing validators, SoftPOS and the TMS
A validator sits in a public place, often unattended, so security has to be built into the device itself. A strong Automatic fare collection validator combines several layers: secure boot, application integrity checks, device authentication, tamper protection, secure OTA updates and remote monitoring through a TMS. Each layer limits what an attacker can do if another one fails.
SoftPOS and Android devices
Android-based and SoftPOS devices open useful options in Automatic fare collection: mobile validators, inspection devices, staff devices, temporary acceptance at events and flexible mobility services. They also need careful evaluation. Review device and operating system security, application integrity, secure communication, data protection, authentication, update handling and remote management, and check which PCI requirements apply, including MPoC.
Terminal Management System
The TMS is how an operator stays in control after launch. A capable platform handles provisioning, configuration, application deployment, firmware and OTA updates, remote commands, monitoring, diagnostics, security monitoring, inventory and reporting. For a network with thousands of validators, these functions are what keep certification valid and the fleet healthy over time. Without them, every fix means a visit to the field.
Regional design and choosing a technology partner
Automatic fare collection looks different from one market to the next. In India, projects often involve RuPay and NCMC, depending on the programmed. Other regions, including the UAE, Southeast Asia, Africa and Europe, bring their own schemes, acquiring arrangements, certification routes and security expectations. A design that works in one country cannot simply be copied into another.
When you evaluate a technology partner, ask them to be specific about:
- Kernel development and the schemes they support
- Certification support and kernel integration
- PCI requirements, key management, RKI and HSM use
- Validator security and OTA update handling
- Fare engine and backend integration
- TMS scalability for large fleets
- SoftPOS and Android experience
- NCMC and RuPay support, where relevant
EazyPayTech works across this stack, from EMV kernel solutions and certification support to transit validator software, payment applications, gateway and backend integration, and terminal management. To discuss your Automatic fare collection requirements, write to info@eazypaytech.com.
Conclusion
The future of Automatic fare collection depends on getting several things right together: EMV for how payments work, PCI for how they are protected, and secure devices, validator software, fare engines, backend integration and terminal management to hold it all in place. Operators who plan certification and security from the first design workshop launch faster, avoid costly rework and keep passengers moving. Those who treat them as a final checkbox usually pay for it later.
