Written by on 23 September 2015

Improving the credit card payment flow

We’re always looking for ways to increase our conversion. Although we’ve made quite some improvements over the years, one thing always stood out like a sore thumb. Take a look at our checkout process when using a credit card…

You can see that the flow is suboptimal due to the extra payment step, which isn’t that pretty to start with. To improve usability (and conversion) we wanted to integrate the form within our checkout pages. However, doing this comes with security risks and constraints. We always aim for the right balance between usability and security. This wasn’t possible with our current payment service provider (PSP), so we needed to look elsewhere.

We found a new PSP which suited our needs, but implementing a new PSP is harder than you’d think. There are a few things that you need to keep in mind when changing your PSP:

  • Which departments and business processes are going to be influenced by this and how will you involve them
  • Is the security still up to standards
  • What are the risks during the implementation, map these and make a backup plan
  • How are we going to add value to the company and the customer as fast as possible.

I’ll elaborate on the latter. Our goal was to have customers pay with the new PSP as fast as possible. So we could test the whole process from start to finish and see if any problems arose. Just a basic, secure form that was available for 1% of the customers would be enough.

This didn’t give any real problems in the first week. It also gave an indication that the conversion was steady. We could easily scale up to 10% and a few weeks later to 100%.  With of course a few new features. This is the stage we’re at now, the form is looking better than ever and the conversion is still stable.

But we’re still devoted to improve the flow of paying with credit cards. We want to offer our customers the possibility of saving their credit card (and paying with that saved credit card of course). And we want to move the form to the payment method selection step, which will probably look something like this:

So when implementing a new PSP, keep in mind who you are going to impact with the change. And how you are going to involve them. Also try to test the complete process as fast as possible, so that you can find the bugs and quirks. And gradually improve on this first release.

REPLIES (7)What you say.

  1. 5 years


    As an UX designer i’m wondering why there is no help for the user filling in the fields. The old design had help with the verification code, but is now removed in the new design. Is that decision backed up with statistics? And if so, could you share these statistics?

    Let me know.

    • 5 years

      Hi Ruben,

      Thanks for your comment. You are correct, we had some explanation for this. Unfortunately we couldn’t add it to the current form yet. We still plan on adding this though. It would definitively improve the form.

  2. 5 years

    Hi Vincent,

    In reply to your message:

    capturing the money from the credit card only after the payment is accepted from your systems would be a huge improvement from the customer point of view, as this is the behaviour he would expect: something went wrong, no money is withdrawn.

    About the use of Mastercard Secure and Verified by Visa, It is petty similar to the way iDeal works, where you are rerouted to your banks iDeal screen. Although there are some flaws comparing 3D-Secure to iDeal (it is pretty hard for a customer to know for sure that the 3D-secure page is a legitimate one) I am used to use 3D-secure on many sites, so to me it is not annoying, it feels more secure in a way.

    The problems I face with creditcard card payment (my girlfriends credit card actually) is that the creditcard somehow got marked has possibly “unsafe” by your systems. So my girlfriend got an email saying the payment was not accepted, while the next day the amount was withdrawn from her Visa card. Although the credit card is not unsafe and ICS cards confirms there is nothing wrong with it and that my girlfriend is the legitimate user, there is no way she can pay now with credit card at any coolblue website. And that is kind of a problem since she pays extra for the credit card to have more insurance on bought items.

    We have tried to get an answer about why the payment is rejected, but no answers are giving since it is policy of coolblue not to tell why a payment is rejected when paying with creditcard. Hence, my girlfriend can not pay with a perfectly safe credit card at coolblue websites. Since she wants to make use of her creditcard insurance she finally gave up and went to another shop, where she paid with creditcard and 3D-Secure without any issues.

    I still want to stay a customer of coolblue, but if I get the same problems when I try to pay with credit card, then well, I guess you see my point now.

    Hopefully you and your team will be able to solve these “false alerts” as I call them.

    If you need any more information, I will gladly provide you with anything you need to try and fix this. Just let me know :-).



  3. 5 years

    Hi Vincent,

    I stumbled across your posting about creditcard payments and the changes you had to make. Seems like a lot of challenge and I like that you make the step to make it part of your proces and layout.

    However, since I am involved in some problems with creditcard payments on the coolblue website, I would urge you to always choose the path that is most secure to the user. Apparently your proces makes use of some validation of the payment that has flaws and gives false alerts, and this false alerts do not stop the proces to continue and even goed ahead and withdraws the money from the customers credit card.

    As you can imagine, if a customer gets an email saying that the verification proces did not succeed but the amount is still withdrawn from the credit card account, there is no fancy website layout that will make up for the problems and discomfort that this generates from a customer.

    So, as a fellow developer I urge you to give functionality and security a higher priority than “good looks”. I can assure you that customers are happier with 95% working functionality than 75% fancy looking working functionality :-).

    Get the 3D-secure module and you will get more revenue and less headaches…

    well, thats about it, my 2 cents 🙂



    • 5 years

      Hi David,

      Thanks for the feedback. I share your opinion that security is important, I’m not confident that adding the 3D-secure check would be the best option. This would probably decrease the conversion because of the extra step in the checkout and the use of card readers. But a splittest could prove me wrong.

      Another solution to the problem that you describe would be to only capture the money from the card after the payment is accepted by our financial employees. This way the payment flow is still easy for the user and his money won’t be withdrawn yet. What kind of problems and false alerts did you run into on our website? Maybe we could take a look into it.


  4. 5 years

    Wat ik me afvraag, vooral omdat ik zelf werkzaam ben als dev van een PSP platform, in hoeverre is bij jullie de compliance aangaande PCI-DSS bekend? Want wanneer eenmaal de creditcard gegevens opgeslagen zijn hoef ik bij het afrekenen helemaal niets in te vullen, zowel geen CVC als expiration date. En hoewel dat erg praktisch is tijdens het afrekenen, is dat voor PCI echt een absolute no-go.

    • 5 years

      Hi Remco,

      Thanks for your comment. When we implemented the current flow we had an independent PCI-Qualified Security Assessor check our payment flow to see in which PCI scale we would end up. With the current solution we are PCI compliant.

      We don’t save any credit card data or the CVC code ourselves (it’s saved at the PSP). When a credit card is being saved, we ask for the CVC code. After that we think it isn’t necessary. Because the user has saved his credit card in his account and needs to be logged in to use it.


COMMENTGive your two cents.