Month: February 2024

Network tokens power modern subscription models

It is easy to think that the rise in the use of network tokenisation is stimulated by the increasing dominance of Apple Pay in mobile transactions. However, there is no doubt that network tokenisation also offers clear security and customer convenience advantages which are starting to drive up adoption. They replace card data with unique tokens in coordination with the card networks and issuers. They thus enable transactions to go ahead even if a card has been lost, locked, or expired. In other words, network tokens can power the modern trend for regular, subscription-based paying.

How then do network tokens secure transactions?

When provisioning a card, a unique network token is generated automatically by card networks such as Mastercard, Discover, VISA and American Express. This token is then securely transmitted to the merchant’s payment process or gateway whenever a payment is to be made. The payment processor decrypts the token using a secure key provided, again, by the card network. The payment processor then sends the decrypted token to the card network for authorisation. The card network verifies the token and ensures it corresponds with the correct cardholder account. If everything agrees with the network’s records, the transaction is approved and the merchant receives the payment.

It’s great for smaller merchants as those accepting network tokens have reduced PCI DSS compliance requirements. It’s also great for customers as they don’t have to continually tap in card details into online interfaces or card terminals. This fact alone reduces the risk of card fraud by as much as 26 per cent, according to research commissioned by PYMNTS.com.

Better still, if a customer wants to terminate an in-app subscription, or is worried about the integrity of any merchant, they can simply revoke the single network token relevant to that merchant. They don’t have to cancel any of their cards – something which customers hate doing because it takes over a week to get a new card issued and often several weeks to manually update all the card details linked to the multiple online subscriptions which are now tied to the revoked card.

The role SoftPOS can play with network tokens

So how does this impact SoftPOS providers such as Mypinpad?  The initial provisioning of network tokens requires the gathering cardholder data which brings with it onerous PCI-DSS compliance requirements for merchants, while exposing cardholders to real security risks.  Our SoftPOS solution can protect the cardholder data with that initial card present transaction while ensuring a seamless customer experience.

How is this done? We have an SDK that can be embedded into a merchant app that can perform all elements of the payment process from transaction right through to provisioning. This keeps customers safer, while massively reducing PCI-DSS requirements for merchants, including those offering subscriptions.

Real power of network tokenisation in enabling subscription-based models

We are buying more and more products and services via subscription today. Next time you are in your core business or personal bank account statement, count up the number of regular monthly subscriptions you are already paying for monthly. You might well be paying Adobe, Microsoft, Amazon, Xero and a number of other tech firms for up-to-date access to their software suites. Increasingly, we are buying cleaning, gardening, delivery, entertainment/TV and other home-based services by subscription also. Put simply, network tokens are currently the most secure and convenient way to power the growth of subscription-based buying.

Apple versus Android

The other linked development is payment via a merchant’s mobile app when on the move. Here too network tokens can be used to complete transactions – eliminating the need to show a bank card to a reader in public. Android mobiles have a head start since they offer open NFC access today.

By contrast, Apple exerts a good deal of control over NFC payments going via its iPhones via Apple Pay. Apple currently also places restrictions on third-party access to the iPhone’s NFC technology although this too is changing as the tech giant recently unveiled plans to allow software developers across the EU to distribute their apps through channels other than Apple’s App Store.

And from next month, developers will have the option to provide alternative app stores on iPhones and can opt out of using Apple’s in-app payment system, which traditionally charges commissions of up to 30 per cent. This will offer a further boon to regular in-app, network token-based mobile payments. It all contributes to a blurring of the lines between card present and card not present transactions.

Network tokenisation offers key to next wave of payments change

Surely, as we head towards the second quarter of the twenty first century, we must seek to embrace a highly secure and yet more customer-friendly level playing field for enabling mobile app payments to merchants without exposing app developers to punitive charges, some of which inevitably end up in transaction charges to merchants and then being passed onto consumers. Network tokenisation is definitely part of making this happen, and Mypinpad is in a terrific place to support this important new development.

Flexibility with security is the ideal behind MPoC

PCI Security Standards Council (PCI SSC) published its new standard PCI Mobile Payments on COTS (MPoC) a little over a year ago in November 2022. MPoC of course builds on the existing PCI Software-based PIN entry on COTS (SPoC) and PCI Contactless Payments on COTS (CPoC) Standards, which individually defined security requirements for solutions that enable merchants to accept cardholder PINs or contactless payments using a smartphone or other commercial off-the-shelf (COTS) mobile device.

More precisely, the PCI MPoC Standard aims to provide increased flexibility – not only in how payments are accepted but in how COTS-based payment acceptance solutions can be developed, deployed and maintained or, as it was described at the time:

“PCI MPoC is a new, flexible mobile standard and program for payment solution development. It provides a modular, objective-based, security standard that supports various types of payment acceptance channels and consumer verification methods on COTS devices. PCI MPoC combines many of the aspects of the existing PCI SPoC and PCI CPoC standards, primarily by including the entry of both PIN and contactless cardholder data on the same COTS device.”

Now that MYPINPAD has been through the lengthy and expensive process of validating and accrediting its software to comply with the MPoC Standard, we can finally communicate with a little authority on what PCI SSC might want to consider changing to stimulate more rapid adoption of the new standard by payment technology providers, merchants and ultimately consumers.

To clarify, we believe it is better for the entire industry to adopt this new ‘belt and braces’ standard sooner rather than later, not least to clear the path for the SoftPOS payment ‘hyper growth’ which many are now forecasting for the next five years.

