PAYMENT APPLICATION
A payment application of ticketing devices refers to the software component responsible for
securely processing fare payments when passengers interact with a ticketing device (like a
validator or ticket vending machine) in public transportation systems.
🎟️What Is a Ticketing Device?
Ticketing devices include:
Validators (used on buses/trains to tap-in/tap-out)
Ticket vending machines (TVMs)
Mobile ticketing terminals
Handheld inspector devices
These devices often support cashless payments, including:
Contactless EMV cards (Visa, Mastercard)
Mobile wallets (Apple Pay, Google Pay)
Closed-loop transit cards (e.g., Oyster, Octopus)
QR codes or barcode tickets
💡 What Is the Payment Application?
The payment application is the embedded software that enables the device to:
1. Read and interpret payment media
2. Apply fare rules
3. Securely transmit and authorize payment transactions
4. Provide visual/audible feedback to passengers
5. Record and audit fare transactions
🧩 Components of the Payment Application
Component Function
Media Reader Interface Interacts with contactless cards, phones, QR/barcodes
Component Function
Fare Engine Calculates fares (flat, distance, time-based)
EMV Payment Kernel Processes contactless bank card transactions (L2 certified)
Transaction Processing Authorizes or defers payments; sends them to acquirers or back office
Security Module Ensures encryption, PCI-DSS compliance, tokenization
Feedback UI Provides passenger feedback (beeps, lights, screen messages)
Risk Management Logic Checks for blocked cards, fare capping, or duplicate taps
Offline Support Stores transactions if network is down and syncs later
Logging and Audit Records transaction history for audit, reports, and reconciliation
🔄 Payment Flow in Ticketing Devices (Open-Loop Example)
1. Passenger taps a contactless card or phone
→ Payment application reads card via NFC reader.
2. Fare engine determines fare rules
→ May use tap-in/tap-out logic or fixed fare.
3. Transaction is created
→ Encrypted data sent to backend or acquirer.
4. Authorization (online or deferred)
→ Payment processor or bank approves/declines.
5. Result is shown
→ LED/beep/screen feedback to passenger.
6. Transaction is logged
→ Stored locally or sent to central server.
🔐 Compliance and Standards
To process real money securely, the payment application must comply with:
Standard Purpose
EMV L2 Secure card transaction logic
PCI-DSS Data security for handling cardholder info
EMVCo L1/L2 Hardware/software payment interoperability
L3 Certification Scheme-specific approval for end-to-end payment flows
🛠️Example Use Cases
✅ Open-Loop Ticket Validator
Accepts Visa/Mastercard
Runs EMV kernel + fare engine
Sends transactions via 4G to payment gateway
✅ Closed-Loop Smartcard Validator
Accepts transit-only cards
Runs stored-value logic on-card or in backend
Does not involve banks directly
🧠 Summary
A payment application on a ticketing device enables secure, automated fare collection using
various payment media. It combines fare logic, card interaction, security, and communication to
process and authorize payments in real time or batch mode.
