# Friday, 25 April 2008

img_ecommerce With an e-commerce solution online payment naturally follows. Recently I've been involved in a couple of e-comm projects which needed integration with a payment provider.

In the good old days integration was a no-brainer you'd simply go with the API, HTTP-RPC or web services, for the nicest solution design-wise and development-wise as well.

Last year though VISA/MasterCard introduced the PCI compliance requirement for businesses handled credit card information. A move which in theory was good in that it limits the number of businesses which handle the information and by extension limits the chance for leaked information via security breach.

Now I write in theory because what happened is the VISA/MasterCard went a bit too far in their requirements. Basically if a credit card number is ever entered on your server you need to be PCI compliant; while this make sense for a payment provider for a store it means that you can't use the APIs as you'd normally would instead you have to use a payment window provided by the service provider.

If you want to handle credit card information at all you have to submit your system for quarterly reviews by external security consultants and your system will have to comply to the same standards as the payment providers themselves adding a yearly running cost of $5,000 - $30,000. Did I mention that VISA/MasterCard is bumping up the requirements on a quarterly basis? All in all this adds up to the conclusion that not handling credit card information on your servers at all is becoming the default choice and by extension the payment window becomes the default choice.

The payment window adds another layer of complexity to your solution in that you have to redirect your customer completely over to the payment provider site to process the credit card after which point the customer returns to your site to view a confirmation if everything went well. My main complaint about the payment window is the lack of contiguity for the customer. A great many sites here in Denmark use the payment windows with more or less success in that department.

Payment-Windows-Redirection-Flow

With the payment window being the default choice for now it's important that Danish online e-tailers figure out how to integrate the window in the most user friendly manner. Not doing so signals lack of professionalism in the best case and in the worst case they could loose customers because they are confused by a completely different look and feel in the most critical part of the checkout flow: Payment.

A company which does this extremely well is Trollbeads.com. Their integration with the payment window is seamless, in fact when I shopped there a couple of weeks ago I didn't even notice that I was redirected to their payment provider for processing my payment information. I should notice I do this for living :)

Take a look at the following screenshots to see what I mean:

Trollbeads-basket

(Basket)

Trollbeads-checkout-DIBS

(Checkout)

That's how it should be done and I didn't even do it myself :)

Friday, 25 April 2008 15:52:24 (Romance Daylight Time, UTC+02:00)
Thats the way its done. I have done this for a very long time using quickpay's feature called CCI page which fetched a HTML page from your server and displays it at theirs. It takes som handling of links, images and other ressources. But its very smooth and furthermore you aren't required to have certificates on your own server (if you only have these because of the payment).
Comments are closed.