Introduction

Our service serves as an indispensable bridge between developers and the complex world of payment card transactions. Designed for both security and ease of use, our API empowers developers to seamlessly integrate real-time card transaction data into mobile and web applications.

By leveraging our unified API, you gain access to high-quality, in-depth, and consistently reliable data directly from major card networks. This enables you to create engaging, real-time experiences for cardholders—right at the crucial moment following completion of a transaction, whether they're standing at a terminal or finalizing their online checkout.

Once a card is successfully enrolled transaction data flow into your server in real-time. This not only adds another layer of interactivity to your application but also provides invaluable insights that can drive data-driven experiences for your customers.

Card Transactions in the Payment Ecosystem

When you use a card to buy something, a lot happens behind the scenes.

This section will provide you with a brief background to this process to enable you to better engage with the rest of our product documentation.

The Players

Cardholders: People who use their physical or virtual cards to pay for goods and services.

Acceptors: Card acceptors are the merchants that accept cards as a form of payments for goods and services.

Issuers: Issuing banks are the financial institutions that provide credit and debit cards to cardholders and manage the accounts that these are linked to.

Acquirers: Acquiring banks are the financial institutions that enable merchants to accept payment cards in their stores.

Processors: A payment processor acts on behalf of the financial institutions to manage the card transaction process.

Payment Card Networks: The payment card networks provide and maintain the infrastructure on which card payments run.

The Steps of a Card Transaction

Transactions within the ecosystem comprise of the following processes:

Authorization: This is like asking, "Is this card able to make this transaction?" It checks if the card is valid, if the rules associated with it are followed, and if there's enough money. If everything looks good, the money is set aside, but not yet taken.

Clearing: Here, the 'set aside' money is prepared to be moved. This happens after the shop says, "Yes, we made the sale".

Settlement: This is where the money actually moves from the buyer's bank to the shop's bank.
Another way of thinking of a card transaction (and the terminology we use in much of this documentation) is that generally, card payments transaction messages can be categorised in four ways, represented in the table below:

	Non-Financial message (Authorization)	Financial message (Financial)
Request	Messages sent by the Merchant Acquirer to retrieve information from the issuer processor, generally requiring a response (e.g. Authorization Request)	Messages sent, generally by the Merchant Acquirer, to initiate money movement from, generally the issuer processor, usually requiring a response (e.g. Financial Authorization)
Advice	Informational messages that do not move money (Authorization Advices etc..)	Informational messages that move money (e.g. Clearing, Return)

To keep it simple: the main difference is whether money is being moved or not, and if the issuer needs to respond or not.

Specific message types are discussed in more detail as part of our Transaction Message documentation. Our Message Types are based on ISO 20022 nomenclature.

How Transactions Happen

Transactions generally are authorized, cleared, and settled in one of two ways. Which way is chosen depends on the card issuer, the type of card, and/or the region in which the transaction takes place.

Single-Message Transaction: Think of it as a one-step process. The shop sends one message with everything needed to finish the transaction, all at once.

Dual-Message Transaction: This is a two-step process. First, the shop asks for authorization from the card issuer via the merchant acquirer. Later, they send another message to clear and settle the transaction. Most card payments are done this way. But if you use your PIN (like when getting cash from an ATM), it's usually a single-message transaction in most of the world.

Other Types of Transactions

PIN Debit Transactions: This is when you use your PIN to buy something. In most of the world it's usually a one-step process. In Europe all card payments are processed as dual-message-system messages.

Reversals: This is when a shop or customer in a shop changes their mind about a sale. Maybe the authorization was okay, but they haven't finalized the sale yet. They can undo part or all of the transaction.

Refunds: This is when a cardholder asks a shop to give your money back after a sale has already been settled.

Chargebacks: This is when the cardholder says, "This transaction wasn't right," and disputes it via their issuer.
Usually, the whole process goes from Authorization > Clearing > Settlement without any deviations. But sometimes, it can get a bit more complex, depending on factors like the nature of the purchase, the merchant type, the location where the purchase happens, and more (learn more in Transaction - Example Transaction Flows). Most transaction lifecycles finish within a week.

Where does this service enter the Picture?

We connect directly to the payment card networks, receiving and passing notification of these network messages as they happen. Typically, other aggregation services work primarily with clearing messages, but our underlying network connection allow for the inclusion of real-time authorization messages, which enable next generation experiences with cardholders the moment they spend.