The ubiquity of the Plastic Payment Card has led many in the Payment Card Industry to assume that the processes that make these services work are straightforward and well understood at all levels.
This, of course, isn’t true.
The complexity of payment cards, the breadth of transaction processing technologies, and the fact that the only universal standard is the one that covers EMV contact transactions, means that it’s a borderline miracle that this stuff works at all.
Many developers, whilst excellent coders, don’t always grasp the card-in-hand, practical implications of the EMV processes they are trying to implement. It becomes apparent, when speaking with them, that they haven’t fully appreciated the nuances or the additional context of chip as they endeavour to apply EMV functionality to the more “traditional” magstripe processes that they are comfortable with.
EMV might have been around since 2002 when the Halifax first issued 12.5 million new chip & PIN cards, but for many it is still an unknown or misunderstood quantity.
For example, you might think that completing a contact transaction on a live card without needing the PIN wouldn’t be possible … but you would be wrong! It happens, and in all the cases that I have seen, it wasn’t down to malice, it was down to developers not quite understanding the EMV specification and the Mastercard EMV implementation guide.
Visualise the Design
Think about what you are trying to achieve and use that to develop your vision, then write it down. You can always do some tweaking as you gain more insight into your delivery, but having a vision will help you set and maintain your path.
Having a Vision will also help focus and direct the developers, as well as the marketeers and the rest of the team, and it works best if it’s presented from the perspective of the end user.
Without a Vision, product direction can only be derived from the interpretation of a set of discrete instructions – and we end up able to make POS purchases without a PIN!
On the one hand, establishing your Vision forces you to crystalise your ideas and defines the end product; on the other hand, having a Vision means that if the development process is knocked sideways, for whatever reason, it’s fairly easy to realign with the goal and get back on track.
Validate the Core Product
Whatever value-added services you might want to deliver to your card base, you can only deliver them if the supporting card base is solid.
Bear in mind that:
- it costs a lot of time, money and effort to elevate a card to top-of-wallet;
- it doesn’t take a lot for a cardholder to push a card to the bottom.
Review the logic behind the issuing processes … there’s a lot more to it than you might think, and the devil is in the detail. Then move on to payments and transaction processing and don’t forget to look at the support processes for those times when things go wrong.
If you are going to validate the core product with the precision it merits, the Product Team will need to understand the technology and the Developers will need to understand the business.
So, review the logic, walkthrough the product lifecycle, be the transaction and be the consumer … you are looking for the “gotchas”.
Check the Hygiene Factors
Assure yourself that all the hygiene factors work effectively for the end user and that they do so without the need for a degree in IT or Banking. All too often, we see new, and old, components that work on a technical level, but as a user feature, they’re pants.
The following are hygiene factors, which means that they are services that a cardholder may reasonably expect to be provided a part of a standard offering rather than what may, in the past, have been value-adds.
- X-pays and Wallets
- Banking Services that support card accounts
- Strong Customer Authentication (SCA) and Messaging
- Account communications
- Customer Services
Customer Services should possibly be higher up the list and not an afterthought.
None of the above are particularly compelling selling points, as they offer very little in the way of differentiation. However, whilst they may not be a strong reason to buy, if they are not working just right, they are all reasons why customers may reconsider their reason for buying.
Again, if you are going to assure yourself that any component is working as intended, then the Product Team needs to understand the technology and the Developers need to understand the business – it is up to all of us to share the knowledge and the information that will allow us to share the responsibility.
Develop the Value Adds
Value Adds are additional features that can be offered alongside standard payment functionalities to improve the customer and merchant experience.
They can turn a solid product that does what it says on the tin (pretty much like every other solid product) into a Cardholder’s go-to payment application, taking its place at the top of the cardholder’s wallet.
The more obvious Value-Adds include Loyalty and Rewards initiatives, but the list could easily include additional features aimed at SMEs and members of specific groups – the features are limited only by the ingenuity of the Product Team, the application of the Developers and the needs of the target Demographic Group.
And so …
Value-Adds are service differentiators, that pull consumers in and, oddly enough, add some value to their lives.
Hygiene Factors are the facilities that consumers expect to see and expect to just work.
The Core Product is invisible.
Consumers go shopping to buy shirts (and groceries), the payment service is incidental and invisible … and only becomes visible when it doesn’t work!
Product Teams need to be aware of the technology that supports the invisible foundation, and Developers need to understand why they are doing the developing.
