Transactions overview

Transactions are electronic messages that carry information used for payment processing. They originate when cardholders attempt a purchase, either at a physical point of sale or online, and flow across card networks as requests.

When a cardholder uses their card, the transaction needs to be authorized before the funds are actually approved for settlement. The authentication process is controlled by Apto and involves several layers of scrutiny, including fraud detection, balance checking, card capabilities, and user preferences - for example, your cardholders might be interested in deactivating international transactions.

Our Core API and SDKs provide access to all the transactions conducted by your cardholders so you can offer that information to your cardholders. Available information includes the different amounts involved (local, international, etc.), the transaction status (accepted, rejected, hold), the date & time, merchant description, merchant category code (MCC), and more.

Payments

Payment sounds like a simple concept. You have something I want to buy. I swipe a payment card, which transfers money to you. You give me the item. But you might be surprised at how complex a payment card transaction really is.

For starters, every payment card transaction needs a cardholder, a merchant, and a card network.

Payments also involve two banks: The issuing bank provides a card to the cardholder. The acquiring bank enables the merchant to accept customers’ payment cards.

Card networks, such as Visa and Mastercard, communicate between the issuing bank and the acquiring bank. These networks send transaction messages that tell the banks how to credit or debit the bank accounts of cardholders and merchants.

To illustrate how these entities interact, consider a typical transaction flow for a purchase made at a physical point of sale:

1. Before the transaction, the issuing bank issued a payment card to the cardholder.
2. Also before the transaction, the acquiring bank supplied the merchant with a point-of-sale (POS) terminal, potentially through a payment processor or facilitator, such as Square.
3. Now, the cardholder uses the card to make a transaction, causing the merchant’s POS terminal to read the card details and pass the transaction data to the acquiring bank.
4. The acquiring bank routes the transaction to the correct payment card network, who routes the transaction to the issuing bank.
5. The issuing bank authorizes or declines the transaction.
6. If the transaction is authorized, the issuing bank debits the cardholder’s account.
   • The issuing bank usually places a hold on the cardholder’s account before a final amount is confirmed and debited.
7. Authorization message flows in reverse back through the chain of entities to the terminal where the consumer is informed that the transaction was successful.

Transaction flow diagram

So far, we’ve focused on getting permission to make a payment. To understand how funds move around, we need a few more concepts.

Authorization and clearing

Step six above mentions a hold. This reserves some of the money so that it can’t be claimed by anyone else. In most payment card transactions, a temporary hold is placed on a portion of the funds in the cardholder’s account. The hold happens before the transaction amount is finalized and funds are moved into a settlement account—more on settlement in a moment.

Holds are used in two steps: authorization and clearing.

Authorization is the process of confirming that a card is valid, business rules are met, and sufficient funds exist to cover the transaction, and then placing a temporary hold on those funds. If a cardholder loses a card and chooses to block that card’s transactions, authorization is the step where the transaction will fail.

Clearing is the process of finalizing the hold placed on the cardholder’s funds, debiting those funds from the cardholder's account, and posting the transaction. It is the step that happens after the cardholder explicitly confirms the transaction.

Settlement

As transactions clear throughout the day, funds accrue (or build up) in the settlement accounts of the acquiring banks and issuing banks on either side of the card networks.

At the end of each day, the card networks sum the debits and credits to calculate a single net settlement amount. This amount is transferred between the banks to cover the transactions for that day. Because the banks are “settling accounts”, this process is called settlement. During settlement, the banks also move the appropriate funds into the accounts of their merchants and cardholders.

In the most common scenario, money moves from cardholder to merchant like this: funds from the cardholder’s account flow into the issuing bank’s settlement account, then into the acquiring bank’s settlement account, and then into the merchant’s bank account. The final step completes the purchase.

Merchants can also owe money to cardholders, such as from refunds due to returned products. In these cases, money moves from merchant to cardholder like this: funds from the merchant’s account flow into the acquiring bank’s settlement account, then into the issuing bank’s settlement account, and then into the cardholder’s bank account. The final step completes the refund.

Generic funds flow

To illustrate authorization, clearing, and settlement, let’s look at a restaurant dining scenario. In this example, the restaurant places a hold on the customer’s account to cover the cost of the meal before confirming the final amount for settlement after the tip is known.

These are the payment steps:

