Payment services

In my line of job it is always challenging to understand and separate the business requirements from the actual technical implementation, and a added challenge is the language. I am not just talking about English <-> Spanish, I am a fluent Spanish speaker but the Spanish that some latin american countries speak is just plain different. I am talking about the language barriers between IT and business users, even between IT fellow coworkers..

A small example: I called Strawberries, Fresas in Chile they are called Frutilla.

Anyhow....

This customer is looking to integrate with 3 different payment system. This is when I learn about a new term "Transaction Completa" or "Complete transaction". It took a couple of back and forth conversation for us to be on the same page as we didn't have a "Client term dictionary" to IT eCom terms.

Let's look at the payment system that I have experienced.

1) In house direct Payment System: ... where the eComm system directly talks to a interface. Such interface can be a hardware that is provided by a 3rd party company or to a home-grown system that handles the direct communication to a mayor payment system (bank, transbank, interact, paymentech, chase 3dsecure...)

In this type of  integration there is a transaction_ID stored somewhere in that should be encrypted either the eComm persistance layer or the interface layer, to associate the order to a payment transaction.

2) Middle Man: ... where the eComm does not capture the CC information but rather eComm transfer the control to a contracted payment system and what eComm gets in return is a authToken that refers to the transaction. This authToken should be encryted in the system. This type of integration is also known as punchout, in the sense that we send the control to a another system.

The eComm never handles information related to the CC and thus responsibility to keep that information save is passed on to the 3rd party system. This is the most common and preferred approach.

There is a large market of providers out there: PayPal, WebPay, Transbank, Chase

3) Direct Gateway: ... where the eComm talk directly to the bank entity. In the older days before Punchout existed, this used to be a direct type of connection code directly on the eCommerce platform and would directly talk to each bank/payment system. Because each bank/payment system had their own specs and apis, this would become too complicate to code, support and mantain, thus almost always this would end up on a in-house payment system and this approach would be abandoned.

Now a days each bank have grown to understand the customer and they now provide their own propitiatory punchout payment interface. In some cases even providing eWallets where you can store your own credit card. Some sample of this system are Visa Checkout, MasterPass