Skip to content
BPTCMobile Wallet Ticketing · Prototype

Bahrain’s bus fares and passes, in one wallet

Passengers board with a signed QR code or an NFC tap. Validators keep collecting fares without signal, and BPTC owns the ledger.

Run the end-to-end demoOpen the passenger app
  • Device-bound
    credentials
  • Signing keys in
    secure hardware
  • Arabic & English,
    full right-to-left

Illustration: a phone shows a stored-value wallet with a rotating signed QR code, the validator on bus BUS-101 shows ACCEPTED, and the ledger records a balanced BHD 0.300 fare posting, over a map line of route A1 from the airport through Muharraq.

Designed to connect with the payment, messaging, device and transit systems in BPTC’s scope

  • BENEFIT gateway
  • BenefitPay
  • Visa & Mastercard · 3-D Secure
  • Apple Pay & Google Pay
  • Acquirer card tap
  • SMS aggregator
  • Push notifications
  • Mobile device management
  • GTFS & GTFS-Realtime
  • Offline maps & navigation
  • OpenAPI, versioned

Platform

Four apps on one backend. One source of truth, simulated in your browser.

A top-up on the phone, a tap on the validator or a refund at the counter appears in every other open tab straight away.

Passenger app

Stored value and passes on the phone. A signed, rotating QR code per product, NFC tap on Android, purchase, history and live arrivals.

  • iOS & Android
  • QR + NFC
  • العربية
  • English

Passenger wallet on two phones, in English and Arabic: stored value of BHD 7.400 and BHD 8.200 at BHD 0.300 per trip, in front of the Bahrain World Trade Center in Manama.

PA-01 – PA-15

Driver validator

A rugged tablet at the door: hands-free QR scanning, NFC wallet reads, bank-card tap for single trips, and turn-by-turn navigation that keeps working offline.

Driver validator tablet: boarding accepted, 39 boardings this shift, and turn-by-turn navigation to Muharraq Bus Station.

DV-01 – DV-10 · NAV-01 – 08

Admin back office

Fares and products, concessions, device fleet, fraud cases, GTFS timetable, service alerts, reconciliation and a full audit trail.

Admin dashboard (pilot, simulated data): 539 boardings today against 501 on the same day last week, and 3 offline events awaiting sync.

ADM-01 – ADM-10

Counter portal

Cash sales and top-ups with receipts, device changes and account recovery, refunds within role limits, and till reconciliation.

Counter receipt: cash top-up of BHD 5.000 by Maryam Ali at Manama Bus Terminal; refunds above BHD 5.000 need a supervisor.

CP-01 – CP-10

Backend platform

Identity, fare engine, double‑entry ledger, signed credentials, validation, payments, offline sync, fraud rules, GTFS and GTFS‑Realtime.

Diagram: backend services around one double-entry wallet and entitlement ledger. Payments, validation, the fare engine, credentials and offline sync are wired to the ledger; identity, fraud rules and the GTFS-Realtime feed sit alongside it.

BE-01 – BE-16 · FR-01 – 06

End-to-end process

Follow one fare from sign-up to settlement. Six steps, one wallet.

The demo console runs this whole story live: the passenger phone and the driver validator side by side, with every backend event in a feed.

Open demo console
  1. 01

    Register with a one-time password

    A verified mobile number is all it takes. Identity details are asked for only when a concession is claimed.

    PA-02

    Illustration: a six-digit one-time password entered on the phone and the number verified.

  2. 02

    Top up through the gateway

    BENEFIT debit, Visa and Mastercard with 3‑D Secure, BenefitPay, Apple and Google Pay where supported. Credited only on server-to-server confirmation.

    PA-04 · PAY-01 – 04

    Illustration: a BHD 5.000 top-up confirmed server to server and credited to the wallet.

  3. 03

    Board with QR, NFC or a bank card

    The validator checks signature, entitlement, replay and duplicates, then shows green or red with a tone and counts the boarding.

    PA-06 · DV-03 – 07

    Illustration: the driver validator shows ACCEPTED for a BHD 0.300 stored-value fare and counts the boarding.

  4. 04

    Post to the ledger

    Every fare is a balanced, append-only double-entry posting with an idempotency key, so a retry can never charge twice.

    BE-03 · PAY-04

    Illustration: a balanced ledger posting, debit wallet 0.300 and credit fare revenue 0.300.

  5. 05

    Flag fraud, decide by people

    Rules flag impossible travel, offline double use or refund patterns. Staff decide, and automated measures stay reversible.

    FR-01 – FR-04

    Illustration: an impossible-travel alert with risk score 82 waiting for a staff decision.

  6. 06

    Reconcile and report

    Daily settlement matches the gateway, the acquirer and the ledger. Dashboards show ridership, revenue, schedule adherence and kilometres.

    ADM-08 · BE-08

    Illustration: daily settlement where gateway BHD 74.275 plus acquirer BHD 3.600 matches ledger clearing BHD 77.875.

