In this article I introduce a subject that we don't usually pay much attention to on a daily basis: where our money goes. This process usually happens in a matter of seconds and, from the user's point of view, we only come across the result that is usually “transaction approved” or “transaction denied”, without knowing much about the different technical and business layers behind it. I hope to help you understand a little more about this super dynamic world that grows more and more over the years.
First of all, what is payment?
According to the Brazilian Dictionary of the Portuguese Language (Michaelis), among the definitions of the word “payment”, there is “Act or effect of paying(-se); pay, pay.” and, in the context of e-commerce, the act of paying is directly related to the way in which a buyer rewards a seller for a certain product or service provided via a virtual store, whether it is available at a virtual address of a large retail chain or even via via social networks.
And what about those payment methods?
We will have a brief introduction to how e-commerces are integrated into the payment structure here in Brazil and how an order with a credit card works at one of the restaurants registered here on iFood, but it is important to highlight some names that you have probably heard of such as: pix, bills, vouchers and transfer between accounts. These are the payment methods that we use so much on a daily basis, each with its own particularities.
Where to start?
To make these and other payment options available, entrepreneurs need to understand the limitations of an online store, which I chose to separate between resource limitation and platform limitation.
A resource limitation it is related to the size of the company behind the virtual store, what it sells, how much it sells and whether or not it is able to develop and maintain sufficient technology to connect to payment institutions (IPs), gateways and other payment service providers.
Furthermore, it is important that the virtual store follows the concepts of information security and protection of stored and transmitted data, preferably those established in ISO 27001, ISO 20000 and also in General Personal Data Protection Law (LGPD), ensuring that the services it integrates with also meet the same criteria so that the payment process is secure from end to end.
Most of the time, large companies have more specific and complex flows that are better served through these individual integrations with third parties, even participating in the improvement of services or customizing them to meet the interests of your customers. business, in a process called “self-development”. The conditions mentioned above determine the choice of this model or an e-commerce platform.
Already the platform limitation concerns the method by which the company decided to establish its online store. It is important to note that a store created via a social network will be limited to accepting the payment methodsWhat it integrates, this is repeated for the dozens of payment platforms that seek to provide more and more options to entrepreneurs to capture them, increasing their market share.
These platforms are mostly used by small and medium-sized companies, which do not have a structured development team and/or do not intend to invest in technology at first. This process is made easier when they opt for a ready-made solution that can include services, in addition to providing payment methods, such as solutions for stock control, delivery, relationships with customers and suppliers, etc. In short, e-commerce platforms have ready-made store solutions, which are already connected with all services (gateways, anti-fraud services, delivery systems, etc.) and require as little configuration as possible regarding payment methods.
This choice can also happen given the business segment in which it operates and its need to offer different payment methods in an easy way. And that's where iFood appears as a platform that brings together several payment methods, offering this possibility to restaurants, markets, pharmacies, among other establishments.
I cannot fail to mention that the conditions shown do not establish a rule and it is possible for a large company to use an e-commerce platform, as long as the solutions meet their flows and require less effort. Just as it is possible for a small company to hire a developer and begin its own development process.
Now that we understand the limitations, how does this framework work?
To fully understand all the parties that connect with the objective of making the payment, we first need to understand how gateways, acquirers/acquirers, brands and banks/issuers work. There are also sub-acquirers/sub-accreditors, these connect to various e-commerce platforms or directly to virtual stores and, generally, offer all the functionalities of acquirers, but with some facilities for small businesses such as transaction fraud analysis, dashboard for transaction management, among others.
After the most basic concepts, let's cover payments in more detail. It is important to note that each payment method has a information flow and financial flow.
At the information flow we have the data transacted between all connected parties. From the moment the order is finalized (checkout) in the online store, where the request for payment creation will be created depending on the method(s) used, until the return of payment approval information. Each medium has its specificity and understanding the details of each one helps us interpret how the “machine” works behind the scenes. This stage involves requests for APIs, webhooks, timeouts, etc. Most of the time the information follows a path similar to the one shown in the figure below (we don't need to focus too much on the names for now, we will cover each of them later):
Information flow from a “common” credit card transaction
At the financial flow money needs to be moved from one place to another, there is no “creation” of money. There is always a debit from the consumer so that there is a credit to the retailer when the payment is made and there is not much difference between the virtual world (online payment) and the physical world (payment using a card machine). This includes the fees discounted by the participants in the process, the anticipation of receivables and the effective settlement of the payment (when the retailer receives payment for the sale he made).
The financial flow of credit transactions involves the cardholder, retailer, acquirer, brand and the issuing bank. The holder pays the issuer who passes the money on to the acquirer, discounting its operation fee (called interchange) and also the fee that will be paid to the brand (called “brand fee”). The acquirer, in turn, discounts its administration fee (called Net MDR) which totals the total MDR (Merchant Discount Rate) agreed with the retailer, making the amounts available within the agreed period (usually counting the date of purchase + 30 days, what we call D+30). Even if the holder pays the invoice the day after the purchase, the amount will only be paid to the retailer within the period already agreed between the retailer and the purchaser. Important: Bacen has rules for transferring amounts and we here at iFood work within the legislation with different types of contracts with our partners that are not so important when talking about payment methods, so I just exemplify a modus operandi used so much by e-commerces and physical stores and not necessarily how it works here at home.
Now that we understand how the flows differ and what an online payment is, let's address each of the parties involved in more detail.
Gateways
Gateways solve a problem for companies because they provide several immediate integration options with services such as anti-fraud, acquirers and even some e-commerce platforms. They often provide features such as subscriptions, card data storage, multimedia, multibuyer and the like. Although they process all transactional information, are not part of the financial flow of transactions, i.e, they only transport the data they receive from one end to the other, hence the name gateway.
In the case of anti-fraud and accreditors, for example, e-commerces benefit from established contractual conditions and also reduce the chances of transactional problems due to a failure in one of the services used, being able to keep another connected at all times as a contingency. Furthermore, for acquirers, fees may vary for each payment method (cash credit, installment credit, etc.), allowing the virtual store connected to the gateway to determine which acquirer will handle each payment method and its particularities.
To make the flow clearer, let’s imagine that we have two accreditors: “blue” and “green”. The “blue” acquirer offers rates for cash credit transactions that are cheaper than what the “green” acquirer offers in this same modality. On the other hand, the “green” acquirer offers more attractive installment credit rates. After defining the settings in the gateway to determine which acquirer will handle each type of transaction (in cash or in installments), transactions sent by the virtual store will always have the best possible rates, using the “blue” acquirer in the cash credit modality and the acquirer “green” for installment credit.
Here at iFood we are also connected to services through gateways to offer the best conditions to our partners, regarding the use of the most diverse acquirers and payment methods with a presence in the market. This type of solution also guarantees the quality of our services: even if a gateway goes down, we will never be without receiving all types of payments, because we have other options in other gateways that are available to our customers.
The gateways we connect to have a certificate PCI-DSS (Payment Card Industry — Data Security Standard), a very demanding security standard regarding card storage and handling of transactional information. PCI ensures that transactional data is not exposed and subject to fraud, pretty cool right?! If you are interested in learning more about how your data is protected within our services, follow our privacy statement.
Accreditors/Acquirers
They are defined by the central bank as institutions that do not manage payment accounts, but enable commercial establishments to accept payment instruments. In other words, they are institutions that sign a contract with the virtual store to accept cards, connecting the retailer to the brand and taking care of their financial flow. It is responsible for meeting receivables settlement deadlines and for the arrangements that guarantee the making and acceptance of payments, in addition to adopting security rules that protect both consumers and store owners from risks, fraud, card cloning, etc. As explained in the topic about gateways, it is not common for retailers to connect directly to an acquirer, taking into account that they need to develop an integration for each of them — which can be quite complicated when we look at the technical aspect of this type of operation.
Flags
They are related to card payments and determine the “rules of the game”, ensuring that information flows from the acquirer to the bank and vice versa. In addition, they usually carry out assessments linked to protocols that guarantee the security of transactions. The brand receives part of the value of each transaction, in a payment transaction carried out by the acquirer, after discounting the respective fees.
For the iFood benefits card, for example, we are connected with the Elo brand, which allows the cardholder to be able to use the card in all establishments accredited to accept this brand and that are within the conditions set out for restaurant/market characteristics .
Banks/Issuers
These are financial/payment institutions that issue plastic (cards) to cardholders, determining credit limits and conditions, within what is foreseen in their integration with the brands. Just like brands, issuers also usually receive a fee for each transaction carried out, which is paid by the acquirer after the respective discounts.
Anti-fraud
The vast majority of them work as scoring analysis services, taking into account the consumption history based on the data sent by a specific buyer. They can be configured in two flows, called “normal” and “inverted”.
In the normal flow, transactions are first forwarded to the gateway so that they are authorized (pre-captured) at the acquirer and, only then, forwarded to the anti-fraud service. With anti-fraud approval, effective capture is carried out.
In the reversed flow, the first step is to forward the transaction for analysis by the anti-fraud service, before even forwarding it to the gateway. This solution is most used when we need speed in the process.
How do all parties connect here at iFood?
Using an example of a transaction carried out with a credit card in a restaurant, taking into account only the flow of information, we have the following scenario: A buyer using any device (android, ios, desktop) completes an order (checkout) in a store registered here on iFood by selecting credit card as payment method.
We have a payment control service that determines the flow of each type of transaction and, after confirming that this is a credit transaction, checks whether this card is already registered with a service protected by the PCI-DSS certificate, then the data are forwarded to our anti-fraud department. If approved at this stage, it is sent to the gateway in operation for this type of transaction, connected to an acquirer, which receives the data from that purchase and talks to the brand. This performs its validations and contacts the bank to understand whether there is credit or not.
The information returned to the brand is passed on to the acquirer, who will say whether the purchase was authorized or not by the gateway. The authorization information will arrive through the gateway to our payment control service, which will return the authorization information or the non-authorization message to the device, at which point the attempt to transact with credit is terminated — in a matter of seconds .
This is a summary of what the “ideal order” would be, where the flow was followed completely from checkout to the bank. It is also possible for the transactional denial to happen before it even arrives at the brand or the bank, whether due to a security rule of the acquirer or the brand itself, for example.
What are the details of the actions taken for a credit transaction?
Within the flow of transactions made with a credit card in an e-commerce, several actions are available: authorization, capture (total, minor or major), authorization and capture (at the same time), cancellation, refund and chargeback. Each of these determines a status for the order and has a different functionality. These actions can also be called “transactions”, in a single request we will have an authorization transaction and a capture transaction, for example. These terms are confusing because we usually talk about “a credit transaction”, but within this “credit transaction” there are several other transactions. There is no convention, but it is important to highlight that each action mentioned is reflected in a transaction, which would be a new communication with all parties involved in the process of that specific action.
Still regarding authorization, the person who defines the rules to deal with the period in which a transaction can remain authorized without receiving a capture (or a cancellation) is the acquirer. A captured order is subject to receiving a request for total/partial cancellation or total/partial refund (depending on the capture date and the acquirer's rules), if it is necessary to undo it, returning the captured value to the buyer. The maximum period for carrying out a cancellation/reversal is defined by the brands.
There is also a deadline for the consumer to dispute the purchase, which characterizes a chargeback and is also defined by the acquirer — in accordance with the deadlines of the brand and the bank. Chargeback is a harmful process for the online store that can generate fines if it happens excessively, but it is essential for the consumer who felt aggrieved and would like to get their money back, initiating this action with the card issuer who informs the acquirer. The gateway has no view of whether there was a chargeback or not in the transaction, because this flow falls within the financial scope (return of values) and is outside its responsibility.
Indicators
One of the most important indicators we observe when we talk about e-commerce transactions is authorization conversion, which can be understood as the number of authorized transactions over the total number of transactions. If we have, for example, 1000 authorized transactions and 1600 is my sum of authorized + denied, my conversion will be 1000/1600, that is, approximately 62.5%.
The main causes of low card conversion are lack of balance and improper data entry (invalid card number). To understand whether the conversion is good or bad, we depend a lot on the details linked to the business model in which the store operates. These 62.5% may reflect a poor result for a retailer, but an excellent result for a store that works on a recurring basis. There are many factors to be taken into consideration here, but in short, this is a super important factor and must be observed closely because, among other results, it directly affects the company's revenue.
What if something goes wrong?
As the process involves several players, we may face situations such as timeouts, where the connection between them closes without there being a response to whoever made the request. Imagine that the gateway calls the acquirer but does not get a response. It is possible that the problem occurred in the outward flow between the gateway and the acquirer, between the acquirer and the brand, between the brand and the bank or on the way back between the bank and the brand, between the brand and the acquirer or even between the acquirer and the gateway. Therefore, there are probe mechanisms that are triggered between participants in this flow in case of loss of information, which can cause payment processing to take longer than usual.
There are also cases where more than one transaction is created when completing the order, generally due to redundancy routines and, consequently, all parties receive two requests for the same order, generating duplication. In this scenario, some protections are activated both on the platform side and on the gateway or acquirer that identify requests made with the same data in a short period of time and automatically reverse or ignore one of the requests. When this process does not occur automatically, we have a financial loss for the buyer and this type of situation must be immediately remedied, hence the importance of monitoring that identifies duplications and acts to resolve them.
Just that?
No! As I mentioned, these are the most basic concepts of a credit card transaction. There are also N other configurations for the flow of information that may include the use of two cards (multibuyers), two different payment methods such as card + bank slip (multimedia), the use of anti-fraud in the normal flow and so on...
This “skeleton” presented helps us to understand in a simpler way how the parties interact with each other, adding examples and showing expected behaviors during some main parts of the credit card payment transaction here. I hope the text has helped to demystify a part of the world of payment methods in e-commerce and here at iFood. See you next time! =)
