Chapter Five: The Role of the Payment Service Provider

<< Go back to Part 4: Hardware - Point of Sale Validators

The Basics of Processing a Payment

In its most common form, payment processing occurs in a ‘4 party model’. The 4 parties are:

1. The Customer (or the traveller in transit): purchaser of the services and owner of the payment card or mobile wallet
2. Issuing Bank (Customer’s Bank): issuer of the payment card
3. The Merchant (Transit Operator): seller of the good or service
4. Acquiring Bank (Merchant’s Bank): responsible for processing the transaction

Payment processing involves complex and intricate relays between the Issuing Bank and the Acquirer for authorisation and settlement.  A simplified description of the flow is described below.

After the customer either taps their card (‘card present’ transaction) or submits their payment card details online (‘card not-present’ transaction), the acquiring bank receives a request to authorise a payment. Acquiring banks (Acquirers) process payments for merchants. This authorisation request will contain encrypted information about the card, the expiry, the amount to be authorised. The acquirer then routes this request to the payment network of the card making the request (Visa, Mastercard, etc). Acquirers are connected to payment networks for which they acquire payments through a licensing arrangement.

Some examples of Acquirers are: Elavon, Rapyd, Fiserv, WorldPay and Adyen.

The payment network then routes the authorisation request to the specific issuing bank that holds the customer's debit or credit card account.

The issuing bank verifies the customer information and checks for available funds.  After a range of checks, if the information is valid the issuing bank sends an approval code back to the card network, and places a hold on the funds. The payment card network in turn sends the authorisation code back to the acquirer to approve the transaction. If the transaction is ‘online’, this authorisation process is completed in a matter of seconds.

Once the transaction is completed, the acquirer will then send a settlement request, in a similar manner to the above, and the funds are transferred from the Issuing bank to the Acquiring bank in a few days.

It is the Card Networks, like Visa, Mastercard, Amex and Discover, who licence the ‘‘payment rails’ (or scheme) by which the Banks communicate with each other to authorise and settle transactions. The card networks specify the various rules and requirements to ensure card transactions are processed reliably and securely across the world. 

Payment Processing Fees

The diagram below is a simplified illustration of a payment flow, and the fees associated with each component.

• Merchant Service Fees: This is the fee paid by the Merchant for payment processing services provided by the PSP and Acquirer. It is a per transaction fee and usually a small percentage of the transaction value. In most cases a transit agency or operator will contract with Littlepay to manage the acquiring relationship and will pay a bundled rate for payment processing. However larger cities may have a direct relationship with the acquiring bank, in which case the PSP and Acquiring fee may be separate.

• Interchange Fees: This is a fee paid to the card issuing bank. Interchange fees vary by card type, and by jurisdiction. A transaction made by a foreign card will have significantly higher interchange fees than a domestic transaction. As a general rule Debit cards have lower interchange fees than credit. 

• Scheme Fee: The card networks charge the acquirers a licensing fee per transaction. Each acquiring bank will have its own arrangement based on the volume of transactions it processes.

Littlepay usually provides its service on an Interchange++  basis. This means that the Interchange Fee and Scheme Fee are passed through to the transit operator at cost. The alternative to Interchange++ is a Blended Rate. This is where the merchant pays a single fee per transaction for all transactions, regardless of the type of card used. In order to offer this, acquirers will assess the merchants usual transaction volumes and distribution of card types to estimate the likely cost of variable fees such as Scheme and Interchange. They will then add in a buffer to cover the risk of the assessment being incorrect. Blended rates offer a known cost of processing for the merchant but can often be more expensive than an Interchange++ model.

The acquirer is able to provide detailed information regarding the fees for every transaction. Usually, all fees will be deducted from the value of the transaction and then settled into the Merchant’s bank account. This is referred to as Net Settlement. 

What is a Merchant of Record (MoR)

A MoR is a legal entity that is responsible for selling goods or services to an end customer. The MoR name appears on the customer’s bank statement as the Merchant and is typically the entity that is responsible and in control of the customer relationship.

Transit operators are often already a Merchant of Record for services such as ticket office and Ticket Vending Machine (TVMs) payment processing.

Some transit ticketing vendor’s offer third-party Merchant of Record services and then act as an intermediary between a transit operator and its customers, taking responsibility for all of the payment processes, retail customer support queries and liabilities on behalf of the business. That puts them in a position of power in the funds flow, acting as a reseller of the transit services and receiving the funds from the customer when purchasing a ticket. The transit ticketing vendor will then transfer the funds to the transit operator at a later date, often for an additional administration fee

Where does the Payment Gateway or PSP come in?

