Urban Transport Contactless Fare Operations Refund & Reconciliation

Contactless Fare, Refund & Journey Reconciliation Platform

Modernising fare calculation, failed tap resolution, refund handling, customer-support workflows, and payment reconciliation through a centralised, auditable, and scalable platform for multi-modal contactless transport journeys.

Refund Processing

7d → 24h

Journey Matching Accuracy

89% → 97%

Manual Refund Review

-55%

00 Summary 01 Problem 02 Stakeholders 03 AS-IS 04 TO-BE 05 Requirements 06 Process Diagrams 07 Risks 08 Deliverables 09 KPIs

00 — Executive Summary

A UK urban transport operator needed a joined-up operating model for journeys, fares, refunds, and reconciliation.

A UK urban transport operator was experiencing growing operational pressure from contactless payment disputes, incomplete journey records, fare calculation errors, delayed refunds, and fragmented customer-support workflows.

Customers used contactless bank cards, mobile wallets, and transport cards across buses, rail, tram, and metro-style services, but journey data, payment authorisations, fare rules, and refund cases were not managed through a fully joined-up operational process.

The organisation needed to improve how it captured tap-in and tap-out events, matched journeys, calculated fares, handled incomplete journeys, resolved failed taps, processed refunds, and reconciled payments across multiple transport modes and payment providers.

As Business Analyst, I led the discovery and process transformation initiative to design a contactless fare, refund, and journey reconciliation platform. The solution introduced improved journey-event matching, automated fare calculation, exception handling for failed or missing taps, customer refund workflows, payment reconciliation dashboards, and customer-support case management.

The transformation improved fare accuracy, reduced refund processing time, strengthened payment reconciliation, and gave operational teams better visibility into journey exceptions, revenue leakage, customer disputes, and settlement performance.

01 — Business Problem

Fragmented journey, payment, and support data made contactless fare operations hard to control and explain.

The transport operator’s contactless fare-management process was under pressure because journey, payment, and customer-support data were fragmented across multiple systems.

The problem was not simply “take payment when someone travels.” The real complexity was matching transport events, applying fare rules, managing exceptions, and proving why a customer was charged a specific amount.

The organisation needed a centralised platform that could connect journey events, fare rules, payment transactions, customer disputes, and reconciliation workflows into one auditable operating model.

  • Tap-in and tap-out events were not always matched correctly
  • Customers were sometimes charged maximum fares due to incomplete journeys
  • Failed taps created payment and journey exceptions
  • Refund requests were manually reviewed
  • Customer-support teams lacked a complete journey and payment history
  • Payment reconciliation between journey records, authorisations, captures, and settlements was slow
  • Operational teams lacked dashboards for fare exceptions, failed taps, refund trends, and revenue leakage

02 — Stakeholders

Passengers

Accurate fares and simple refunds

Expected clear journey history, fair charging, and simple refund resolution.

Customer Support Team

Full journey and payment visibility

Needed a unified case view to explain charges and resolve disputes faster.

Revenue Protection Team

Reduced fare evasion and leakage

Focused on unresolved exceptions, failed payments, and revenue leakage controls.

Fare Policy Team

Correct fare rule implementation

Required accurate application of caps, zones, routes, concessions, and service-specific pricing.

Payment Operations Team

Authorisation, capture, settlement, and reconciliation

Needed reliable payment matching, settlement visibility, and queue-based exception handling.

Finance Team

Revenue accuracy and refund controls

Required controlled refund approvals and accurate revenue reconciliation.

Station and Operations Teams

Handling failed taps and passenger issues

Needed practical frontline visibility for device failures and passenger issues.

Data Analytics Team

Journey matching and exception insights

Needed clean data for failed taps, maximum fares, device/location issues, and exception trends.

IT & Engineering Team

Reliable integrations and scalable processing

Focused on event processing, journey-engine integrations, payment-provider integrations, and reliability.

Compliance and Risk Team

Auditability, payment controls, and data protection

Needed auditable fare calculations, refund decisions, and GDPR-compliant journey/payment data handling.

