A small example: I called Strawberries, Fresas in Chile they are called Frutilla.
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.
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.
Visa Checkout, MasterPass