NEW PLAYBOOK: Built to Launch — Modern payments infrastructure for teams built to innovate
Three platforms. Three different eras. None of them will tell you which one they belong to.
The wrong choice sets your ceiling before you launch.
We built Highnote as the unified issuer processor for embedded finance. Here is how the generations divide.
Key Takeaways:
The card platform market did not evolve in a straight line. It evolved in generations, each built to solve a different problem. Which generation a platform belongs to tells you more about its ceiling than any feature comparison.
Gen 1: Legacy Scale (Galileo)
Galileo was built when getting a card program running at scale was the hard problem. The infrastructure is mature. The processing depth is proven. The customer list (Chime, Dave, Robinhood) represents a generation of fintechs that needed exactly what Galileo provided: reliable transaction processing at volume. The ceiling is the model. Galileo is a processor. Acquiring, ledger reconciliation, and program management sit outside the core platform. The architecture reflects the era it was built for.
Gen 2: Developer-Native, API-First (Lithic)
Lithic built the API first, along with the processing infrastructure around it. Developer experience is clean, the sandbox is fast, and time-to-first-card is genuinely low. Lithic also owns its bank subsidiary (Lithic Bank), which gives it more direct control over the BIN sponsorship relationship than pure processor models provide.
The ceiling is still the top layer. Acquiring lives elsewhere. The ledger does not extend across both sides of the money movement.
Gen 3: Enterprise Embedded Finance (Highnote)
Highnote was built for an era when embedded finance was not a product category. It is a competitive requirement. Issuing, acquiring, credit, and a real-time ledger on one API and one data model. Program management and compliance are built in, not coordinated across third parties.
The architecture was designed to address the problem that Gen 1 and Gen 2 platforms were not built to solve: owning the full financial stack within a product.
Each generation works until it doesn't. That failure is what builds the next one. Fragmentation is failing at scale. The question is: which generation has your program already outgrown?
Galileo: Processing at Scale, Not Program Ownership
Right for mature debit and prepaid programs that need proven infrastructure at volume. The ceiling is architectural: acquiring, ledger reconciliation, and program management sit outside the core. When your program evolves, you coordinate that evolution across vendors that Galileo does not control.
Lithic: Developer Velocity, Not System Ownership
Right for teams where getting to the first card fast is the primary constraint. Lithic Bank's direct BIN ownership reduces the number of compliance intermediaries. The platform optimizes for engineering speed inside the issuing layer. What happens after the card is issued (acquiring, ledger, program economics) lives elsewhere.
Highnote: Embedded Finance, Not Just Issuing
Right for programs where the card is infrastructure inside a larger product. The question is not "how do I get a card running?" It is "how do I own the full financial stack and the economics that come with it." Issuing, acquiring, credit, and ledger are not integrations. They are the same system.
Galileo Financial Technologies: Acquired by SoFi in 2020. Powers Chime, Dave, Robinhood, and the generation of US fintechs that scaled on debit and prepaid. Gen 1 at its most proven.
Lithic: Lithic Bank owns the BIN directly, reducing the compliance intermediary layer that other processor models carry. Developer documentation is among the cleanest in the category. Gen 2 at its most differentiated.
Highnote: Named to Forbes Fintech 50 for two consecutive years. Programs running on Highnote (Splitit, OatFi, Coinflow) share a consistent pattern: multiple financial product types on one platform, not coordinated across three. Gen 3 is the only model on this list where that is possible.
API Design and Developer Experience
Gen 1 built processing depth. The API reflects that lineage: capable, but not designed for the iteration speed modern engineering teams expect. Gen 2 built developer velocity first. Lithic's sandbox is purpose-built, the documentation is thorough, and the path from API key to card transaction is genuinely short. Gen 3 built system ownership. Highnote's API unifies issuing, acquiring, credit, and ledger events into a single surface. The developer experience is clean. The architectural surface is what neither Gen 1 nor Gen 2 can match.
Card Product Coverage
All three support virtual and physical cards. The generational difference shows in depth: Galileo and Highnote support credit; Lithic's credit product is more limited. Highnote is the only platform that supports debit, credit, charge, and prepaid in a single system, without separate integrations per card type. Gen 3 does not require a rebuild when your program grows into its next use case.
Program Management and White-Glove Support
Gen 1 program management is process-driven and suited to established programs with predictable needs. Gen 2 reduces the number of intermediary compliance layers by leveraging Lithic Bank's direct BIN ownership, but program management beyond that remains with the operator. Gen 3 owns program management as a platform function. Not a support tier. Not a third-party relationship your team coordinates. Configuration control without coordination overhead is an architectural outcome, not a service level.
BIN Sponsorship and Bank Partner Model
Galileo: bank partner model, processor in the middle. Lithic: Lithic Bank holds the BIN directly, reducing the intermediary layer. Highnote: bank partner model with program management as a built-in platform function. The Lithic model offers more control at the bank layer. The Highnote model offers more control at the program layer. Which layer matters more depends on where your compliance and operational risk actually live.
Speed to First Card
Gen 2 wins here, and it is not close. Lithic's sandbox is built for iteration. Galileo and Highnote require more structured onboarding because they are setting up more complex program infrastructure. That is not a disadvantage. It reflects what you are actually buying.
Scalability and Uptime Track Record
Gen 1 has the most proven track record at the consumer-fintech scale. Galileo processes transactions for programs with tens of millions of cardholders. Gen 3 is built for enterprise-scale on a unified infrastructure, with a growing enterprise customer base. Gen 2 serves mid-market programs well; very high-volume enterprise programs are a less-established part of Lithic's track record.
How Each Platform's Pricing Model Works
The real pricing question is not what each platform charges per transaction. It is what each architecture forces you to buy elsewhere.
Gen 1 and Gen 2 platforms price the issuing layer. Acquiring infrastructure, real-time ledger tooling, reconciliation systems, and external program management are costs you assemble separately. Those costs do not appear in a processor contract. They appear in your engineering roadmap, your finance team's headcount, and your operational overhead every quarter.
Gen 3 prices the full stack. One commercial relationship covers issuing, acquiring, program management, and ledger. The cost model reflects the architecture.
What Costs Look Like at Different Scales
At low volume, Gen 2 (Lithic) has the lowest friction-to-start cost. Sandbox access is fast, and setup overhead is minimal. Gen 1 and Gen 3 require more structured onboarding investment upfront.
At mid-market volume, headline rates across all three become competitive. The divergence lies in the operational costs of the model: reconciliation tooling, external program management, compliance coordination, and infrastructure acquisition that issuing-only platforms do not provide.
At enterprise volume, the gap compounds. Every seam in a fragmented architecture carries a recurring cost. The external tooling required to close the acquiring and ledger gaps on Gen 1 and Gen 2 platforms is not a one-time integration. It is an ongoing infrastructure that a Gen 3 platform makes unnecessary.
Your processor contract is not your total cost of ownership. Your architecture is.
Who Owns the BIN Sponsorship Relationship
On Galileo and Highnote, a bank partner holds the BIN. Your commercial relationship is with the platform; the issuing bank sits behind it. On Lithic, Lithic Bank holds the BIN directly, giving the program a more direct line to the issuing bank because they are the same entity.
Compliance Responsibilities: Platform vs. Customer
All three platforms place some compliance responsibility on the program operator. The distinction is how much. Platforms that own program management as a core function absorb more of the compliance workflow. Platforms where program management is external push coordination overhead onto your team: between the processor, the bank, and any third-party program manager in the chain.
What Happens If the Bank Partner Changes
On bank-partner models, a change in the issuing bank can require card reissuance and program renegotiation. This is a real operational risk for high-cardholder programs. Lithic's owned-bank model reduces this specific risk. Highnote's platform-managed compliance model reduces the operational complexity if a transition is required.
Ask every platform directly how a bank partner transition would be handled before signing. Most programs discover the answer at the worst possible time.
Galileo powers Chime, Dave, Robinhood, and a generation of US fintech programs that needed processing scale for consumer debit and prepaid. The track record at volume is the most extensive on this list.
Lithic serves developer-led teams and enterprises building custom card programs where engineering control and API design are the primary requirements. The customer base skews toward programs that need to move fast and stay within the issuing layer.
Highnote powers Splitit (unified issuing and acquiring for installment payments), OatFi (embedded credit), Coinflow (stablecoin payment infrastructure), nmible (clinical trial reimbursement cards), and SKUx (brand rewards and payments). The pattern is consistent: programs that require issuing, acquiring, or credit to work together on one platform, not in parallel.
What You're Actually Committing To
Every card program creates lock-in at three layers. BIN and card number ranges require reissuance to move. Authorization logic and program rules need to be rebuilt, not migrated. Integration dependencies (ERP systems, fraud tooling, reconciliation pipelines) require reconnection. Tokenized cards add network coordination overhead. These are not reasons to avoid choosing a platform. There are reasons to choose the right one.
Data Portability and Exit Options
Ask every platform directly: can you export your full transaction history, cardholder data, and program configuration? In what format? On what timeline? At what cost? Platforms vary significantly here. The cost of staying on the wrong platform compounds every quarter. The cost of migration is fixed and finite.
Choose Galileo if...
Your program is a mature debit or prepaid product at significant volume. You need proven processing infrastructure with an extensive track record. Acquiring unification and real-time ledger visibility are not current requirements. Galileo's installed base and processing depth are real advantages for programs that fit the model.
Choose Lithic if...
You are a developer-led team that needs fast iteration, clean API design, and a quick path from prototype to production. You value Lithic Bank's direct BIN ownership, and your program stays within card issuance. Engineering velocity is the primary constraint.
Choose Highnote if...
Your program needs to issue and acquire on a single platform. Your use case is embedded finance or vertical SaaS. You need a real-time ledger across both sides of money movement. You are building a program that will evolve across card constructs without a rebuild. The goal is to own the full financial stack inside your product.
For programs comparing issuing-only options more broadly, see our Highnote vs. Marqeta breakdown.
Gen 1 solved processing at scale. Gen 2 solved developer velocity. Gen 3 solves something neither was built for: owning both sides of money movement, the ledger that connects them, and the program infrastructure that governs it, all inside one platform, built for you and the specific program you are running.
No fragmented reporting. No compliance overhead pushed onto your product team. No acquiring gap that requires a separate vendor relationship. One API. One data model. One source of truth.
When issuing, acquiring, and ledger live in the same system, program teams ship faster, finance teams close cleaner, and the platform adapts to what you build next instead of constraining it.
The right issuer processor is not the one with the most features. It is the one built for the generation of problems you are actually solving.
Request a demo to see how Highnote handles your specific program so you can launch, evolve, and scale without rebuilding your stack.
FAQs
How do I choose the right issuer processor for my card program (Galileo vs Lithic vs Highnote)?
Choose based on architecture, not features. Match your needs to the platform model: processing scale, developer velocity, or unified infrastructure. If you need issuing and acquiring on one ledger, only unified platforms support that.
Why does issuer processor bank ownership vs. bank partner models matter for card programs?
It matters because it affects control, risk, and continuity. Bank-owned models reduce intermediaries, while partner models add dependency risk if relationships change. Always confirm how BIN transitions and disruptions are handled before signing.
What is involved in migrating from one issuer processor to another card platform?
Migration requires rebuilding program logic, reconnecting integrations, and handling BIN or cardholder transitions. Most programs take 3–6 months depending on complexity. Prioritize data portability and minimize customer disruption during planning.
Author
Highnote Team