Senior Leadership

Customer trust and operational efficiency

Focused on customer trust, revenue protection, service efficiency, and operational visibility.

Stakeholder Conflicts

  • Passengers wanted fast refunds and simple explanations.
  • Finance and revenue teams wanted stronger controls before money was returned.
  • Fare policy teams wanted complex fare rules applied accurately.
  • Customer support wanted journeys explained in plain language.
  • Engineering teams needed scalable event processing.
  • Operations teams needed practical tools for frontline resolution.

BA Balancing Role

  • Translated a technically complex fare and payment ecosystem into clear business rules.
  • Defined exception workflows for incomplete journeys, failed taps, refunds, chargebacks, and settlement issues.
  • Balanced customer experience, fraud and leakage controls, payment governance, and operational usability.
  • Converted fare logic and payment dependencies into delivery-ready requirements and user journeys.

03 — AS-IS Workflow

1
Passenger Taps In / Out
2
Tap Event Captured
3
Event Sent to Fare System
4
System Attempts Journey Match
5
Fare Calculated from Available Data
6
Maximum Fare May Apply
7
Authorisation & Settlement
8
Passenger Contacts Support
9
Manual Journey & Payment Review
10
Manual Refund Approval
11
Reconciliation Investigation

Key Pain Points

  • Missing tap-ins, missing tap-outs, delayed events, or device failures caused incomplete journeys and incorrect fares.
  • Refunds required manual review across journey, payment, and customer-support systems.
  • Passengers could not always see why they were charged a certain fare.
  • Support agents had to check multiple systems to understand journey history, fare calculation, and payment status.
  • Authorisations, captures, refunds, chargebacks, and settlement records were difficult to reconcile quickly.
  • Incorrect fare calculation, failed payments, and unresolved exceptions created financial risk.

Operational Impact

  • Frequent maximum fare disputes.
  • High manual refund review workload.
  • High payment reconciliation mismatches.
  • High customer-support repeat contacts.
  • Limited visibility into failed taps and device/location exceptions.
  • Revenue leakage from unresolved journey and payment exceptions.

04 — TO-BE Solution

Centralised contactless fare, refund, and journey reconciliation platform.

The future-state solution introduced a centralised contactless fare, refund, and journey reconciliation platform.

The solution improved fare transparency, reduced manual investigation, and created a stronger link between journey data, fare logic, payment operations, and customer service.

Operational dashboards show failed taps, maximum fares, refund reasons, device issues, revenue leakage trends, and reconciliation exceptions.

01

Tap Event Capture

Tap events are captured from gates, validators, onboard readers, and mobile devices.

02

Event Validation

Events are validated for timestamp, location, device, payment token, and service route.

03

Journey Matching Engine

The platform pairs tap-in and tap-out events using configurable matching rules.

04

Fare Calculation Engine

Fare rules, caps, zones, concessions, and service-specific pricing are applied automatically.

05

Exception Queues

Incomplete or suspicious journeys are routed to operational exception queues.

06

Customer Refund Portal

Customers can view journey history and raise refund requests through self-service.

07

Unified Support View

Support agents can view journey, fare, payment, refund, and case history in one place.

08

Refund Eligibility Rules

Refund eligibility is assessed using configurable business rules and controlled approval flows.

09

Payment Reconciliation Dashboards

Dashboards compare charges, captures, refunds, chargebacks, and settlement data.

10

Operational Analytics

Teams monitor failed taps, refund trends, maximum fares, device issues, and revenue leakage.

05 — Requirements

