Contactless Payments Support Framework
Issue resolution: who to contact and when
Introduction
How to use this document
Monitoring and maintaining our fare collection system
Ensuring consistent & reliable fare collection
Our fare payment system is made up of products and services from multiple vendors, each with their own issue-reporting systems, response rates and contact points for escalation.
This “live” document is intended to be used internally as a record of these processes, performance indicators and contact personnel. It should be completed in collaboration with our vendors, and reviewed every 3-6 months to ensure it is up to date.
Our contactless payment system
[XX transit agency]’s providers
The building blocks
There are three main components to our contactless payment system. Our providers and what they are responsible for are noted below:
FARE VALIDATORS
(DEVICES)
Onboard or on-platform devices that are equipped to read riders’ contactless bank cards and smart devices.
FARE CALCULATION SOFTWARE (TRANSIT PROCESSOR)
PAYMENT PROCESSOR (ACQUIRER)
Software that instantly determines the correct fare for a trip based on distance, applicable discounts, and frequency of travel.
Entity that transmits money from a rider’s bank card to our bank account.
[XX provider]
[XX provider]
[XX provider]
Common issues to troubleshoot
Some of the issues that may be experienced with the different parts of the system – or questions that may arise – are listed below:
FARE VALIDATORS
Possible device hardware issues:
Possible device software issues:
FARE CALCULATION SOFTWARE
PAYMENT PROCESSOR
Devices
Escalation process, contacts and performance measures
To be requested from vendor
Should include indication of the vendor’s expectations of the transit agency, plus interactions/connections with vendor’s service desk and technical teams
Support flow chart
To be requested from vendor
An indicative format is shown below
Response targets
Urgency | Description | Time to Respond |
1 Critical | Hardware and Software do not function at all or have such frequent and systematic interference that they cannot be used | Within 8 hours |
2 High | Hardware and Software have severe loss of functionality, but can still be used to a limited extent e.g. check in and check out can be performed | Within 1 Business Day |
3 Medium | Hardware and Software show minor shortcomings, but can be used normally (e.g. improvements can be put in subsequent Updates of the Software). | Within 5 Business Days |
4 Low | Queries outside the scope of the Agreement | Within 10 Business Days |
To be requested from vendor
Should state when the vendor is contactable and through which communication channels
Agreed service times
To be requested from vendor
An indicative format is shown below
Roles and escalation points
Contact | Escalation level | Role |
Service desk email | n/a | [System] to raise tickets with |
Name: xx Email: xx | 1st escalation | Technical coordinator/project manager First point of contact for day to day escalations. Works with the internal teams to resolve incidents/problems and fulfil client requests |
Name: xx Email: xx | 2nd escalation | Head of service operations Major incidents, service-related escalations and governance |
Name: xx Email: xx | 3rd escalation | Contract manager Contractual and commercial aspects, incident and project governance |
The table below, and overleaf, details the performance measures defined in the State of California Master Service Agreement for Category A – Payment Acceptance Devices.
Performance measures (1 of 2)
Key Performance Indicator (KPI) | Unit of Measure for Service Credits | Trigger for Service Credits |
The Payment Acceptance Devices shall have an Availability greater than 99.3% | Month | Failure to meet the KPI three (3) months consecutively or six (6) out of twelve (12) consecutive months. |
The Fare Management, Device Management and Reporting Services shall have an Availability greater than 99.5% | Month | Failure to meet the KPI three (3) months consecutively or six (6) out of twelve (12) consecutive months. |
The System and each of the services shall have a Recovery Time Objective of:
| Incident | Three (3) incidents of failure to meet Recovery Time Objective in a 6-month period or an accumulation of hours exceeding the Recovery Time Objective in a 6-month period, as follows:
|
Performance measures (2 of 2)
Key Performance Indicator (KPI) | Unit of Measure for Service Credits | Trigger for Service Credits |
Incidents managed to a lower level (e.g., from a Critical to a Major Incident) shall be fully recovered as per the Recovery Time Objective of the lower-level incident starting at the moment the incident has been managed to a lower level, provided that the incident has been managed to a lower level within 50% of the Recovery Time Objective of the higher-level incident. In all other cases, the System shall be fully recovered within the recovery time and start counting at the start of the initial higher-level incident. | N/A | N/A |
In case of any disruptive event, the Contractor shall be able to recover 100% of data that could have a financial or operational impact on the Transit Agency. | # of incidents during contract term in which less than 100% of data is recovered | One (1) incident allowed; each subsequent incident shall trigger Service Credits. |
The maximum time from an updated allow and deny list being made available by the Agency’s Transit Processor to the list being active in a Payment Acceptance Device shall not exceed 1 minute, provided there is a stable network connection to same Payment Acceptance Device and provided this has not been agreed otherwise with the Transit Agency. Contractor should take all efforts to minimize data usage by list downloads. | # of reported incidents in which a Transit Customer was denied access to a transportation service one (1) minute or more after an updated list made available by t Agency’s Transit Processor, with the Transit Customer’s credential removed from the deny list. # of reported incidents in which a Transit Customer was allowed access to a transportation service at least one (1) minute or more after an updated list made available by Agency’s Transit Processor with Transit Customer’s credential on the deny list. | Six (6) incidents in any three (3) month period or consecutively or twelve (12) incidents in any twelve (12) month period. |
Transit processor
Escalation process, contacts and performance measures
To be requested from vendor
Should include indication of the vendor’s expectations of the transit agency, plus interactions/connections with vendor’s service desk and technical teams
Support flow chart
To be requested from vendor
An indicative format is shown below
Response targets
Urgency | Description | Time to Respond |
1 Critical | System does not function at all or has such frequent and systematic interference that it cannot be used | Within 30 minutes |
2 High | System is functioning, but daily or time-sensitive functions are prevented from being performed. | Within 1 Business Day |
3 Medium | Issue arises that does not prevent daily or time sensitive functions being performed, but presents a material inconvenience, degraded level of performance or similar. | Within 5 Business Days |
4 Low | Issue arises that presents a minor inconvenience, requires an enhancement to a Service, or is the result of an advised event (e.g. upgrade). | Within 10 Business Days |
To be requested from vendor
Should state when the vendor is contactable and through which communication channels
Agreed service times
To be requested from vendor
An indicative format is shown below
Roles and escalation points
Contact | Escalation level | Role |
Service desk email | n/a | [System] to raise tickets with |
Name: xx Email: xx | 1st escalation | Technical coordinator/project manager First point of contact for day to day escalations. Works with the internal teams to resolve incidents/problems and fulfil client requests |
Name: xx Email: xx | 2nd escalation | Head of service operations Major incidents, service-related escalations and governance |
Name: xx Email: xx | 3rd escalation | Contract manager Contractual and commercial aspects, incident and project governance |
The table below, and overleaf, details the performance measures defined in the State of California Master Service Agreement for Category B – Transit Processor Services.
Performance measures (1 of 2)
Key Performance Indicator (KPI) | Unit of Measure for Service Credits | Trigger for Service Credits |
The Contractor shall have an Availability of 99.5% | Monthly | Failure to meet the KPI three (3) months consecutively or six (6) out of twelve (12) consecutive months. |
The Contractor shall have a Recovery Time Objective of 12 hours per incident | Incident | Three (3) incidents of failure to meet Recovery Time Objective in a six (6) month period or an accumulation of twenty-four (24) hours exceeding the Recovery Time Objective in a six (6) month period. |
In case of any disruptive event, the Contractor shall be able to recover 100% of data that could have a financial or operational impact on the Transit Agency (note that this includes, but is not limited to, tap transactions, deny lists, and account information). | # of incidents during contract term in which less than 100% of data is recovered. | One (1) incident allowed; each subsequent incident shall trigger Service Credits. |
The average time for the Contractor to process taps and add credentials to the deny list shall be less than 15 seconds after receiving a transaction from a PAD. | Monthly average processing time | Failure to meet the KPI three (3) months consecutively or six (6) out of twelve (12) consecutive months. |
Performance measures (2 of 2)
Key Performance Indicator (KPI) | Unit of Measure for Service Credits | Trigger for Service Credits |
The maximum time for the Contractor to process taps and add credentials to the deny list shall be 20 seconds after receiving a transaction from PAD. | # of reported incidents in which a Transit Customer was allowed access to a transportation service one (1) minute and twenty (20) seconds or more after a tap transaction has been received by the Contractor that subsequently failed authorization, provided that the Transit Processor’s processing time has exceeded twenty (20) seconds. | Failure to meet the KPI three (3) months consecutively or six (6) out of twelve (12) consecutive months. |
The average time for the Contractor to send a response to a credential inspection request from a Transit Agency shall be less than 1.5 seconds after receiving the request. | Monthly average response time | Failure to meet the KPI three (3) months consecutively or six (6) out of twelve (12) consecutive months. |
The maximum time for the Contractor to respond to a credential inspection request shall be 2 seconds after receiving the request. | # of incidents per month in which the response time exceeds two (2) seconds | Six (6) incidents in any three (3) month period or consecutively or twelve (12) incidents in any twelve (12) month period. |
The average time for the Contractor to remove a credential from the deny list shall be less than 15 seconds after receiving information that the Transit Customer has settled the debt. | Monthly average response time | Failure to meet the KPI three (3) months consecutively or six (6) out of twelve (12) consecutive months. |
The maximum time to remove credential from the deny list shall be 20 seconds after receiving information that the Transit Customer has settled the debt. | # of reported incidents in which a Transit Customer was denied access to a transportation service one (1) minute and twenty (20) seconds or more the Transit Customer has settled the debt, provided that the Transit Processor’s processing time has exceeded twenty (20) seconds. | Failure to meet the KPI three (3) months consecutively or six (6) out of twelve (12) consecutive months. |
Acquirer
Escalation process and contacts
To be requested from vendor
Should include indication of the vendor’s expectations of the transit agency, plus interactions/connections with vendor’s service desk and technical teams
Support flow chart
To be requested from vendor
An indicative format is shown below
Response targets
Urgency | Description | Time to Respond |
1 Critical | System does not function at all or has such frequent and systematic interference that it cannot be used | Within 30 minutes |
2 High | System is functioning, but daily or time-sensitive functions are prevented from being performed. | Within 1 Business Day |
3 Medium | Issue arises that does not prevent daily or time sensitive functions being performed, but presents a material inconvenience, degraded level of performance or similar. | Within 5 Business Days |
4 Low | Issue arises that presents a minor inconvenience, requires an enhancement to a Service, or is the result of an advised event (e.g. upgrade). | Within 10 Business Days |
To be requested from vendor
Should state when the vendor is contactable and through which communication channels
Agreed service times
To be requested from vendor
An indicative format is shown below
Roles and escalation points
Contact | Escalation level | Role |
Service desk email | n/a | [System] to raise tickets with |
Name: xx Email: xx | 1st escalation | Technical coordinator/project manager First point of contact for day to day escalations. Works with the internal teams to resolve incidents/problems and fulfil client requests |
Name: xx Email: xx | 2nd escalation | Head of service operations Major incidents, service-related escalations and governance |
Name: xx Email: xx | 3rd escalation | Contract manager Contractual and commercial aspects, incident and project governance |
[Transit Agency]
Escalation process and contacts
To be completed
Should include an indication of [transit agency]’s actions prior to reaching out to a vendor, for each of the services we receive.
Issue reconciliation flowchart
Roles and escalation points
Contact | Escalation level | Role |
Name: xx Tel: xx Email: xx | 1st escalation | e.g. General Manager |
Name: xx Tel: xx Email: xx | 2nd escalation | e.g. Director of IT |