Design FASTag toll payments

A lane cannot wait for a four-party round trip over a highway network that may be slow or down. So the system splits the decision from the payment. The decision is local: the plaza holds a list of tags that must not pass (blacklisted, closed, low balance) and the fare rules, and the lane decides in milliseconds. The payment is asynchronous: the read is written to a durable local store first, then forwarded when the network allows. Use an exception list, not a full list of good tags, because most tags are good and the bad list is much smaller and changes less. This creates a risk window: a tag that went bad a few minutes ago may still pass, and its debit may later be declined. The network handles this with rules on time: the status that counts is the one at read time, so a tag blacklisted shortly before the read (inside the list propagation window) is the issuer's risk, while a stale plaza list beyond the allowed lag is the acquirer's risk. NPCI has tightened these rules over time, for example around how long before and after a read a blacklist status applies. In an interview, explaining this 'decide locally, settle later, with clear liability windows' pattern is the main signal.

Double charges are the top FASTag complaint. They come from three sources. First, multiple reads: the antenna reads the same tag many times as the car moves, and a car may stop and reverse. The lane controller collapses reads of the same tag in the same lane within a time window (say 5-10 minutes) into one transaction. Second, network retries: the plaza resends a batch after a timeout. Make every transaction carry a txn_id that is created once at the lane and never changes; the acquirer stores it with a unique constraint and the issuer deduplicates on the acquirer's reference too, so retries are safe. Third, cross-lane or cross-plaza confusion: a tag read by an adjacent lane antenna. Use antenna power tuning and cross-check with the AVC and camera; transactions where the camera plate does not match the tag's registered VRN go to an exception queue rather than being debited blindly. Also guard against missed tolls: transactions stuck at the plaza must be sent within the network's allowed window, after which they may be rejected or need a different process, so the plaza alerts when its local queue age grows. Disputes use the image and read logs to decide.

The exception list service keeps an append-only, versioned log of status changes: (version, tag_id, new_status, effective_at). Issuers write to it when balances cross a threshold, KYC fails or tags close. Each plaza stores the list in a local key-value store (RocksDB or SQLite) and pulls deltas since its last version every 30-60 seconds; a push channel can cut this further. If a plaza has been offline long enough that the log has been compacted past its version, it downloads a full snapshot (compressed, tens of MB) and then applies deltas. To keep it small, the full list holds only non-good tags, and low balance can be expressed as a threshold flag rather than exact balances. Consistency is eventual, so measure and alert on 'list lag per plaza', because a stale list directly costs money. A hot path matters too: when a driver recharges in the lane, the issuer can also publish the change with priority. Integrity: sign the snapshots and deltas so a compromised plaza network cannot inject a list that lets tags pass free.

Money does not move per transaction between banks. The switch records every approved debit and computes net positions per settlement cycle: each issuer owes the sum of its customers' tolls, each acquirer is owed the sum for its plazas, minus interchange fees. Banks settle the net amounts through their settlement accounts, and acquirers then pay toll concessionaires. Every participant receives settlement and raw transaction files for each cycle. Reconciliation runs at three levels. Plaza vs acquirer: every txn_id from plaza logs must appear in the acquirer's records (detects lost uploads). Acquirer vs switch: approved, declined and pending counts and amounts must match per cycle. Issuer vs switch: debits in the wallet ledger must match the switch's file. Breaks feed the dispute system, where users can raise wrong-class or double charges; refunds flow back as credit adjustments in a later cycle. Keep everything immutable: corrections are new adjustment records, never edits, which makes audits possible years later.

Online authorisation (wait for the issuer's yes) gives zero credit risk but makes lanes depend on four systems and the network, and adds seconds per vehicle, which creates queues. Local decisions with an exception list keep lanes fast and resilient at the cost of a small, bounded credit risk. Hybrid: use online checks when the network is healthy and the tag is near the threshold.

A full list (every tag with status) is bigger and changes on every debit. An exception list is small and only changes when a tag goes in or out of a bad state. The trade-off is that an unknown, never-seen tag is treated as good, so newly issued tags work instantly but fake tags must be caught by the switch later.

Sending each transaction immediately gives faster debits and SMS but more connections and overhead. Small batches (every few seconds) are efficient and handle bursts. With durable local queues both are safe; choose near-real-time with micro-batching.

At 3-4x traffic, the switch and issuers see bursts after plazas reconnect and flush backlogs. Acquirers should rate-limit flushes and the switch should apply per-issuer backpressure; a queue (Kafka) between acquirer intake and switch calls absorbs bursts without losing transactions.

Many tags hover around the threshold, flipping in and out of the list with every debit and recharge. This inflates deltas. Use hysteresis (go bad below ₹X, go good above ₹X + margin) and encourage auto-recharge to reduce churn.

Lanes keep working using the last list and local fare rules; transactions queue locally on durable storage (with a UPS). On reconnect, the plaza uploads in order, deduped by txn_id. Alerts fire if the list or the queue is older than the allowed window.

The switch cannot get debit approvals; transactions stay pending and are retried with the same reference until the issuer returns. Lanes are unaffected. Settlement for that issuer happens in a later cycle.

The lane falls back to manual handling: the operator scans the tag with a handheld reader or reads the number plate, and the transaction uses the same flow with a flag. Highway toll rules treat a working, funded tag that the plaza fails to read differently from a vehicle with no valid tag (which pays a higher fee), so the system must record why a read failed, for audit and disputes.