Architecting a Modern Card Authorization Platform

January 24, 2025

Mirek Klimos

Rik Heijdens

Table of Contents

ISO 8583 Messages

When you tap your credit card at a coffee shop, a sequence of messages starts flowing between multiple financial institutions. Within seconds, these messages traverse a global network, validating your card, checking your balance, evaluating risk rules, and ultimately deciding whether to approve your purchase of that morning latte.

Card payments involve four key players: the acquirer (who enables merchants to accept card payments), the card network (like Visa or Mastercard, who operate the payment scheme), the processor (who handles the technical aspects of card management), and the issuer (who provides cards to consumers). These parties communicate using ISO 8583 messages - a standardized format that's been the backbone of card payments for decades. However, each card network has its own flavor of ISO 8583, adding custom fields and rules to support network-specific features.

In this article, we'll explore:

• How ISO 8583 messages form the foundation of card payments
• Why and how we normalize messages across different card networks
• The intricacies of authorization processing and rule evaluation
• Architectural patterns for building a highly available authorization platform

ISO 8583 Messages

In the early days of card payments, there was no standard way for financial institutions to exchange transaction data. ISO 8583 emerged as the universal language of the payments world, establishing a common format that all networks could adopt. While networks have since added their own dialects, the core structure remains the same.

An ISO 8583 message consists of three key components: the Message Type Indicator (MTI) that signals the message's purpose, one or more bitmaps that act as a table of contents, defining which Data Elements (fields) are present, and Data Elements containing the actual transaction details.

The Message Type Indicator encodes multiple aspects of the message: its function (like authorization or clearing), its source (whether it's coming from an acquirer or issuer), and its message class (request, response, or advice). For example, when you tap your card at a coffee shop, it triggers an authorization request message asking "Can this cardholder spend $5 at Coffee Shop X?". The issuer must respond within a fairly strict timeout to ensure a smooth checkout experience. In contrast, advice messages inform recipients about events that have already occurred.

Message Normalization

Instead, we’ve taken a more elegant approach: We normalize card network messages at our system's edge, converting various ISO 8583 formats into a single, well-defined internal format we call CardNetworkEvent. This translation happens as soon as messages enter our system and just before they leave, allowing our internal services to process transactions without needing to understand the intricacies of each network's ISO 8583 implementation.

Our internal CardNetworkEvent format uses an explicit, machine-readable schema and includes all the necessary information:

• Common fields that exist across all networks, such as transaction amount, country code, merchant details, and track data
• Network-specific fields that capture unique features of each network (like Mastercard's Security Level Indicator or Visa's Electronic Commerce Indicator)
• Lithic-internal fields that track operational details like message receipt time and ingress switch identification

Authorization Processing

One of the tasks Lithic performs on behalf of its customers is processing authorization requests when cardholders attempt to transact. When such a request arrives through the card network, Lithic must respond within a strict timeout. Our authorization service processes these requests through multiple evaluation layers.

At the foundation, we perform universal validation checks that apply to all transactions, covering dozens of basic security measures. The next layer consists of Lithic's internal risk and compliance rules. We also evaluate any Authorization Rules set by our customers, enabling them to implement their own transaction controls and business logic. Both these internal and external rules are executed on a platform which we refer to as Lithic's Rules Engine.

Designed for availability

Our authorization processing infrastructure is built with high availability and horizontal scalability as core design principles. This focus has enabled us to achieve over 99.99% availability in the past year.

When measuring availability in a card authorization system, it's crucial to understand different types of failure modes:

1. Internal system failures
2. Timeout scenarios
3. Complete unavailability due to infrastructure issues

The two pillars of our availability strategy are redundancy and resiliency. For redundancy, we eliminate single points of failure throughout our authorization processing infrastructure. Our infrastructure implements an "active-active" strategy, ensuring that every deployed instance of our authorization processing service and its dependencies actively handle a portion of production traffic.

Conclusion

In this post we discussed the intricacies of building a modern card authorization platform. The key is balancing competing demands: respecting network-specific capabilities while providing a clean, modern API; maintaining high availability while processing complex authorization rules; scaling horizontally while ensuring consistency. Through our multi-layered authorization processing and focus on redundancy and resiliency, we've built an authorization platform that serves as a solid foundation for modern card programs.