« The New School of Privacy | Main | FYI: Feeds, CMS »

More on Tokenization

In a previous post, "Does Tokenization Solve Anything?", I questioned what the value was if the cardholder data still passed through your site. I've had the opportunity this week to look at three of these solutions, and have been pleasantly surprised that I had somewhat underestimated the approach out there (though site literature doesn't necessarily get this point across well).

Either directly or indirectly, I've research the following companies:
- Enterprise Payment Exchange (http://www.epx.com/)
- Paymetric (http://www.paymetric.com/)
- Braintree Payment Solutions (http://www.braintreepaymentsolutions.com/)

Each of these solutions has a different spin on things. As such, let me provide some thoughts on each, and then wrap it up at the end with broader comments.

Enterprise Payment Exchange (http://www.epx.com/)

Enterprise Payment Exchange, or EPX, has what I consider to be a fairly basic tokenization solution. They generally rely on a gateway on the customer premises that generates their "BRIC" (token). Rather than taking credit cards directly through your web site, then, you instead redirect to a page hosted on the gateway that is made to look like your site. You then get a redirect back from their box with URL parameters that include the token so that you can complete the transaction accordingly. And the back-end, their gateway ties into their SaaS to securely store the cardholder data off-site. This raises questions for me in terms of the security of their gateway. However, it appears that this system has received PA-DSS certification (look under Electronic Payment Exchange for their BuyerWall 2.0), which should provide some degree of assurance.

Paymetric (http://www.paymetric.com/)

Paymetric appears to be relatively comparable to EPX, with a couple key distinctions. Where EPX uses a redirect, Paymetric instead provides Javascript code to embed into your site. I don't know, however, that this is good thing, as many end-users disable Javascript. As a back-up, they appear to also support a redirect to a landing page. Beyond that, the primary differentiator is that they are the only vendor that integrates fully with SAP Business One. Unfortunately, Biz1 is not apparently a very good billing platform/engine, especially for companies that have a recurring subscription model. Paymetric does not not provide the billing engine, but rather supplements it with their tokenization technology in order to reduce the scope for PCI compliance. As such, you need to bring to the table your own billing engine, and then they'll integrate with and enhance what you have.

Braintree Payment Solutions (http://www.braintreepaymentsolutions.com/)

Braintree has an interesting solution that is different from the other two researched this week. They will generally integrate with existing billing platforms, such that one merely needs to set them up as a processor and modify site code accordingly to add their API calls (rather than a POST to your own servers, you instead POST to theirs) and to receive the token back. The token appears to be a standard hash, nothing too exciting. They also support up to 20 custom fields, opening the door to some creative uses. Overall, the solutions appears to be more complete than either Paymetric or EPX, with some interesting value-added propositions. It definitely seems promising in terms of providing ample motivation for merchants to get cardholder data out of their environment altogether.


In the end, it turns out that the one key weak point identified previously is being addressed by these vendors. Nonetheless, it's not clear how much value straight tokenization solutions add. Yes, you get the cardholder data off of your systems, but with the caveat of making some interesting tradeoffs (having a gateway on-site, redirecting off your site, adding Javascript to your site, etc.). In at least 2 cases, it appears that you still need to maintain your own billing engine/platform, which means your costs will be generally higher. Some might argue that this isn't necessarily a bad thing. In the grand scheme of things, though, the ideal for smaller merchants (at least Level 3-4) seems to me to be getting the entire billing platform outsourced completely such that there is a much lower burden for support and maintenance, as well as dramatically lowering the compliance requirements. This is where a full-fledged SaaS model holds a lot of potential. It will be interesting to see what else may come in the future.


TrackBack URL for this entry:

Listed below are links to weblogs that reference More on Tokenization:

» Tokenization: Someone Else Gets It from The Falcon's View
Apparently I'm not in fact insane, but do in fact know a little something about things that don't make much sense. One of those things is the mythical tokenization that has been heralded in marketing hype as the next greatest... [Read More]

Comments (1)

With more VISA mandate deadlines looming and the ability for software companies and payment processors to work 'compliance' into their development life cycle, I think there will be a couple of more organizations offering components to remove the card holder data from the process. Organizations like the one you mention provide services that intervene, tokenize the payment data and then pass that along.

I noticed last week, CRE Loaded (disclosure: one of our partners) launched CREsecure http://www.cresecure.com/ which is a compliant open source payment page for ecommerce carts. Perhaps, you could review their setup as well.

Post a comment


This page contains a single entry from the blog posted on May 21, 2009 1:41 PM.

The previous post in this blog was The New School of Privacy.

The next post in this blog is FYI: Feeds, CMS.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.