This technical article describes how merchants can optimize the customer experience of their shops by reducing the time spent waiting for payment gateways. While the optimizations in this article are partly tailored to PAY.ON’s payment gateway, the principle works with all gateways.
Web shops redirect the user to a payment gateway at the end of the checkout process. On the payment gateway, which is usually provided as part of merchant account services, the user enters confidential details such as credit card numbers. For users the process looks like this:
- In the web shop users view the shopping cart.
- The user clicks the button or link to check out.
- On the payment gateway’s website the user enters his payment details.
Technically, before the payment gateway page can be displayed the following steps need to be performed:
- The payment gateway IP address must be looked up in the DNS.
- To establish a secure connection the SSL certificate must be requested.
- To validate the certificate external services (such as OCSP or CRLs) might have to be queried. This could be incurred additional DNS and HTTP requests.
- After the connection is established the payment gateway page is requested by the browser used by the shopper.
Here is a diagram of how this process looks like when visiting https://www.paypal.com:
http://www.webpagetest.org/result/120829_MV_9JW/1/details/ (This diagram was created at http://www.webpagetest.org.)
In this diagram the following steps are performed by the browser:
- The DNS entry for www.paypal.com is looked up (the green block on line 3).
- A connection to www.paypal.com is established (the orange block on line 3).
- The SSL certificate for www.paypal.com is exchanged (the violet block on line 3).
- The DNS entry for evsecure-ocsp.verisign.com is looked up (the green block on line 1).
- A connection to evsecure-ocsp.verisign.com is established (the orange block on line 1).
- Two HTTP requests are made to evsecure-ocsp.verisign.com to validate the SSL certificate (the green blocks on line 1 and 2).
- The actual request for the page is made which receives a redirection (HTTP status code 301) as response (the green block on line 3).
- Another request to https://www.paypal.com/home is made (the green block on line 4).
In the diagram above, the “1” icon marks the point at which all technical requirements are fulfilled and the actual request can be made. In this example this happened after around 1.25 seconds. These 1.25 seconds can be removed by this optimization.
Optimizing the HTTPS Connection:
To reduce the time between the shop and the payment gateway the HTTPS connection (steps 1-4 in the list above) is pre-loaded when the user is still on the shop checkout page. This is done by embedding an image from the payment gateway domain on the shopping cart page and making it invisible to the user. Even though the image is invisible it causes the browser to start all of the steps above.
When the payment gateway page is requested all the preconditions are already established.
For the PAY.ONpayment gateway, the required HTML is simply:
<img src=”https://ctpe.net/frontend/images/spacer.gif” width=”1” height=”1” alt=”” style=”display:none”>
When this optimization is implemented for the majority of users the time spent waiting for the payment gateway is reduced. The actual savings will vary with:
- the geographical location of the users
- the speed of their Internet access
- the geographical location of the payment gateway
- how fast they click through from the shopping cart to the payment gateway
- several other factors such as the usage of Internet backbones
It is not possible to predict results, however, we estimate savings between 250-1000 ms. This might not sound like much but Internet users were expecting websites to load in 2 s in 2009 (down from 4 s in 2006) so every performance improvement helps visitors to complete their tasks.