Ticketing and Payments Integration: The Pitfalls of a Deregulated Environment

This is the sixth of short series of eight articles that aims to better define the requirements, limitations, and the potential pitfalls to avoid when delivering Digital Mobility Platforms (DMP’s) – previously referred to as MaaS – within a UK deregulated transport environment.

This article will concentrate on ticketing and payments, specifically identifying the challenges that deregulation and multi-operator platforms can create. This article will also discuss how payments integration can be approached and the benefits and disadvantages of different integration levels. This also goes hand-in-hand with the user experience, which in my view is critical to the overall success of any transport application but is exponentially more important for DMPs.

While no app can profess to be the best at everything, it is essential that we strive for the best possible user experience when delivering DMPs, because in general there will be other operator specific apps that can be used if they are deemed to be providing, better, cheaper, quicker or more convenience that the DMP solution that you have created.

A Couple of Words of Warning

Before continuing with the elements that may need to be considered for ticketing and payments within your DMP, we feel it is necessary to state that ticketing and payments in a deregulated environment is perhaps the single biggest challenge to success. Let us explain – if, for example, you have ten different transport operators, and each of those has a different digital ticketing solution, you will need to integrate with each of these. Depending on the flexibility of your providers’ ticketing solution, these may take from a few days to integrate with, to multiple months. And then, if you also need to offer multi-operator tickets, or a fare-capped solution, the magnitude of the issue is multiplied. Of course, if you only have two or three operators this is less of a concern, but should still be analysed carefully before deciding on the right approach for your DMP.

Likewise, each different operator is likely to have their own preferred payments service provider (PSP). Integrating with one PSP is a multi-person, multi-month activity, and would quickly become cost prohibitive if your platform provider needs to start an integration exercise with multiple PSPs. While some platform providers do offer their own payments processing approach, this then requires agreements with each of the operators, and for the authority or platform provider to be responsible for reconciliation, which can also have an impact on data sharing under GDPR guidelines. It can potentially require either the Authority to be GDPR compliant or the Platform provider, or even require shared responsibility. This is something that must be considered prior to deciding on the right approach for your own platform. Some platform providers may already have implemented with multiple PSPs as part of their white-label solution, but both payments and ticketing requires full analysis before deciding on either the best approach and the best platform provider to meet your business needs.

Core Ticketing and Payments Requirements

The following section provides a little more detail on at least some of the elements that should be considered when specifying, designing, and delivering your platform. At present, every solution that has been delivered both in the UK and abroad has been quite bespoke, and therefore it is not suggested that this list of expectations, suggestions or requirements is comprehensive for your specific needs, nor will your own solution necessarily need everything identified. But it should provide a good baseline from which to at least start developing your specification and deciding on your approach.

Ticketing is Complicated

When Jorgen worked for a full-fare collection ticketing provider in the US, their mantra was “if you’ve seen one transit operator – you’ve seen one transit operator” meaning that in almost all aspects of systems, approach and operations, each transport operator does it differently. Tariffs vary, business rules are different, one operator may have a day that starts at 12:00am, another might have theirs starting at 4:00am. A monthly ticket may be 28 days, 30 days, 31 days or a calendar month. Activation times can vary depending on whether it’s a digital ticket, or a visually validated ticket and can vary from starting immediately on ticket purchase, to before or after a ticket has been activated. A short delay after activation is often implemented to prevent a customer from trying to only activate their ticket when they see a ticket inspector, rather than when they board their bus, tram or train.

Open Loop or Contactless EMV (cEMV) solutions are often seen as the panacea to all things ticketing, and while these solutions are “in general” easy for the customer to navigate, one should consider how such systems should be represented or accommodated within your DMP platform.

Some of the areas that you may want to also consider are:

1. How will you offer concessionary fares?
2. How will a concession be verified?
3. Will you be able to see activation events, and scanning events?
4. If not, how will you accommodate refunds in the event that a ticket is claimed not to have been used, or not to have been able to be scanned?

Your approach to the above questions will determine which tickets one should offer as part of your DMP platform, without unduly exposing the operator to the opportunity of fraud.

Visual Validated Tickets

Visual validated ticketing can be a great way to provide a multi operator ticketing solution without the complexities of providing integrations with multiple digital platforms. For smaller operators this presents a real opportunity to delivering digital ticketing without the expense of back-office systems, validators, and the associated installation costs. Many operators provide these as part of their standard ticketing solution. Most of these work on the basis of “word” of the day or “colour” of the day, and are provided to drivers and fare control officers on a daily basis. Some are a little more sophisticated, and provide a slowly evolving watermark, which is virtually impossible to replicate, and in some cases makes it even easier for a driver or fare enforcement officer to spot a fraudulent ticket.

In our view visually validated tickets are useful, and can be the difference between a solution that will be cost prohibitive and one that can be implemented quite quickly. It can accommodate multi-operator environments, either as a multi or single operator shared ticketing solution. It can also plug a gap in the event that an operator’s ticketing solution is in change, and therefore can prevent the need to implement an historic solution while a new ticketing solution is made available.

Payments, and Payment Service Provision

Payments is a horribly complex area, and your approach to this can be the difference between not only a technologically viable solution, but also a viable solution from a user experience point of view. For example, if each Mobility Service Provider (MSP) or Transport Operator has their own PSP, and requires their PSP to be used, they might also have an Application Programming Interface
(API) which enables the platform provider to integrate with the MSP’s PSP.

Unfortunately, operator specific APIs are still reasonably uncommon, leaving other rather limited options:

1. Implement a large integration with all operator’s PSPs, that the platform provider does not currently have an integration with. This is both costly and time consuming.
2. Implement a single PSP and then use that PSP for all payments across all operators. The issue with this is that this requires an agreement to be brokered between the authority and each MSP. This will also require that a reconciliation process is defined and that some authority or platform provider resources it for the duration of the contract. Agreements will need to be brokered to identify how to pay for not only the resources, but also the PSP, Gateway and acquiring bank costs. And of course, there will also need to be an understanding of how GDPR will be accommodated, who will be the controller, who will have access to what data, and whether there is a need to have joint data controller responsibilities, based around your proposed reconciliation process.
3. Deep links are links directly to an alternate system or service. These can be implemented when no APIs exist, or because a specific API endpoint does not exist. Deep links transfers a user from one platform to an alternate platform. To provide an example, if APIs don’t exist for a micro mobility provider, one can set-up a relay to move the user to the micro mobility providers native web service or application, where a user can do whatever they need to do before being returned to the DMP platform. The problem with this is that it provides a pretty poor user experience. For example, a user could be in your DMP, get transferred to a bus operator, from where they are able to select whatever ticket they require, pay for that ticket, and then get returned to the DMP. If they now want to use the ticket, they have just purchased they may need to now log into the operator’s app and go to that ticket wallet to retrieve and use the ticket. It’s just clunky, unhelpful and can be quite confusing to navigate. For this reason, using deep links is personally my least favourite approach to integration.

Conclusion

We firmly believe that the current method of implementing integrated ticketing and integrated payments is perhaps the biggest single barrier to delivering successful DMP platforms in the UK. The deregulated landscape coupled with different ticketing solutions, standards, products and business rules and lack of encouragement or incentives to collaborate, truly make the delivery of Digital Mobility Platforms in the UK a significantly greater challenge than delivered almost anywhere else.

But it’s fair to say that those challenges can to some extent be offset by having a great platform provider, who already has or will integrate with a flexible and configuration-based ticketing platform.