In the payment facilitator world, APIs are everywhere you look. In many cases, they’re the mechanism that allows the system to work – enabling payments infrastructure to integrate with other functions in a way that solves businesses’ unique problems.
So not surprisingly, API security is a hot topic. Does the use of APIs leave merchants more vulnerable to fraud? What are the special security considerations?
PaymentFacilitator.com asked Cliff Gray what he thought was important for payment facilitators to know right now. Gray is a principal with Gray Consulting, where he advises merchants, merchant acquirers, and payment technology providers about payments acceptance and security.
Gray recommends that payment facilitators take a hard look at two areas that may not be getting enough attention: authentication and role identification. He says it is imperative for payment facilitators to take the time to develop robust policies and procedures, and then to build their enforcement into the software.
“If I’m building an API that’s going to allow my customer to accept payments, what kind of rules am I going to build into that API to keep me safe?” he asked. “They have to have the corporate bravery to build these policies and then enforce them through APIs.”
Am I Who I Say I Am?
Authentication is key to any security program, and when you’re dealing with payment information, it becomes even more important. How does the payment facilitator determine that the person submitting a request through an API is indeed who they say they are?
Because a payment facilitator’s job is to minimize risk, robust authentication policies are key, Gray says. He cites a trend toward multifactor authentication, which he recommends that all payment facilitators require of their submerchants.
“If I’m a submerchant, when I log in on my tablet, my credential is delivered through the API,” he said. “Based on what the API told it, the system at the other end thinks it knows who I am. When you use multifactor authentication, it has to make sure. It will text me a code, so it will authenticate me before letting me in.”
While these types of systems may have been cumbersome in the past, they have become easier to use, and their effectiveness more than compensates for any inconvenience, Gray said.
Am I Allowed to Perform This Action?
Beyond requiring authentication of an individual’s identity, a strong security policy will outline specific roles and responsibilities, Gray said. Payment facilitators should carefully define what individuals who have access to the system are allowed to see and do, within both their own organization and the submerchants’ businesses.
For example, one submerchant may be allowed to accept a card, but may not be able to process credits. Or an administrator may be able to process credits or see certain reports, but may not be able to run a sale.
“Role identification requires that the merchant be very intelligent about how they register their users. It’s not just, ‘Can this person log in?’ It’s also, ‘Does this person have the rights to do what they’re trying to do?’ And today, I would call that a gap,” Gray said.