So, which areas need to be considered for improvement of the MPoC Standard to increase adoption of the standard and avoid consumers switching to potentially less secure methods of transacting such as QR code payments and digital wallet-based Peer to Peer payments which often have unknown security and standards?

Considering ‘Real World’ Application to Encourage Adoption

Because MPoC focuses on security specifications for mobile payments in isolation, this often bakes in a complex pin pad customer experience which might easily be off-putting thereby slowing adoption. Instead, it should be possible for the Standard to consider mimicking the highly familiar ATM pin pad on all mobile devices handling transactions. In this way, acceptance is likely to be much higher because many consumers remember their pin based on the pattern of where each key is on a traditional ATM (rather than by the sequence of numbers itself). As soon as you change the layout of the keyboard, trails have found, you risk the failure of up to 30 per cent of transactions which consumers attempt via POS-enabled mobile devices.

The reason, the PCI SSC faithful might tell us that they do not want to have predictable pin pads on smart devices is that it will be easier for merchants to harvest those pins and marry them with card details they are holding. Of course, in reality if a merchant wanted to harvest pin numbers it would be far easier to tip the CCTV camera, often situated above the cash till, more in the direction of the position where the customer puts in his or her pin number.

However, assuming the merchant is PCI DSS compliant, they will find the stolen pin codes useless without the corresponding card data which they will not be able to harvest in any POS system. Likewise, it will be difficult to capture the card details via even the most carefully specified and positioned surveillance camera. Of course, increasingly the card details are never shared but rather network tokens are used to make this too impossible.

Apply Risk Matrix

This leads me to my second thought. Should Standards be stratified or layered based on size and therefore risk-level associated with a transaction? So, much like in the UK, where we no longer need to put our physical cards into the merchant’s payment terminal and type in our pin code if the transaction is below £100, levels of security technology should not be applied if transactions are for relatively trivial amounts which do not justify some processes.

So, for example, could transactions of less than £10 by-pass the payment attestation process to speed up the processing of the transaction and enable the money to move to the merchant’s account faster, thereby reducing transaction costs? Now this would surely deliver on increased flexibility, with security requirements moving in line with the real risk level, transaction by transaction.

Containing Operational Costs

As the next generation of payments reaches us, there is a natural expectation from merchants that they will need to pay less to transact, particularly in the SoftPOS world where they are applying their own mobile devices to the task rather than going to card issuers or banks to rent expensive POS terminals. While the consumer expects greater convenience and speed.

However, the current risk is that operational costs for the merchant will actually be driven up if the MPoC Standard is adopted as it is today. We know as an SDK provider for SoftPOS that the costs of compliance with this and others PCI Standards, amount to hundreds of thousands of pounds annually. The more the Standard demands of technology providers and other participants in the payments ecosystem the higher the operational cost to the merchant, and the higher the risk of non-adoption. The risk is that less secure systems will thrive and/or less centralised standards will proliferate without some adaptation of the MPoC Standard. That cannot be good for either merchant or consumer. It may stifle innovation as the barriers to entry prove too high for many.

Inevitably, some technology providers will look to defer MPoC implementation for as long as possible and instead elect to go with one or other (or all) card issuer waiver options. We are already VISA Waiver Version 1.8.1 certified for example since this standard provides most of the benefits of MPoC (especially as we have an SDK) with fewer downsides.

These waivers are not a long term solution for anyone since each scheme’s requirements are different.  Each waiver granted by a scheme is unique and is limited only to the specific circumstances of the individual request.

However, this is not always the case and changes can be made by the issuer to bring them out of alignment with other issuers’ waiver schemes as well as the core PCI standards. The merits of an all-encompassing centralised MPoC Standard become clearer when you look at uncertainties which decentralisation brings. Level but also stratified and centralised data, together with security standards are the key to more rapid adoption.

The other risk as mentioned before, is that more digital transactions are conducted in a less secure way in which consumer protections like rights to repudiate (cancel, review and re-issue) transactions if errors have been made, are in doubt.

Well-designed, Fully Isolated SDKs Should Not Have to go Through Domain 2/app Integration Testing & Certification

Finally, more specifically there may be a need to review Domain 2/app integration requirements. As one size for application and Software Development Kit (SDK) integration testing does not fit all. Domain 2 app integration testing and compliance should not be necessary for SDK’s like MYPINPAD’s SoftPOS SDK which protects and isolates its SDK from all payment data associated with a card present face-to-face transaction. This adds unnecessary cost for well-designed SDKs built with security and rapid and seamless integration in mind.

Most importantly, it serves as a barrier to adoption of payment acceptance technologies by merchants who are not familiar with the new certification process.  We envision every merchant app to be a payment app. This MPoC requirement discourages this and will limit adoption.

Layered Security Commensurate with Transaction Risk

In summary, the key is to drive the MPoC Standard through the mobile payments world as quickly as possible. However, to stimulate that rapid adoption there is a need to consider real-world consumer experience. I gave just one example around replicating the ATM-like pin pad to reduce transaction failure rates.

There is a need to also run a risk matrix over transactions so that smaller transactions where losses to customer and/or merchant are not high, perhaps sub-£10, can be ascribed lighter security requirements to keep transaction costs down.

Finally, the ‘belt and braces’ approach in Domain 2/app integration testing and certification also looks like ‘overkill’ for professionally designed SDKs which isolate their own code from other systems while enabling smooth plug-in to payment apps. We shouldn’t let perfect be the enemy of the good!