A Transaction’s Journey through Brex

Brex is re-imagining B2B financial products, starting with a corporate card for technology companies. Here, we’ll provide a glimpse into the card processing infrastructure as well as the underlying financial technology that powers Brex cards.

Credit card processing 101

Credit card processing sounds simple at first, especially from a customer perspective. Under the hood, however, it is a fairly complex process that involves multiple entities.

At a high level, credit card transaction processing primarily consists of two steps: authorization and clearing. This can be thought of as a two-phase commit system, where authorization is the process of approving or declining a transaction, and clearing is the process of committing the final transaction result.

The first step, the authorization flow, is represented in the following diagram:

The most important entity is the card network, such as Mastercard and Visa, which facilitates communication between issuing banks (or issuers, which issue credit cards to cardholders) and acquiring banks (or acquirers, which are merchants’ banks) to process credit card transactions. The overall flow is explained below:

1. The cardholder pays the merchant with a credit card
2. The merchant sends the purchase information to the acquirer
3. The acquirer forwards the request to the network
4. The network requests payment authorization from the issuer
5. The issuer sends the authorization response back to the network
6. The network sends the authorization response to the acquirer
7. The acquirer forwards the response to the merchant
8. The purchase is complete if the authorization was approved by the issuer

The second step is the clearing flow, which is the process of confirming final transaction results. Unlike the authorization flow which takes place in real-time, the clearing flow is a batch process that takes place several times a day. Its process is represented in the following diagram:

1. The acquirers send the list of transactions, most of which are approved transactions from the authorization step, to the network for clearing
2. The network consolidates the list of transactions from acquirers and send them to the appropriate issuers

The goal of clearing is to determine the amount of money that needs to move between participating banks. The process of actual money movement is a separate process called settlement, but it is not covered in this post for simplicity.

Brex, as a card issuer, has built a system to handle authorization and clearing processes. The next section describes the system at a high level.

Brex card processing infrastructure

At a high level Brex’s card processing infrastructure looks as follows:

Brex supports two networks: Mastercard and Visa, depicted at the top half and bottom half of the diagram above, respectively. For Mastercard, we’ve built separate components that handle authorizations, which happen in real-time, and clearings, which is handled by batch processing. These components use TLS and SFTP with binary protocol (ISO 8583) as their communication protocols, respectively. The third parties that we rely on provide services such as connectivity and tokenization, which is a process of converting credit card numbers into tokens for data security purposes.

For Visa, the third party we’ve partnered with communicates both authorizations and clearings via HTTP requests, so we have a single component to process both types of messages.

Both Mastercard and Visa requests are forwarded to a network-agnostic component, through which further processing takes place. This allows us to build most of the business logic involved in the processing of authorizations and clearings in a network-independent manner.

Authorization processing

As mentioned above, authorization is the process in which transactions are either approved or declined. As an issuer, Brex is responsible for making such decisions for our cards.

In simple cases, a transaction is made up of just an authorization and a clearing. In practice, transactions can be more complex than this. For example, a transaction’s amount could be adjusted after it’s been authorized, the transaction could be cancelled, or additional authorizations could be added to the same transaction.

Merchants generally communicate with issuers using the following types of messages. These messages are sent by merchants and processed by issuers mostly in real-time.

• Authorization requests
• Advice notifications
• Reversal notifications

Advice and reversal notifications are types of messages distinct from authorizations which notify the issuer of new information regarding a transaction before it has cleared. For example, advice notifications indicate changes in authorized amounts; reversal notifications are used to reverse transactions that were previously authorized, or reduce their amount.

These messages, as well as clearings, contain metadata indicating which other messages they’re related to, allowing us to form a graph of related messages which all belong to the same transaction.

Regardless of their type, all messages that we receive from Mastercard are in ISO 8583 format. ISO 8583 is a specification of a binary format that’s used to represent financial transactions.

MC auth processor receives authorization requests, advice notifications, and reversal notifications in this format over a stateful TCP connection with the third party. It parses these messages and converts them into a domain model that’s agnostic to the network, the third party we use to connect to the network, or the particulars of how the third party communicates with us. This gives us a nice separation of concerns between the network and protocol-specific components like MC auth processor and Visa processor, and the agnostic ones like Transaction processor. For example, the third party we use for Visa cards parses ISO 8583 messages for us and communicates with us via HTTP requests and JSON, but this distinction is abstracted from Transaction processor. This makes it relatively easy to introduce new third parties to connect with credit card networks without changing too much of the agnostic logic related to the domain model and authorization rules.

Transaction processor then records these transactions in its agnostic data model and publishes an event which is consumed by downstream services. This enables Brex’s beloved credit card features, such as statements/billing, rewards, the web and mobile dashboards, receipt capture, expense integrations, and more. This communication is done asynchronously using Kafka to ensure that the downstream services don’t interfere with the availability of authorizations.

For authorization requests, Transaction processor also needs to decide whether to approve or decline the transaction. It does so based on a number of rules including the cardholder’s credit limit, fraud risk, spend controls, etc. MC auth processor will convert this decision into a new ISO 8583 message and send it back to the network, completing the authorization request.

Clearing processing

Now that your transaction has been approved and you have walked away with your goods and/or service, you can go to your credit card issuer’s dashboard and see a “pending” transaction. The transaction is pending in the sense that even though the merchant has reserved that money, they have yet to actually claim it. It will stay in this pending state until the merchant captures that money (i.e. the second phase of the two phase commit mentioned earlier) or until it expires (usually 8 days later).

In the simplest case, the merchant will submit a request to claim the pending amount. But in reality, the authorization and the clearing can be for different amounts. Consider an example where a restaurant swipes your credit card for the check amount (say $10) and you later add a 20% tip ($2). The $10 will usually be the authorization, and the clearing will show up as $12 to include the tip.

Whatever the amount, the merchant’s capture request will be sent to the network. The network will collate all of these capture requests into a file for Brex six times a day. The network puts these files on an SFTP server for Brex to consume. The files themselves consist of ISO 8583 messages with a header and footer. It is the job of MC clearing processor to download these files, validate them, and convert the ISO 8583 messages into network agnostic domain models. Visa clearing processor does the same thing, except instead of files and ISO 8583 messages, it receives HTTP requests that contain clearing messages as JSON.

This follows the same pattern to separate concerns as MC auth processor and Visa auth processor, allowing us to add more auth and clearing processors without having to add code into Transaction processor.

The road ahead

While the system has served us well so far, we have many challenges ahead. At Brex, we dream big. As we continue to scale, we need to ensure that our financial infrastructure can support and stay ahead of the growth curve that we aspire to achieve.

Brex customers also dream big, and we want to bring new features to our customers to empower them to achieve those dreams. To this end, we’re in the process of evolving our card processing system into a platform that enables internal teams at Brex to iterate quickly without compromising the reliability that our customers depend on. This platform will empower Brex to build features that our customers want so that they can focus on their businesses instead of spending time on their finances. This is at the core of our vision to build the Financial OS for the next generation of businesses.

Interested in building financial software and services for every growing business? Come join us at Brex!

Special thanks to co-authors Phil Nachum and Christopher Treviño, as well as contributors including Julia Wu, SJ (Sophia Jefferson), and Arjun Baokar.