How can I use fare collection systems to support open-loop and closed-loop payments?

Fare collection systems can support both open-loop and closed-loop payments by using a shared payment back end, but with different front-end behaviors and rules.

1) Open-loop payments

Open-loop means riders pay with general-purpose payment instruments, such as:

• EMV contactless bank cards
• Mobile wallets like Apple Pay, Google Pay, Samsung Pay
• Wearables

How fare systems support open-loop

• Accept standard tap-to-pay devices at gates or validators.
• Use a payment gateway / acquirer to process card transactions.
• Perform real-time authorization or deferred authorization, depending on the fare model.
• Apply fare capping so riders are charged no more than a daily/weekly pass.
• Support account-based ticketing (ABT) where the card token acts as the rider identifier.
• Use tokenization and PCI-compliant handling to reduce risk.

Key considerations

• Fast transaction times are critical for transit throughput.
• Need offline or “tap-and-go” fallback if network connectivity is intermittent.
• Risk controls are important because small transit fares can trigger issuer fraud checks.

---

2) Closed-loop payments

Closed-loop means payment works only within the transit operator’s own ecosystem, such as:

• Transit smart cards
• Proprietary mobile transit accounts
• Stored-value cards
• Agency-issued IDs or passes

How fare systems support closed-loop

• Riders load value into a transit account or card.
• Validators read the card/account ID and deduct fare from the transit system balance.
• Central back office manages:
  • Stored value
  • Passes
  • Concessions
  • Transfer rules
  • Revenue allocation
• Cards can work offline using local cryptographic keys or stored balance rules.

Key considerations

• Full control over fare logic and customer policies.
• Lower dependency on banks and card networks.
• Requires card issuance, top-up channels, and customer service infrastructure.

---

3) Supporting both in one system

Many modern fare collection systems are hybrid and can handle both open-loop and closed-loop at the same time.

Common architecture

• Front-end validators/gates accept:
  • EMV cards/wallets for open-loop
  • Transit cards/accounts for closed-loop
• A fare engine determines the applicable fare rules
• A back office reconciles transactions and manages rider accounts
• A risk and fraud module handles payment exceptions
• A clearing and settlement layer handles:
  • Bank card settlement for open-loop
  • Transit account settlement for closed-loop

Benefits of hybrid support

• Greater rider choice
• Faster adoption without replacing existing cards immediately
• Better inclusivity for unbanked riders
• Easier migration from legacy systems to modern ABT

---

4) Practical implementation options

To enable both types:

1. Choose validators that support multiple credential types

   • EMV
   • NFC/mobile wallets
   • Transit smart cards
   • QR codes if desired

2. Use account-based fare collection

   • Keep fare rules in the back office
   • Let cards/devices act as identifiers

3. Implement a payment orchestration layer

   • Routes open-loop transactions to card processors
   • Routes closed-loop transactions to the transit account system

4. Unify rider history and customer service

   • One user account can hold both bank-card and transit-card credentials

5. Design for offline operation

   • Cache hotlists and fare products locally
   • Sync when connectivity returns

---

5) Example workflow

Open-loop rider

• Rider taps bank card at gate.
• Validator sends tokenized transaction to fare back office.
• System checks eligibility and provisional fare.
• At day’s end, charges final amount with fare capping applied.

Closed-loop rider

• Rider taps transit card.
• Validator checks card or account balance locally or via back office.
• Fare is deducted immediately or recorded for later sync.
• Passes and discounts are applied automatically.

---

6) Best practices

• Support account-based ticketing to unify both payment models.
• Keep fare policy separate from payment processing.
• Ensure PCI and data privacy compliance for open-loop payments.
• Provide fallback top-up methods for closed-loop riders.
• Build for high availability and low latency.

If you want, I can also provide:

• a reference architecture diagram,
• a vendor comparison checklist, or
• a step-by-step migration plan from closed-loop to hybrid/open-loop.