Acquiring banks are large global regulated financial institutions. Their strength is having large-scale infrastructure that can process billions of transactions for tens of thousands of Merchants. Their priority is ensuring the reliability of standardised high-volume processing and managing fraud.  

As a result, Acquirers are less focused on smaller merchants or providing flexibility to optimise the payment experiences for industry specific needs. This is where the more modern Payment Services Providers (PSP’s) or Gateway’s come in.

PSP’s work in partnership with acquiring banks to improve the merchant and customer experience, and reduce friction throughout the integration and settlement process. PSP’s like Stripe started out by simplifying the complex onboarding processes, digitising paper flows, and modernising user interfaces. Over time, they also added capabilities to reduce transaction abandonment rates, reduce fraud, and add functionality that improved the customer experience in industry-specific use cases, such as online marketplaces (where the merchant is not the seller) or splitting payments for a cab fare, and other variations. PSPs differ in terms of cost, speed and capability to suit the varying needs of merchants. 

The unique challenges of payments in transit

As we alluded to in Chapter 1, bank card payments in public transit have their own set of unique challenges that necessitate some specialised infrastructure and flows:

• Payments need to be processed instantly: retail stores can still afford a slight delay of two or three seconds between the moment a customer taps their card and the moment the payment is authorised. In transit, the standard is 300 milliseconds to reduce congestion. Acceptance with such timescales means we don’t have time to check if the customer has adequate funds in their account. This in turn has implications for risk.

• The system needs to work online and offline: retailers are usually connected to Wi-Fi or a mobile network. If the POS device is down, you have to wait and try again. In public transit, it is sometimes necessary to take payments underground or in remote, rural areas, where connectivity isn’t guaranteed. 

• There is risk to manage: the first time a passenger taps their card on a transit network, the amount to charge isn’t known and the payment isn’t fully authorised. If the passenger has no funds, or the transaction fails, a system is required that can recover the payment and deny subsequent travel. 

• Values are often unknown at the point of sale: when a customer taps to pay at a retail store, the value of the payment is known. With transit, the value will differ depending on how far they travel, what zones they go through, whether they are eligible for discounts or whether they have hit a fare cap. There can be thousands of different fare variations and this requires a set of different approaches.

• Transaction costs must be managed: the average transaction value (ATV) of a retail transaction is $20-$50. In transit the average transaction value is an order of magnitude smaller, $2 - $5. This lower ATV means that payment processing can be much more expensive due to fixed fees in place. The ability to aggregate transactions before processing, to minimise fixed fees can have a big impact on overall cost in some jurisdictions but this is not possible with standard online retail transactions

• Transit data is not just about the transaction: retailers are mostly interested in ‘sales’ data of different products. A transit ‘product’ is a more fluid concept that can change depending on frequency of travel (e.g. a capped product), the designation of the individual (e.g. a Veteran) or a range of other factors, about which data is needed.

• Payments is a small part of a much larger, complex ecosystem: large transit agencies and operators are often complex organisations with sophisticated reporting demands, control hierarchies, complex fare management systems and extensive customer support needs. Integration with this infrastructure is necessary to deliver the optimal operational and customer experience.

These challenges have been embraced by the industry and are visible in the transit focussed specifications issued by the major Card Schemes. Examples include Visa’s Urban Mobility specification and Mastercard’s Global Transit rules. A PSP implementing the Card Scheme specifications offers agencies and operators payments processing with: 

• Fast boarding/entry times

• Secure offline processing

• Risk management protocols to reduce the risk and volume of declined transactions

• Debt recovery processing to recover any debt incurred

• Aggregation to allow transactions to be tallied up at the end of the day to calculate fares and reduce the impact of fixed fees on cost of sale

However, in the same way as PSPs in the general retail world differ, so do PSPs in the transit world. In addition to simply meeting the technical specifications of the Card Schemes, a true transit PSP can add value to an agency's business and its passengers, offer ROI and help to reduce the overall cost of sale. It can become a payment partner to the agency to innovate and evolve throughout the lifetime of the partnership. 

Littlepay - the first transit specialist PSP

Littlepay was founded in January 2016 to address these unique challenges, and to develop a more accessible, affordable solution for the transit industry. We set out to disrupt the traditional model for transit ticketing which relied on bespoke, turn-key, single-vendor-solutions, and used expensive proprietary hardware and software technologies to accept contactless payments. Processing payments for the transport industry is the only thing that we do; it is not a sideline business for us. Our leadership and continued success is based in deep expertise in both payments and transport, allowing us to innovate and deliver value to partners, operators and passengers.   

This specialisation has proven to be our superpower, allowing us to work closely with our agency’s and operators to understand their emerging requirements and evolve the platform to the benefit of all in our operator community, whether they are a three bus rural operator or a multi-thousand vehicle operating group, city or country. Together with some of our most innovative operators, we have identified product features and enhancements to offer a supercharged transit PSP service, over and above the Card Scheme transit specifications.

