In our previous insight entitled “The difference between a merchant and third-party account”, we touched on the starting point for a merchant, exploring options for payment processing by looking at the two different kinds of merchant accounts that need to be considered. We move now to a new chapter in the payment story, which has to do with the payment page. This needs to be created in order for online Payments to be made.
As you may have guessed, there are various options and ways of presenting and Hosting the payment page, involving both the merchant and the payment processing provider (PSP) with different variations and levels of implication.
The simplest way of setting up a payment page is the basic “buy now button” whereby the customer presses the button in order to pay for his selected item and he is directed through a link straight to the processor’s payment page hosted on its server. The customer fills out his payment details there and the processor deals with the payment. Once the payment has gone through, a message is sent to the merchant who then notifies the customer that he has successfully made a purchase.
This option is simple and less costly than other integrations. It also precludes the merchant from having to be PCI certified because the end-user’s payment details are being processed on the processor’s server instead of the merchant’s to ensure total compliance with the PCI-DSS standards. (Greater detail about PCI DSS certification will be published in a future insight.)
The next option is much the same as the simple “buy now button” but with further integration, the payment page to which the end-user is directed is customizable in order to appear to belong to the merchant. The look and feel of the payment page can be adapted to reflect the merchant’s brand even though the page still belongs to and is hosted on the processor’s server. This slight advancement is in the merchant’s best interest because the paying customer is often comforted by his recognition of the merchant’s brand and may prevent him from abandoning the transaction owing to a fear of payment safety.
The integration of the hosted payment page is advanced slightly with the option of the I-Frame. Unlike the previous options, an I-Frame provides a kind of “illusion” for the customer. The payment page is still hosted on the processor’s server, with payment information remaining in the hands of the processor but, it is set up in such a way, that it appears to be hosted on the merchant’s site. The customer thus, is not redirected to another site when he clicks to make a purchase. Rather, he remains on the merchant’s website and although the URL in the address bar is the one of the merchant, the exact place where payment details are being entered calls for the hosted payment page of the processors and displays the relevant fields directly from the Processor’s server. When done properly, the I-Frame will not cause any scroll bar to appear and the page will then appear to be fully hosted on the merchant’s sever while in fact sensitive data will never transit through his server. This a very good compromise to fight the walkaway rate and conversion problem that may arise when redirecting your customers to a third party.
Like everything internet related, there is always the risk of fraudulent activity. In this case, hacking has been known to occur whereby a criminal will gain access and redirect shoppers to a fake page of his own that is a replica of the payment page and the customer will end the details that he is asked for. The data is the captured and send to the hacker in question. In an interesting document by VISA and the hosting of payment pages, suggestions are made about how to take precautions.
All three of the above mentioned payment page options, work according to a similar integration and in all cases, the payment page is hosted on the processor’s server. The alternative to the type of processing system is a direct payment option (server to serve r type of integration). This option can only be selected if the merchant is PCI certified and usually when a direct merchant account has been opened (Merchants who have third party accounts should not be able to choose this option)
With this server to server process, the payment page is fully hosted on the merchant’s site and the entire transaction takes place on the merchant’s website. When customers have chosen what they want to purchase, they check out and proceed with the payment process on the merchant server.
Once the payment form is received back on the merchant server, he then uses the API given by its processor to transmit the credit card details to the Processor’s gateway in a way that the gateway can understand (The API). The transaction is then processed as usual and an answer is returned to the merchant informing him that the transaction was either approved or declined.
Many merchants prefer this type of integration as it allows them to store the credit card details, at least temporarily in order to try a failover solution in case the transaction got declined or for rebilling purposes. One could agree with this reasoning, should it not involve the need for PCI certification.
Other solutions exist, especially for recurring billing, and we at Payment Magnates believe that the Tokenization (which will also be treated in a future insight) is probably the very best solution to legally constitute a database of your clients’ credit card details without any fear of being hacked and it can be implemented using a direct integration and a hosted page too.
But the direct integration is also helpful when it comes to the merchant’s bottom line. If, when the payment page is hosted on the processor’s site, the payment is rejected or fails to go through, the merchant will inform the customer though a “failed payment” notification. The customer will then have to try again by re-entering his credit card and other details. This is time consuming and annoying for the customer who may choose to abandon the payment. In the case of direct payment, the merchant (through the set-up of various technical systems or outsourced solution like NATS in the adult world) is able to reattempt the transaction or to submit the payment through alternative processing avenues, before notifying the customer (This all takes place within seconds).
As we saw, the direct integration option is not available to all merchants, but for those who want to host their own payment pages but are not willing to get PCI certified, there may the possibility of Transparent API. In this case, the payment page is hosted on the merchant’s sight but on the form that is sent to the end user’s browser, the submit button is configured to send the filled form leads to the gateway of the processor directly and not as it would normally back to the merchant’s server. In this way, customer credit card details do not remain or get stored on the merchant’s server but rather, are transported directly to the processor without touching the merchant side, like the hosted page.
This could be good option for a merchant however, it poses some risk for the customer: should the merchant decide to, he technically could fiddle with the button so that the client’s information is sent to both the processor and himself. This would be a serious safety and legal breach and therefore processors should not allow this technique unless the merchant is duly PCI certified.
