The card issuing industry has been evolving at break-neck speed. Scaled fintech challengers, the embedding of financial services by non-bank intermediaries, and the increasing digitization of payments have irreversibly changed the game for card issuers.
To serve this dynamic market, forward-looking issuers are increasingly turning to a new generation of ‘developer-first’ issuer processors to keep pace and differentiate their card programs.
In this guide, we introduce developer-first issuer processing and discuss ways that issuers can identify and leverage these technology providers to future-proof their card programs.
Issuer Processing Recap
Roughly $12 trillion was spent on payment cards in the U.S. in 2023. Processing all these payment transactions for card issuing banks (and the fintechs or card program managers that work with those banks) is a small group of back-end payment infrastructure providers better known as issuer processors.
These issuer processors are responsible for handling billions of individual card transactions every day, with over 1.29 million credit card transactions alone every minute. This means successfully processing and orchestrating billions of network messages daily, including authorizations, clearing files, returns, balance inquiries, etc., to ensure that card-issuing banks can deliver safe, reliable, and seamless experiences to their cardholders.
Issuer processors also provide essential tools that issuers need to maintain regulatory compliance, follow card network rules, fight fraud, and manage chargebacks.
Three Generations of Issuer Processing Infrastructure
First-generation fintechs like Fiserv (founded 1984), FIS (founded 1968), Jack Henry (founded 1976), and TSYS (founded 1983) are known primarily for their core banking software and merchant acquiring businesses, but they also dominated the market for card issuer processing for decades. In a paradigm where financial products like payment cards were built and distributed only through traditional banks, this was no surprise. These legacy providers still heavily leverage COBOL, IBM JCL, mainframe applications, and batch processing.
A second generation of card-issuing infrastructure providers emerged in the early 2000s with i2c (2001), Galileo (2003), and Marqeta (2010). They set out to build more modern card issuing platforms, and they slowly started to bundle in compliance, risk, and support services for fintechs that were new to card issuing and program management. This laid the grounds for the launch of new financial products by non-bank entities — Chime was built on Galileo, and Buy Now Pay Later (BNPL) companies like Affirm and Klarna were built on Marqeta.
What we’re seeing today is the rise of the third generation of card issuing infrastructure — developer-first issuer processors.
Developer-first issuer processors, like Lithic, are purpose-built to give card issuers extremely high levels of observability, control, and flexibility over their card programs. This has unlocked a wave of innovation for card-issuing banks and fintechs to build new experiences around bill pay, commercial payments, disbursements, digital banking, rewards and incentives, and expense management. What’s more, these solutions have empowered card issuers to deliver better cardholder experiences, while simultaneously improving card program margins.
Developer-First Issuer Processing
Developer-first issuer processing has three core pillars:
Observability
Observability is vital for tech-forward businesses. It enables self-serve debugging, better resourcing planning, and more. These benefits ultimately lead to more efficient business workflow management.
To deliver higher observability, developer-first issuer processors provide real-time transaction webhooks so card issuers have full visibility into their card program(s) — including the lifecycle of every cardholder and card transaction. This is in sharp contrast to legacy issuer processors, who predominantly run daily batch jobs to provide reporting to issuers.
Take Lithic’s Events API and Webhooks, for example. Through these endpoints, card issuers can subscribe to receive real-time alerts on everything ranging from digital wallet tokenization attempts to chargeback case updates to transaction settlements. Card Issuers can also replay failed transaction webhooks in the event of disruptions like cloud service provider outages.
One of the more popular alerts for large consumer card issuers has been the webhook for chargeback/dispute evidence upload failures. This notifies customers immediately if there's an issue with the dispute evidence that they’ve uploaded so that they can correct it and file an on-time dispute. For one customer, using Lithic’s webhook alerting for chargeback/dispute evidence upload failures decreased their dispute processing time by 10x, saving tens of thousands of dollars every month and simultaneously helping us deliver a 95% chargeback success rate for them.
Another pain point we hear about from card issuers all too often is that their legacy issuer processors do not provide enough granularity or visibility into why transactions get declined. This creates an operational tax on card issuers’ support and tech teams by forcing them to manually investigate and write support tickets just to explain transaction failures that cardholders inquire about.
At Lithic, we’ve built detailed results in transaction webhooks so that issuers receive clear and insightful decline reason codes. For example, your fraud team may have implemented a rule in Lithic’s system to block spending at a specific set of high–risk merchant category codes, in which case Lithic would fire a webhook to inform you that the transaction was declined along with the reason code AUTH_RULE_BLOCKED_MCC. Or, perhaps the cardholder might be breaching a spending velocity limit that your risk team recommended, in which case you’d receive a reason code such as ACCOUNT_MONTHLY_SPEND_LIMIT_EXCEEDED.
For issuers, this kind of observability into their card program(s) ultimately means the ability to efficiently monitor and automate business workflows at scale to save time and money. And perhaps more importantly, for their cardholders, this means faster time to resolution and far fewer surprises or disruptions.
Control
Creating unique and safe card products requires the ability to apply granular controls over card transactions. Developer-first issuer processors are designed from the ground up to provide issuers with these programmatic controls.
For example, take 3DS authentication flows:
• 3DS, as most issuers will be all too familiar with, is a merchant-initiated fraud prevention protocol for applying additional security to online card transactions.
• Perhaps most importantly for issuers, a 3DS authenticated transaction creates a chargeback liability shift 100% onto the issuer, which is why issuers need to be very careful with how they choose to authenticate a cardholder during a 3DS transaction.
• At Lithic, we’ve built collaborative 3DS authentication decisioning, giving issuers the controls over online fraud-fighting tools like never before.
• By participating in the 3DS authentication flow, card programs gain access to 30+ data fields on the transaction and the person who made the transaction. This includes the email address provided at checkout, the IP address of the buyer, and even the time zone of their browser. Leveraging this data can enable massive improvements in fraud loss prevention.
Another area in which granular controls like this are proving to be invaluable is in the realm of digital wallets. To further aid our issuing customers in fighting unauthorized use of their cards, Lithic provides control over digital wallet tokenizations with two-factor authentication. Fraud on digital wallet cards is generally not disputable with the networks, as they’re considered authenticated via the cardholder’s Face ID or smartphone passcode. This means that stopping fraudulent tokenizations using parameters like a device risk score, IMEI number, and location can prevent costly, unrecoverable fraud losses.
Control over various aspects of a card program like 3DS authentications and tokenization requests therefore enable issuers to fight back against sophisticated fraudsters, and protect their bottom line.
Flexibility
In contrast to legacy issuer processors, developer-first issuer processors give you plenty of options and choices in how you set up your card program so that you can build highly customized workflows that suit your exact needs and requirements.
For instance, some issuers prefer to be in the authorization stream to make custom authorization decisions on every single transaction using their own ruleset. Lithic supports this through its ASA (Authorization Stream Access) functionality. One large card program manager found immense success in tamping down on fraud (including counterfeit card fraud and account takeover fraud) with this approach, as it enabled them to act on dozens of proprietary behavioral signals in real time.
Other issuers prefer to set static authorization rules on each card or across the entire card program and have Lithic enforce their specified rules. This is handled through Lithic’s Authorization Rules API.
Some issuers even choose to use a combination of both, which is equally well supported.
Similarly, some issuers, such as those in the cobrand-as-a-service or banking-as-a-service space, prefer to build their own custom ledgers in order to better integrate with their chosen BIN sponsors or to better administer their own unique cashback, points, and rewards programs. For these customers, a developer-first issuer processor is typically able to provide a modular, issuing gateway solution that is ledger-agnostic. On the other hand, some issuers and fintech program managers prefer to leave the network message threading and managing of account balances to the issuer processor, in which case the combination of an issuing gateway plus the ledger is the ideal combo.
This type of flexibility gives issuers the ability to build unique card programs that are adapted to the specific needs and behaviors of their chosen cardholder segment. Additionally, the flexibility to mix and match features and functionality can also create huge cost savings. Issuers no longer need to pay for a bundle of redundant or irrelevant features that they’ll never use. Instead, they can selectively pick from a list of services provided by their developer-first issuer processor based on what delivers tangible value across the card program.
Conclusion
An issuer processor is perhaps the single most critical piece of infrastructure behind any card program. Leveraging a developer-first issuer processor is the best way for issuers to future-proof their card programs and innovate faster.
As an issuer, the last thing you want in your card program is to have invested time and resources in perfecting customer service, rewards and offers, branding, distribution, etc., only to be dragged down by the limitations of your back-end payments infrastructure.
Inviting your Product and Engineering teams to the table early and giving them a voice in the evaluation process will save you from countless hours of headaches down the line.
And, of course, knowing developers, they’d much rather test drive than read product marketing content. To this, we say, please feel free to take Lithic for a spin in our Sandbox.
Or check out our API Client Libraries in your choice of major programming language, including Java, Go, Kotlin, Python, Ruby, and Node JS, which you can use to speed up your time to market. Lithic also maintains an OpenAPI spec you can reference any time.
To learn more about how Lithic’s developer-first issuer processing technology can help you build a unique and differentiated card program, speak to one of our experts.