1. At the end of the meal, the restaurant presents a bill to the cardholder (that is, the guest).
2. The cardholder gives a payment card to the restaurant.
3. The restaurant swipes the cardholder’s card to authorize the transaction.
4. The POS terminal reads the card details and passes transaction data to the acquiring bank.
5. The acquiring bank routes the transaction to the correct payment card network, who then routes the transaction to the issuing bank.
6. The issuing bank uses predetermined rules to authorize or decline the transaction.
7. If the transaction is authorized, the issuing bank places a hold on the cardholder’s account for the requested amount.
8. Authorization messages flow back through the chain of entities to the terminal, where the restaurant is informed that the transaction was authorized.
9. The restaurant prints a receipt based on that authorization and presents it to the cardholder for a signature.
10. The cardholder enters a tip and, in doing so, updates the transaction amount.
11. The cardholder signs the receipt to formally authorize the transaction, and returns the receipt to the merchant.
12. With the same POS terminal, the merchant creates a second transaction. This transaction updates the initial authorization on the cardholder’s account to reflect the tip and seeks to capture those funds.
13. The second transaction is routed from the POS to the acquiring bank, on to the card network, and then on to the issuing bank, which captures the amount for settlement.
14. The issuing bank updates the amount, debits the funds from the cardholder’s account, and moves those funds to the issuing bank’s settlement account.
15. The card network pulls the balance of funds from the issuing bank’s settlement account and transfers them to the acquiring bank’s settlement account.
16. The acquiring bank transfers funds from their settlement account to the merchant’s bank account, where the restaurant is ultimately credited for the price of the meal.

Although a transaction such as this is created right away, the transaction may be settled at a later date (typically within 3 days). When the transaction settles, you will see it in the settlement report that Apto sends the following day.

Apto’s role

You now know that every payment card transaction involves a cardholder, a merchant, two banks, and a card network. Where does Apto fit into the mix?

Card networks only allow federally-regulated banks to issue payment cards. Apto has partnered with an issuing bank to complete card issuance on their behalf. In this capacity, we act as ‘Processor’, with our partner bank remaining the federally-regulated banking entity.

In short, we make the issuing bank easier to work with by offering innovative card programs and providing a technology layer that makes integrating with the bank’s capabilities straightforward.

Here’s how this relationship works when a cardholder makes a debit card purchase at a physical POS:

1. The acquiring bank routes the transaction to the correct payment card network, and the network routes the transaction to Apto.
2. We authorize or decline the transaction based on the rules prescribed in your card program. For example, we check the balance available in a cardholder’s account.
3. If the transaction is approved, we route the transaction to the issuing bank, who ultimately debits the cardholder’s account to complete the purchase.

A similar role is played on the other side of the card networks by payment facilitators. These entities partner with acquiring banks and interface with merchants to help them accept payment card transactions.

Authorization

Every “card swipe” or online purchase made by a cardholder corresponds to one transaction in our system and in the merchant’s system. Each of these transactions can be updated multiple times by the merchant before it’s finally completed.

Transactions can be loosely broken down into two processing types: those for which multiple authorizations are made before capture, and those for which authorization and capture occur in the same transaction message.

• Many Authorizations and Capture - When a card is first swiped, the merchant is requesting that a hold be placed on the cardholder’s account to reserve funds to cover the transaction when it ultimately settles. After an authorization is made, the merchant can attempt to update the total amount held on the transaction many times. However, when the merchant is finally ready to “settle up” with the cardholder, they will send one capture message, which completes the transaction. This capture message is typically for an amount lower than that initially held on the account, though it may also be higher. Whatever amount is ultimately captured will be transferred to Apto’s settlement account, where it will be collected by the card networks during their next settlement sweep.
• Single Authorization and Capture - When a card is first swiped, a single message indicates that the merchant is requesting that funds are captured from the user. In this scenario, no hold is ever placed on the cardholder’s account. This message affects settlement.

Note - Apto has the option to decline these authorization and authorization-and-capture requests as they are received.

Transactions also contain one of two states—Pending and Complete—that indicate whether a transaction is finalized for settlement.

• Pending transactions are still in the authorization phase, and are expected to be adjusted by the merchant.
• Complete transactions are considered to be finalized, with no further changes by the merchant before the next day’s settlement (where the funds are sent to the merchant).

Technically, a completed transaction can still be adjusted by the merchant, although these cases are rare, and most networks are deprecating this functionality. In certain cases, adjustments to completed transactions can also be caused by upstream timeouts.

Transactions also contain a type, such as purchase, withdrawal, or return. Apto uses the type to determine whether the transaction credits or debits funds.

Fraud detection

Apto uses a built-in fraud detection engine and fraud case management tools to provide adequate controls over potential fraud with the flexibility to apply different strategies in real time. There are different categories and checks available to restrict authorizations on a per-program basis, per-cardholder basis, as well as at a card level. These pre-authorization rules cover the entire card life including: Know Your Customer (KYC), AML, suspicious patterns, and non-financial fraud patterns.

The Apto team works with fraud analysts to apply the best possible fraud prevention settings, ensuring maximum protection with the least customer impact.