Open any step in the prototype

Reliability

Fare collection never stops because of a connectivity failure.

Validators keep checking credentials against cached keys, lists and BPTC’s offline policy, queue every event encrypted, and reconcile with zero loss when signal returns.

Map of the simulated pilot network: routes A1 (Airport to Manama Bus Terminal), X2 (Manama to Isa Town and Riffa) and 41 (Seef to Juffair). A simulated no-signal zone covers the Muharraq to Manama causeway on A1. Bus BUS-101 drives through it, keeps validating offline, queues three encrypted events and syncs them with none lost when signal returns.

Validator status

Pilot network · 3 routes · simulated

  • A1Airport – Manama Bus Terminal
  • X2Manama – Isa Town – Riffa
  • 41Seef – Manama – Juffair
  • A1

    VAL-01 · BUS-101

    Hassan Ali

    Online. Events queued while offline sync automatically when signal returns.
  • X2

    VAL-03 · BUS-103

    Rajesh Kumar

    OnlineLists v41
  • 41

    VAL-05 · BUS-105

    Sameer Khan

    OnlineLists v41
Event feed · VAL-01newest first
  1. 08:31:05 ·VAL-01 · signal back · 3 events synced · 0 duplicates · 0 lost
  2. 08:30:37 ·VAL-01 · fare accepted offline · queued, encrypted (3)
  3. 08:30:02 ·VAL-01 · fare accepted offline · queued, encrypted (2)
  4. 08:29:41 ·VAL-01 · fare accepted offline · queued, encrypted (1)
  5. 08:29:14 ·VAL-01 · signal lost · validating on cached keys
  6. 08:29:02 ·VAL-01 · online · lists v41

Try it: the demo console drops a validator’s signal, or takes the whole backend down with one switch. Open the console

  • Targetunder 0.5 seconds

    median QR and NFC decision on the reference tablet

    NFR-01 · NFR-02

  • Targetat least 72 hours

    of validator operation without connectivity, with no transaction loss

    OFF-02

  • Target99.9%

    monthly availability for validation and purchase

    NFR-04

  • Target50,000

    boardings a day across 100 vehicles, with at least three times peak headroom

    NFR-05

Targets set in BPTC’s Scope of Requirements, not measurements of this prototype. Fleet rollout proceeds only if the Stage 1 pilot meets the Section 12 service levels; a short technical proof can first demonstrate QR and NFC validation on the reference device in Bahrain daylight.

Online and offline operation

Section 7 · OFF-01 – 04
Passenger offline, validator online
Online
Full online validation. Passenger data is never needed at boarding.
Validator offline
Offline
Validates against cached keys, lists and the offline policy, queues events encrypted and reconciles on reconnection.
Stored value offline
Within limit
Deducts against a signed balance within a per-account offline limit. Any shortfall is recovered at the next top-up.
Single trips offline
Within policy
Accepted within policy limits and checked against the cached consumed single-trip list.
Bank card tap without signal
Not available
The bank authorises each tap. QR, NFC wallet and cash stay available.
Backend unavailable
Offline
Validators continue offline, and queued events reconcile once service is restored.
Counter and admin portals
Online only
They show that the connection is lost and resume when the platform is back.

Driver navigation keeps working offline

Routes and stops from BPTC’s GTFS timetable, turn-by-turn guidance, off-route alerts and early or late indicators, all on maps cached on the tablet.

150 mContinue straightطريق 2403

