The fundamental problem with payments software is that, for most developers, it’s a necessary evil. They must integrate payment-transaction capabilities so they can get paid for all the other code they’re writing. Now, thanks to one-size-fits-all application programming interfaces and tokenization that devalues everything, developers barely know a PAN from a PIN.
Standardization is a good thing, but always requires constraint. When standardized APIs and human-readable JSON (an open-standard file and data-interchange format) were coming into their own, the e-commerce revolution was a perfect use case—except for those pesky card numbers suddenly being flung about in everybody’s code.
Hosted payment pages and tokenization solved that, but not by convincing developers to behave with consumers’ private data. The solution proved to be never letting the developers touch a card number in the first place.
More recently, gateways have matured into more than card-not-present platforms, solving for retail environments with simple integration to their hardware catalogs. Along with EMV, semi-integrated methods achieve the same result, keeping sensitive payments data out of the digital hands of the developers and their merchants.
Transaction technology and payments-industry oversight have come far since the mag-swipe was king. Along the way, however, the art of payments has been lost.
I’m not suggesting that all developers should become payments experts. An ace gaming programmer shouldn’t have to know about prepaid BIN exclusion or small-ticket interchange programs. Her gateway provider, however, better know all that, and should be carefully guiding her when these or other factors come into play.
In payments integration today, the issue is endemic. Gateway providers expose lots of guides, but little guidance. API documentation is excellent at describing how to perform a transaction, but woefully lacking on why or when a transaction should be performed.
These gateways have built an industry around simple payment integration, scaling with automation, auto-enrollment, and hands-off integration environments. Requiring zero contact with the gateway, a novice developer can easily take an e-commerce implementation into production, but learns nothing about payments best practices along the way.
More and more, corrupted processing is the result. Merchants suffer blanket downgrades because nobody told the developers to settle nightly. A merchant’s mobile app doesn’t collect address-verification data, as it is too cumbersome for their users—resulting in massive declines and downgrades, along with a bank investigation for fraudulent activity.
At the same time, integration support desks aren’t supporting. Many independent software vendors don’t understand the basics of payments mechanics, and their processor partners aren’t educating them properly
Developers (and their chief technology officers) need to integrate payments, but they want to see payments as just another API call. Send a request, get a response. The gateway industry must do a better job of educating these developer communities in payments best-practices. That way, their merchants and acquiring sponsors won’t bear the costs and headaches of non-compliant processing.
—Cliff Gray is a senior associate at TSG, a payments advisory firm.