Innovation Toolbox 

Modularity

We are a specialist payments provider to the transit industry. We do not sell hardware, mobile apps, or back office solutions. Instead we build APIs and open configurability to partner with like-minded organisations in the transit ticketing industry. We have over thirty different device integration, transit apps and back office partner companies working with Littlepay today. The intention is to componentize fare collection systems allowing operators and agencies to select the best of breed solutions that are relevant to their specific requirement in their specific geography and not be forced to compromise on any one aspect of the solution. 

Littlepay’s approach is:

• Open: published APIs that allow other vendors to integrate with our platform

• Flexible: enabling integration with multiple vendors to avoid lock-in to a proprietary solution

• Configurable: a single code-base that is highly configurable - we don’t code, we onboard

• Scalable: a fully cloud-native platform in AWS with scalable elasticity

• Partner driven: a network of fully integrated partners of all disciplines to get our data and functionality into specialist suppliers of data, customer management, retail and fare management systems

The Littlepay platform offers an omni-channel payment solution including:

• Littlepay Contactless: contactless EMV payment in transport for 

• Littlepay Checkout: e-commerce processing for web and app based payments

• Littlepay Unattended: online retail payments processing in services such as queue busting, parking and EV charging 

Our simple-to-use API integrations eliminate vendor lock-in, drive innovative solutions and allow great collaborations between operators and suppliers. 

Enhanced Risk Management

We value every penny processed on behalf of our operators. We have analysed years of transit processing data to implement features over and above the card scheme specifications to reduce revenue loss, optimise payment acceptance rates, reduce processing fees and implement fraud control mechanisms to close down transit specific threats. Some examples are given below:

• PAR Deny Lists: When possible fraudulent activity has been identified on a passenger’s account, their payment credential is added to the deny list and all linked payment credentials, linked under the Payment Account Reference (PAR), are also added to the deny list, ensuring that there is no risk to the transport operator that further debt will be incurred from an account where suspected fraudulent debt has already been accrued. 

• Configurable Rules: Risk rules have been implemented by Littlepay to enforce the scheme specifications and offer configuration within those parameters to tailor risk management settings. Littlepay can advise on optimum settings for configurable items. 

• Fraud monitoring: Littlepay Operations manage a variety of fraud detection dashboards which aim to identify suspicious activity. Any issues are escalated and investigated such that remedial action can be taken to reduce the threat - e.g. adding the token to a PAR Deny List or a deny list. 

Omni-channel and the shared token

Transit specifications focus purely on the Card Present experience referring to a passenger physically tapping a payment card or mobile payment device to enter a transport network. This can become a limitation for operators with multiple sales channels in their network such as e-commerce solutions for ticket purchases or post payment account based travel, who then have to use multiple PSPs.

A transit PSP offering an omni-channel transit payments platform can create a unified passenger experience with tokenisation of bank cards and mobile wallets used across channels. The resulting common token enables agencies to unlock passenger value in a variety of innovative ways.

• Enhanced passenger engagement: Use of the “common token” enables a new level of engagement in the mobile app creating a link between the physical PAYG taps and the cardholder via the app. When Littlepay sees a tap on a transport reader it can then match that card with a mobile app user. This enables operators to to interact in real time with a user that has just tapped their card or phone. This can be used to provide contextual information, nudge passenger behaviour, or help a passenger to resolve their own queries and reduce the demand on customer support services. Littlepay has integrated with industry leading mobile app providers to help deliver valuable visibility, support and information to passengers using payment cards for public transport. 

• Card As Authority to Travel (CAAT): CAAT involves linking a passenger’s payment card with a travel right such as a weekly pass, concession or account. This association allows passengers to travel using just their bank card as their ticket in place of a paper ticket, smartcard or mobile QR code automatically receiving a discount or ensuring that they are not charged where an applicable ticket has already been purchased. 

• Regional Multi-Operator and Multi-Modal Capping: Littlepay offers its Broker Service to deliver intra-group or region wide capping. It addresses the complexity associated with linking together different open loop solutions where tokenisation and a single view of a passenger can be difficult. Operators integrated to the Broker Service can configure their own capping products for their own services while also participating in any group wide capping initiative.

Ongoing Innovation

In a world of rapidly evolving technology it is more important than ever to work with partners that are open to working with other vendors, flexible to respond to changes, and deeply understand your needs.  

No solution is fully future-proof, but having modular payment infrastructure provided by a supplier with proven expertise and a collaborative approach can expand your horizon and significantly reduce the risk.

Go To Part 6: Procurement Pitfalls >>