NAV-01 – NAV-07

Offline rules BPTC controls

Offline tolerance
72 h
Stored-value offline limit
BHD 1.500 per account
Alert when a validator is offline
after 12 h

Pilot settings in this prototype, configurable in the back office.

Offline policyOFF-01 · OFF-04

Security & hosting

Built to protect revenue and passengers’ data. Signed codes, locked‑down validators.

Platform & security in the back office

Illustration of a sample boarding code, as shown in the passenger app. It has three parts: the format and version, BPTC1; a payload of signed fields, which are passenger P-1001, stored value, bound device PD-7Q2F, mode QR, the time it was issued, a nonce and the credential key k2026-10; and a signature made with credential key k2026-10 and bound to this phone, which validators check offline with cached keys. In this prototype a new code is issued every 15 seconds. Credential keys are hardware-backed and rotate on a schedule: k2026-08 is retired, k2026-09 is in its grace period and k2026-10 is active.

  • Keys in secure hardware

    Credential signing keys are held in hardware‑backed key storage and rotate on a schedule. Each phone signs its codes with a device‑bound key.

    SEC-02 · BE-04

  • Locked‑down validators

    Mutual TLS per device with individual revocation, kiosk mode under mobile device management, attestation and remote wipe. A device that fails attestation stops validating.

    SEC-03 · SEC-07 · DV-09

  • Named access only

    Single sign‑on with multi‑factor authentication, role‑based access and managed identities. No shared or embedded credentials.

    SEC-05 · CP-01

  • Monitored, with alerting

    Validation latency, device status and security events, with alerting and detection rules for the fraud and misuse cases.

    NFR-10 · SEC-09

  • Azure UAE North

    Primary region in the UAE, subject to BPTC’s data‑residency confirmation, with immutable backups and recovery copies in Europe.

    NFR-07 · SEC-10

  • Encrypted throughout

    TLS 1.2 or higher in transit, and encryption at rest with customer‑managed keys.

    SEC-01

  • Private by design

    Private endpoints for data services, a web application firewall and DDoS protection.

    SEC-04

  • Hardened apps

    Tamper, root and jailbreak detection with certificate pinning.

    SEC-06

  • Secure delivery

    Threat modelling, static and dynamic testing, SBOM and signed builds. Independent penetration test before go‑live and every year.

    SEC-08 · SEC-11

  • Built for Bahrain’s PDPL

    Data minimisation, retention rules and data subject rights. No developer access to production data.

    SEC-12 · SEC-13

  • Designed to WCAG 2.1 AA

    Apps and portals: contrast, focus order, screen readers, larger text and Arabic right‑to‑left.

    NFR-06

  • Portable, no lock‑in

    Containers, PostgreSQL and standard messaging, with infrastructure as code across development, test and production.

    NFR-08 · NFR-09

Integrations

Works alongside BPTC’s existing systems. Nothing is replaced.

Payments, messaging, timetables and validator device management plug in. The existing fare collection and vehicle location systems need no integration.

Bahrain Bus

BPTC wallet platform

Ledger · credentials · validation · sync

OpenAPI · v1.3 · documented & versioned

Payments & messaging

  • Payment gateway

    BENEFIT · cards · wallets

  • Acquiring bank

    Certified card-tap component

  • SMS aggregator & push

    OTP · receipts · alerts

  • Mobile device management

    Kiosk · attestation · remote wipe

Transit data

  • Timetable (GTFS)

    Import & versioning

  • Journey planners

    GTFS-Realtime feed

  • Maps & navigation

    Offline map data

Outside scope

Existing fare collection and vehicle location

No integration required.

API catalogue · v1.3 · OpenAPI

Documented & versioned· BE-16
  1. POST
    /v1/credentialsPassenger token

    Issue a signed, device-bound QR or NFC credential

  2. GET
    /v1/keysValidator mTLS

    Public signing keys, including keys in their grace period

  3. POST
    /v1/validations:batchValidator mTLS

    Upload the offline queue. Idempotent; returns duplicates and conflicts

  4. POST
    /v1/paymentsPassenger token

    Create a payment intent. Idempotency-Key header required

  5. GET
    /v1/settlements/{date}Staff token

    Daily reconciliation of gateway, acquirer and cash

  6. POST
    /v1/gtfs/versions/{id}:publishStaff token

    Publish a timetable version