Functional Requirements

  • The platform must ingest tap events from gates, validators, onboard readers, and other transport devices.
  • Each tap event must include timestamp, device ID, location, payment token, transport mode, and route/service metadata.
  • Failed or delayed tap events must be logged and retried where technically possible.
  • The system must match tap-in and tap-out events using configurable matching rules.
  • The system must identify incomplete, duplicate, delayed, and conflicting tap events.
  • Unmatched journeys must be routed to exception queues.
  • The platform must calculate fares based on zones, routes, time bands, caps, concessions, and fare policy rules.
  • Maximum fare rules must apply where journeys remain incomplete.
  • Fare calculation outcomes must be explainable and auditable.
  • Customers must be able to submit refund requests against specific journeys.
  • Refund eligibility must be assessed using configurable rules.
  • Refunds above defined thresholds must require manual approval.
  • Refund decisions must be logged with reason codes.
  • Support agents must view journey, fare, payment, refund, and case history in one place.
  • Agents must be able to raise disputes, request investigation, approve eligible refunds, or escalate complex cases.
  • The platform must reconcile journey charges against payment authorisations, captures, refunds, chargebacks, and settlements.
  • Reconciliation mismatches must be categorised and assigned to payment operations queues.
  • Dashboards must show failed taps, incomplete journeys, maximum fare charges, refund volumes, refund reasons, reconciliation mismatches, device/location exception trends, and revenue leakage indicators.

Non-Functional Requirements

  • Tap events must be processed within defined operational thresholds.
  • Fare calculation must support high-volume peak travel periods.
  • The platform must support millions of journey events across multiple transport modes.
  • Additional routes, fare zones, and payment providers must be configurable without major redevelopment.
  • Payment tokens and customer data must be protected using strong encryption and access controls.
  • Staff access must follow role-based permissions.
  • The platform must support GDPR-compliant handling of journey and payment data.
  • Customer journey history must only be visible to authorised users.
  • Failed event ingestion, fare calculation, refund, and reconciliation jobs must support retry and recovery handling.
  • Critical failures must trigger operational alerts.
  • Fare calculations, refund decisions, manual overrides, and reconciliation adjustments must be fully auditable.
  • Customer-facing journey and refund services must remain available during high-demand periods.

06 — Process Diagrams

AS-IS contactless journey and fare workflowTO-BE journey capture and fare calculation lifecycleTap-in and tap-out event matching workflowIncomplete journey exception workflowFailed tap resolution processMaximum fare review processCustomer refund request workflowSupport agent dispute handling workflowRefund approval workflowPayment reconciliation workflowChargeback and settlement exception workflowDevice/location exception reporting flowCross-functional swimlane across passenger, validator/gate, fare engine, payment provider, support team, finance, and reconciliation teamData flow diagram covering tap event source, journey engine, fare engine, payment processor, refund module, case management, and dashboards

07 — Risks & Constraints

Risk

Delayed or missing tap events

Incorrect fare calculation and increased dispute volumes.

Constraint

Complex fare rules

High testing and configuration risk across caps, zones, modes, concessions, and service rules.

Constraint

Payment provider limitations

Refund and reconciliation constraints across authorisation, capture, settlement, chargeback, and refund processes.

Risk

Device outages

Failed taps and customer disputes caused by gate, validator, or onboard reader issues.

Risk

High peak-hour transaction volume

Processing bottlenecks during rush hours or major service disruption.

Risk

False refund approvals

Revenue leakage from weak refund controls or poor eligibility rules.

Risk

Overly strict refund rules

Poor customer experience and unnecessary support escalations.

Constraint

GDPR handling of journey data

Privacy and compliance risk when storing and displaying customer journey and payment history.

Constraint

Legacy fare systems

Integration complexity across existing fare engines, payment systems, and support tools.

Risk

Chargeback and settlement mismatches

Finance reconciliation risk and delayed mismatch resolution.

A phased rollout was recommended, starting with journey visibility, incomplete journey handling, and refund case management before expanding into advanced reconciliation and device-level exception analytics.

08 — Deliverables

09 — Outcomes & KPIs

24h

Refund processing time improved from 7 days for eligible cases

97%

Journey matching accuracy improved from 89%

55%

Manual refund review workload reduction

40%

Maximum fare disputes reduced

45%

Payment reconciliation mismatches reduced

35%

Customer support repeat contacts reduced

Live

Failed tap visibility moved from limited tracking to real-time dashboards

Lower

Revenue leakage from unresolved exceptions reduced significantly

Self-Service

Customer refund status visibility moved from limited to self-service tracking