Payments Methods Implementation

Working in e-commerce sooner or later any developer gets the task to implement a payment system on the web-store. Basically, there are not so many ways, but their features may seem confusing not only for customers, but even for developers.

So, to clear things up, first, let’s make a list of participants who are involved into the purchase process.

The participants

• Seller  – owner of a web-store
• Customer – user who visits the store
• Payment service provider (PSP) – the service that receives the information and processes payments

Payment steps

• Generate and render the payment form in the browser
• The customer enters credit card info and submits the form
• The data is received and forwarded to be processed

Finally, here come different ways to process the data.

Redirects

The first way is to forward customers to the payment processor website where the payment form is located. This method is quite often used in small shops. The advantage of this method is that you need to support less code and the whole responsibility for the payment security is taken by the payment processor.

1. The seller’s website shows a notification to the customer about the redirect,
2. the customer is forwarded to the checkout page on the payment processor website
3. PSP generates the form
4. The customer fills in the form
5. PSP receives the data and processes the payment

However, using a redirect there is a risk of a man-in-the-middle attack, when a hacker gets access to the shop and changes the redirect address to a third-party website. After that on his website the hacker can get the personal credit card data, and then can redirect the customer back to the payment processor website to complete the purchase. In most cases the customer becomes aware of such attacks only after he checks the account balance statements. In this situation it is not possible to blame the payment processor, since the attack was possible due to the security flaw in the web-store itself. Therefore, all the costs and return of funds will be incurred by the seller.

IFrame

Iframe is a method when the payment form located on payment processor website gets incorporated on the checkout page of the web-store. One of the advantages of this method is that the store owner can easily control the design of the checkout page (the frame outputs only stylized form). The same as with the redirect method, the payment form itself is located on the payment processor side.

1. The seller’s site creates a parent page.
2. The customer’s browser requests the frame for the payment form.
3. PSP generates and outputs the form.
4. The customer fills in the form and sends the data to the service.
5. PSP receives the data and processes the payment

On the left there is the parent page. It is a part of the web-store. In the middle there is the frame. The frame contains the payment form which is generated by the payment processor.  On the right is the page layout as it will be presented for the customer. From the point of view of the customer we see just a complete checkout page with the payment form.

However, the Iframe method can be affected by same type of attacks as the redirect method. So if a hacker gets access to the store he can change the frame address and steal the credit card data the same way.

Direct post

Direct post («browser post», «silent order post») differs from the above 2 methods. The payment form is located directly on the web-store, not on the payment processor website. This gives the seller more opportunities to control the payment process. But this also puts extra security demands on the web-store and all committed transactions.

Partner With Us Let's discuss how to grow your business. Get a Free Quote.

Talk to Andrey

1. The payment form is generated by the web-store itself.
2. The customer fills in the form and the data is transmitted to the payment processor.
3. The Service receives the information and processes the payment.

Due to the fact that PSP is being requested only at the time when the payment data is being sent to the payment processor, it is quite difficult to track any third-party interference activities. To pass PCI DSS certificate sellers who use this type of payment system have to not only fill in the questionnaire with 139 questions (AQ A-EP), but to pass a full security audit (internal and external scanning and penetration testing).

JavaScript method

The complete page is generated by the web-store. But the customer’s browser modifies the form by using a script, which is downloaded from the payment processor servers.

1. The web-store generates the payment form.
2. Customer’s browser requests for Javascript
3. PSP generates JavaScript
4. On the basis of the script browser generates the payment form.
5. The customer fills in the form and the data is transmitted to the payment processor.
6. The Service receives the information and processes the payment.

The same as with the direct post, the JavaScript method demands extra security measures on the side of the web-store owner.

API

API ( “merchant gateway”) is different from other methods in the way that it gives full control over the payment process to the seller. Transaction data is kept directly on the web-store, that allows you to implement a closer interaction between the seller and customer.

1. The web-store generates the payment form.
2. The customer fills in the form and the data is transmitted to the web-store.
3. The store sends the credit card data to the payment processor.
4. The payment service receives the information and processes the payment.

But as always, as soon as someone gets access to the store – all your customers’ data becomes compromized. And considering that using API makes the web-store keep all the customers data on its server, the damage can really be quite serious. Web-stores using this method have to pass the most severe tests for PCI DSS certification.