Integration status and the API catalogue

Scope boundary

What the wallet deliberately leaves alone.

  • No vehicle telematics or driver scoring

    Section 2.1

    Engine and vehicle telematics, and driver behaviour scoring, stay out of scope.

  • Cash and GO Card continue unchanged

    The wallet adds a digital channel; nobody is forced onto it.

  • No card data in BPTC systems

    PAY-02

    Cards are captured only on the gateway’s hosted page or certified SDK.

  • No open-loop fare capping

    Section 2.1

    Bank cards buy single trips through the certified component.

  • BPTC owns the data and the code

    Section 14.2

    All data, the ledger, source code and IP, with escrow and documented export formats.

Delivery

Staged, with payment tied to working demos. Each stage proves itself first.

  1. 1Technical proof

    QR and NFC in Bahrain daylight

    A short, paid proof on the reference tablet, before full commitment.

    Proof covers

    • QR
    • NFC
    • Daylight
    Before commitment
  2. 2Stage 1

    Full platform and a controlled pilot

    All apps and portals, piloted on 5 to 10 buses. This prototype simulates a 10‑bus pilot on 3 routes.

    Simulated pilot

    • A1
    • X2
    • 41
    • 10 buses
    Pilot · 5 to 10 buses
  3. 3Stage 2

    Fleet rollout

    Proceeds only once the pilot meets the acceptance measures in Section 12.

    Section 12 targets

    • Median decision < 0.5 s
    • 99.9% monthly availability
    Gated on acceptance

Commercial principlesSection 14

  • Payment tied to working demonstrations and acceptance
  • BPTC owns the data, the ledger, the source code and IP
  • Source code escrow and documented export formats

Clarifications

Answers to Section 16. How each point is handled.

30 min

response at any hour to an incident that stops fare collection, with a target to restore service within four hours. §14.3

iOS NFC

Third-party NFC card emulation on iPhone depends on Apple’s NFC and SE platform entitlement, whose availability in Bahrain is to be confirmed with Apple. Until then iPhones board with the signed, rotating QR code (offered as a Wallet pass where suitable), while Android uses NFC host card emulation. The prototype shows both paths.

Card tap component

A certified tap-to-pay component running on the Android validator, supplied through BPTC’s acquiring bank. The bank authorises each tap; BPTC keeps only the boarding record and the bank’s transaction reference (PAY-05).

GO Card reading

Technically possible with the validator’s NFC reader, but only with the card specification and keys from the current fare collection supplier. It stays out of the pilot scope (Section 2.1) and can be priced separately once that supplier’s terms are known.

Offline stored value

A signed balance credential, a per-account offline spending limit (BHD 1.500 in the pilot), a 72-hour offline tolerance and permitted products, all set by BPTC in the back office (OFF-01). Any shortfall is recovered at the next top-up, and offline double use is detected automatically at sync (FR-02).

Navigation

OpenStreetMap data with vector map tiles cached on the tablet and GTFS shapes for turn-by-turn guidance, so routes, stops and off-route alerts keep working without signal. The open licence avoids per-device fees.

Group travel

One passenger can present several products in one boarding: the phone shows one code per ticket in sequence, and the validator records a boarding for each.

Challenges to this scope

Proposed changes to the scope, each with its trade-offs, are set out in the written response. This prototype follows the scope as written.

Support and service levels

Any incident that stops fare collection gets a response within 30 minutes at any hour, with a target to restore service within four hours (Section 14.3). Validators keep collecting fares offline in the meantime.

Try it

Ready to walk through it?

Start in the demo console, or open each surface in its own tab: they stay in sync. Reset the data any time from the prototype menu at the bottom left.

Launch live demoBack office

Demo sign-ins

Simulated accounts

  • Passenger
    +973 3600 1122
    OTP123456
    Yana Khalid’s account
  • Driver
    Staff 20481
    PIN1234
    Keypad, or tap Demo to fill
  • Counter
    Maryam Ali
    MFA123456
    Counter agent
  • Back office
    Noor Al-Sayed
    MFA123456
    Administrator