- Card issuing APIs are not just for neobanks. Expense platforms, HR tools, payroll products, and procurement SaaS can all embed card programs and earn interchange revenue without holding a banking license.
- The right vendor depends on your use case: virtual-only programs for expense control, physical cards for field teams, or single-use cards for supplier payments each require different API capabilities.
- In the US, every issuing program needs a bank sponsor and, in most cases, a registered program manager sitting between the API vendor and the issuing bank. That structure has cost and compliance implications worth understanding before you sign anything.
- Interchange economics vary by card network, spend category, and card type. A product team that understands this can design a card program that pays for itself.
- The eleven vendors below cover five distinct use cases: expense management, payroll and contractor disbursement, procurement, rewards, and marketplace payouts.
The best card issuing APIs for SaaS tools are Stripe Issuing, Marqeta, Lithic, Highnote, Unit, Galileo, i2c, Adyen Issuing, Visa’s DPS (via program managers), Payoneer, and Extend. Each serves a different use case profile: Stripe and Lithic favor developer speed, Marqeta and Galileo favor transaction-level control, Unit and Highnote bundle issuing with banking infrastructure, and Adyen suits teams already on the Adyen payment stack. Choosing the wrong one adds six to twelve months of rework.
Why SaaS Teams Keep Getting Card Issuing Wrong
Most SaaS founders treat card issuing as a feature for fintech companies only. That is the wrong frame. Any B2B platform that touches employee spend, contractor payments, supplier procurement, or customer rewards has a card issuing opportunity sitting unused inside its existing workflows.
The misunderstanding usually centers on licensing. You do not need a banking license to issue cards in the US. What you need is a bank sponsor, a Visa or Mastercard program agreement (usually handled by the API vendor), and depending on your state footprint, registration as a money services business or a program manager relationship. The API vendor handles most of this, but the compliance structure varies enough between providers that it materially affects your legal obligations and your go-live timeline. If you want to understand how that compliance cost stacks up by stage, the breakdown in the real cost of compliance in fintech SaaS is worth reading before you open vendor conversations.
The second misunderstanding is economics. Card issuing is one of the few embedded finance primitives where the platform can earn revenue on every transaction without charging the end user more. Interchange, the small percentage of each transaction the issuing bank receives from the merchant’s acquiring bank, flows back through the program manager and API vendor to the platform. The split varies by vendor and volume, but the direction is clear: cards can shift a cost center into a revenue line.
How Should a SaaS Team Evaluate a Card Issuing API?
Before reviewing any vendor, it helps to have a consistent evaluation structure. The framework below is what we call the FintechSpecs Card Program Stress Test, four dimensions that separate production-ready programs from ones that will break under real usage.
- Control surface: Can you set per-transaction spend limits, MCC-level blocks, velocity controls, and real-time decline rules via API without a support ticket? If not, your expense or procurement use case will require constant manual intervention.
- Compliance handoff: Who owns KYC and KYB for cardholders? Is it the platform, the API vendor, or the bank sponsor? Programs where this is ambiguous create regulatory exposure the moment a cardholder is sanctioned or commits fraud.
- Interchange economics: Does the vendor share interchange with the platform, at what rate, and does the contract cap volume tiers that would reduce your share as you scale?
- Program manager requirement: In the US, some vendors require you to register as a program manager or work through one they designate. That adds a compliance layer, a cost layer, and a timeline. Know which structure you are entering before you sign.
Every vendor entry below scores against these four dimensions. For a broader view of how embedded finance fits into a SaaS product strategy, the best embedded finance APIs for SaaS companies covers the full stack beyond cards.
What Is the Difference Between a Card Issuing API and a Card Program?
A card issuing API is the technical interface: endpoints that let your application create card numbers, set controls, retrieve transaction data, and trigger funding. A card program is the complete regulatory and commercial structure behind those calls, including the bank sponsor, the network agreement with Visa or Mastercard, the program manager (if required), and the cardholder agreement. The API gives you access to the program. You are responsible for understanding what the program obligates you to do.
In the US, Visa and Mastercard both require an issuing bank to hold the program license. The API vendor either is that bank, partners with one, or operates as a program manager between you and the bank. Marqeta, for example, operates under its own bank partner arrangements and handles the program manager role. Stripe Issuing operates through Celtic Bank and Sutton Bank as issuing partners. Lithic issues through its own bank charter (Lithic acquired Bankprov’s parent entity and holds state licenses). These structural differences affect your compliance obligations and your indemnification exposure if fraud occurs.
Which Card Issuing APIs Work Best for Expense Management SaaS?
1. Stripe Issuing
Stripe Issuing is the fastest path from zero to issuing virtual cards in the US and EU, largely because most SaaS teams already have Stripe payment infrastructure. The API is well-documented, the sandbox is usable on day one, and card creation, spend controls, and transaction webhooks all behave consistently with the rest of Stripe’s API surface.
For expense management use cases, Stripe Issuing supports per-card and per-cardholder spend limits, MCC blocking, and real-time authorization webhooks that let your platform approve or decline a transaction before it posts. That last feature is the one that separates Stripe from simpler issuing wrappers: if your expense tool has policy logic, you can enforce it at the network level, not just flag violations after the fact.
The US program requires Stripe to act as program manager. According to Stripe’s public documentation, interchange revenue sharing is available but terms are negotiated, not published. Physical card support exists but adds production lead time. Best for: expense SaaS teams already on Stripe who want fast deployment and do not need multi-bank redundancy.
2. Lithic
Lithic is built specifically for developers who need card issuing without wrapping it inside a broader payment suite. The API design is lean, the real-time spend control system is genuinely granular (you can approve or decline at the individual authorization level with sub-second response windows), and the documentation makes the bank-program-platform relationship explicit rather than obscuring it.
Lithic supports both virtual and physical Visa cards, single-use card generation for supplier payments, and programmable spend controls at the card and account level. For expense SaaS, the single-use card capability is particularly useful: generate a card for a specific vendor, set a maximum spend, and the card auto-closes after one use. That removes an entire category of expense fraud without requiring employee training. Best for: developer-first teams building expense or procurement tools who want the most direct control over authorization logic.
3. Highnote
Highnote positions itself at the intersection of card issuing and embedded banking, meaning it offers both virtual card APIs and the account structures to fund them. For expense SaaS, this matters because cardholders need a funding source, and building that separately adds architecture complexity.
Highnote supports commercial charge cards, prepaid cards, and debit cards on Visa rails in the US. The platform’s control surface includes real-time authorization, spend limits, and MCC filtering. Highnote handles program management and KYC/KYB, which reduces the compliance burden on the platform but also means you are operating within Highnote’s compliance policies rather than your own. Best for: Series A or B SaaS teams that want a single vendor for both card issuance and account funding without assembling a multi-vendor stack.
Which APIs Fit Payroll, Contractor, and HR Disbursement Use Cases?
4. Unit
Unit is a banking-as-a-service platform that includes card issuing as one component of a broader embedded banking stack. For HR and payroll SaaS, that framing is more useful than a standalone card API: you can issue cards tied to FDIC-insured deposit accounts, handle ACH payroll funding, and give contractors or employees a card for immediate access to earned wages.
Unit’s card API supports virtual and physical Visa debit cards, per-card spend controls, and transaction webhooks. The compliance structure is notable: Unit handles KYC and KYB as part of its BaaS infrastructure, which means your platform does not need to build separate identity verification flows for cardholders. For a more detailed comparison of BaaS platforms that support this kind of full-stack approach, the best banking-as-a-service platforms for fintech startups covers Unit alongside its direct competitors. Best for: payroll or HR tools that need cards tied to real deposit accounts, not just prepaid load structures.
5. Galileo
Galileo is one of the older card processing and issuing platforms in the US, powering the back-end for programs including SoFi, Chime, and Robinhood at various points in their history. For SaaS teams, Galileo offers a mature API with deep transaction processing controls, but the integration surface is heavier than Stripe or Lithic.
For payroll and HR disbursement, Galileo’s strength is volume throughput and multi-product account structures. You can issue cards, handle ACH inflows, and manage account hierarchies at scale. The trade-off is integration complexity: Galileo is an enterprise platform, and the onboarding process reflects that. Best for: payroll SaaS at Series B or later with engineering resources to handle a deeper integration and volume that justifies the setup cost.
6. Payoneer
Payoneer addresses a gap the other vendors on this list mostly ignore: cross-border contractor and freelancer payouts. If your HR or marketplace platform pays workers in multiple countries, Payoneer’s prepaid Mastercard infrastructure lets recipients access funds in local currency without the platform building separate local payout rails.
The API surface is more limited than Stripe or Lithic for card control logic. You cannot run real-time authorization decisions through your own platform logic the same way. But for pure disbursement, where the card is a delivery mechanism for earned funds rather than a controlled spend instrument, Payoneer’s global reach is a meaningful differentiator. Best for: global HR platforms and freelancer marketplaces where cross-border payout reach matters more than spend control granularity.
Which Card Issuing APIs Are Built for Procurement and B2B Payments?
7. Marqeta
Marqeta built its entire architecture around just-in-time card funding and real-time transaction control, features that map directly onto procurement and expense use cases. Rather than pre-loading a card balance, Marqeta can fund a transaction at the moment of authorization, pulling from a business account in real time. For procurement SaaS, this means you can issue virtual cards to vendors or employees for specific purchase orders without pre-funding accounts in advance.
The transaction decisioning feature, where your platform receives an authorization request and returns an approve or decline decision within the network timeout window, gives procurement tools the ability to enforce purchase order matching at the point of sale. That is a fundamentally different control model than post-spend reconciliation. Marqeta operates as a program manager and handles card network relationships directly. Best for: procurement SaaS that needs just-in-time funding and real-time purchase order validation at the authorization level.
8. Corpay (FLEETCOR)
Corpay, part of FLEETCOR, offers card issuing APIs oriented toward fleet, AP automation, and B2B payment use cases. According to Corpay’s public developer documentation, the platform supports virtual and physical card creation, programmable spend controls, and integration into AP workflows. For procurement-focused SaaS, the strength is Corpay’s existing acceptance network among suppliers who already process fleet and commercial card payments.
Corpay is not a developer-first platform in the same way Lithic or Stripe are. The integration timeline is longer and the sales process is more enterprise-oriented. But for procurement SaaS selling into industries like logistics, construction, or field services where commercial card acceptance is already established, the network fit is hard to replicate from scratch. Best for: vertical SaaS in logistics or field services where fleet and commercial card acceptance patterns already exist.
Which APIs Support Rewards Programs and Marketplace Payouts?
9. i2c
i2c is a processing and issuing platform that supports highly configurable card programs across prepaid, debit, credit, and charge card structures. For rewards-heavy programs, i2c’s strength is its loyalty and rewards engine, which can tie card spend to point accumulation, cashback triggers, and tiered reward structures within the same platform that issues the card.
For SaaS teams building rewards programs on top of card spend, having the rewards logic inside the issuing platform (rather than built externally and reconciled against transaction feeds) reduces a significant amount of integration surface area. i2c operates globally and supports both Visa and Mastercard. Best for: SaaS teams building consumer or SMB rewards card programs where the rewards logic itself is a product differentiator.
10. Adyen Issuing
Adyen Issuing makes the most sense for SaaS teams already running payments through Adyen’s acquiring infrastructure. The issuing and acquiring share the same platform, which means reconciliation across inbound and outbound card flows happens natively without building cross-system data pipelines.
For marketplace SaaS, that unified ledger is genuinely useful: a platform can issue virtual cards to marketplace sellers for their operating expenses and settle marketplace revenues into the same account structure. Adyen Issuing supports virtual and physical Visa and Mastercard cards, real-time spend controls, and is available in the EU, US, and Australia. Best for: marketplace platforms already using Adyen for payment acceptance who want a single ledger for both acquiring and issuing.
11. Extend
Extend takes a different approach from every other vendor on this list. Rather than issuing new card numbers from a bank partner, Extend creates virtual cards as extensions of existing corporate credit cards, including Visa, Mastercard, and Amex commercial cards. For SaaS tools, this means your platform can give employees or vendors a virtual card with controls without asking your customer to switch their underlying corporate card program.
The practical implication for expense or procurement SaaS: you can offer card-level spend controls, receipt capture, and transaction data to companies that already have corporate card programs, without those companies needing to replace their existing card issuer. That is a different go-to-market motion than the other vendors here. Extend does not provide interchange revenue to the platform the way a full issuing program does. Best for: expense or procurement SaaS that wants to offer virtual card controls as a feature layer on top of customers’ existing card programs, without requiring a card program migration.
How Do Interchange Economics Actually Work for SaaS Platforms?
Interchange is the fee paid by the merchant’s acquiring bank to the issuing bank on every card transaction. In the US, commercial card interchange rates are generally higher than consumer card rates, and virtual card transactions processed as commercial spend can carry interchange rates in the range of 2% to 3% depending on the card type, MCC, and network agreement. These are publicly published in Visa and Mastercard interchange rate tables.
Consider a hypothetical: a Series A expense management platform with 500 SMB customers, each averaging $20,000 in monthly card spend. That is $10 million in monthly volume. At a 1.5% net interchange rate after the bank sponsor and program manager take their shares, the platform earns roughly $150,000 per month in interchange revenue. The actual split depends heavily on the vendor contract, the card type, and the volume tier. But the direction is clear enough that ignoring it is leaving real money unclaimed. Understanding exactly how fintech infrastructure companies structure these economics is covered in detail in how fintech infrastructure companies actually make money.
Not all vendors share interchange with SaaS platforms. Extend, for example, does not generate interchange for the platform because the underlying card belongs to the customer’s existing issuer. Payoneer’s model is more disbursement-oriented. For platforms where interchange is a strategic revenue line, the vendors to focus on are Stripe Issuing, Lithic, Marqeta, Highnote, Unit, and i2c, all of which make interchange sharing commercially available, even if terms require negotiation.
What US Program Manager Caveats Should SaaS Teams Know?
In the US, Visa and Mastercard require that any entity managing a card program on behalf of an issuing bank register as a program manager or operate under one. This is not optional, and it is not handled automatically by signing a contract with an API vendor. Some vendors, like Marqeta and Highnote, act as the program manager themselves and absorb that regulatory relationship. Others, like Galileo, require you to work through a designated program manager or register directly.
Registration requirements, examinations, and ongoing compliance obligations vary by card network and by state. Some states require money transmitter licenses for certain card program structures. If your platform custodies funds for cardholders before spending (as with prepaid programs), that custodial relationship may trigger additional licensing requirements. This is the compliance dimension most SaaS founders underestimate, and it is one of the primary reasons card program go-live timelines stretch from the anticipated six weeks to six months. The fintech product and compliance readiness checklist includes a dedicated section on issuing program requirements that is worth reviewing before you commit to a vendor.
The practical implication: always ask a prospective vendor who owns program manager registration, what compliance obligations transfer to your platform, and what happens to your customers’ cards if the vendor’s bank sponsor relationship changes. All three questions have happened in practice across the BaaS industry, and the answers are not always what the sales deck implies.
Vendor Comparison: Card Issuing APIs by Use Case, Control, and Interchange
| Vendor | Primary Use Case | Real-Time Auth Control | Virtual + Physical | Interchange Sharing | Program Manager Role | Best For |
|---|---|---|---|---|---|---|
| Stripe Issuing | Expense | Yes | Both | Negotiated | Stripe acts as PM | Teams already on Stripe |
| Lithic | Expense, Procurement | Yes | Both | Yes | Lithic owns bank charter | Developer-first builds |
| Highnote | Expense, Embedded Banking | Yes | Both | Yes | Highnote acts as PM | Series A/B bundled stack |
| Unit | Payroll, HR | Yes | Both | Yes | Unit acts as PM | Payroll tied to deposit accounts |
| Galileo | Payroll, Consumer | Yes | Both | Yes | Platform or designated PM | High-volume enterprise payroll |
| Payoneer | Global contractor payout | Limited | Physical (Mastercard) | No (disbursement model) | Payoneer owns program | Cross-border HR/marketplace |
| Marqeta | Procurement, Expense | Yes (JIT funding) | Both | Yes | Marqeta acts as PM | JIT procurement authorization |
| Corpay | Fleet, AP Automation | Yes | Both | Negotiated | Corpay acts as PM | Logistics/field services vertical SaaS |
| i2c | Rewards, Consumer/SMB | Yes | Both | Yes | Platform or designated PM | Rewards-heavy card programs |
| Adyen Issuing | Marketplace, Expense | Yes | Both | Yes | Adyen acts as PM | Existing Adyen acquiring customers |
| Extend | Expense, Procurement | Yes (via existing card) | Virtual only | No | Not applicable | Overlay on existing corporate cards |
What Should a SaaS Team Check Before Signing an Issuing Contract?
Pricing for card issuing APIs is rarely published in full. Most vendors quote per-card fees, monthly platform fees, and interchange splits in private negotiations. That opacity has real implications. The hidden costs killing fintech SaaS margins includes a section on card program cost structures that often surprise founders after launch, including per-authorization fees, chargeback handling costs, and card production minimums for physical card programs.
Before signing, get explicit written answers to four questions: What is the per-card monthly fee at your projected volume? What percentage of gross interchange flows to the platform, and does that change at volume tiers? Who handles chargebacks and disputes, and what is your liability exposure? If the bank sponsor relationship changes, what happens to active cards and cardholder funds?
The fourth question is the one most platforms skip. Several BaaS bank sponsor relationships have terminated or restructured in the past few years, causing card programs to shut down or migrate under compressed timelines. If the API vendor cannot give you a clear answer on contingency planning, treat that as a signal about the structural stability of the program.
Frequently Asked Questions
What is a card issuing API?
A card issuing API is a set of programming interfaces that allows a software platform to create and manage payment cards (virtual or physical) programmatically. The API connects to a backend card program operated by a bank sponsor and, in the US, a program manager. Developers use it to create card numbers, set spend controls, read transaction data, and trigger funding without building bank infrastructure directly.
Do SaaS companies need a banking license to issue cards?
No. SaaS platforms do not need a banking license to issue cards in the US. They need to work with an API vendor that has a bank sponsor and a Visa or Mastercard program agreement in place. Depending on the program structure, the platform may need to register as a program manager or work through one the vendor designates. Some states also require money transmitter licensing for prepaid card programs that custody cardholder funds.
What is a program manager in card issuing?
A program manager is an entity registered with Visa or Mastercard to manage a card program on behalf of an issuing bank. In the US, every card program requires a bank to hold the issuing license, and a program manager sits between the bank and the platform, handling compliance, dispute resolution, and network reporting. Some API vendors (Stripe, Marqeta, Highnote, Unit) act as program manager themselves. Others require the platform to register or use a designated third party.
How does interchange revenue work for SaaS platforms?
Interchange is the fee the merchant’s acquiring bank pays to the issuing bank on every card transaction. When a SaaS platform issues cards through an API vendor, the vendor typically shares a portion of that interchange with the platform. The exact split depends on the vendor contract and transaction volume. Commercial and corporate card interchange rates in the US are generally higher than consumer rates, making expense and procurement card programs more economically attractive than consumer-facing ones.
What is the difference between Stripe Issuing and Marqeta?
Stripe Issuing is better for teams already on Stripe infrastructure that want faster deployment and a familiar API surface. Marqeta is better for teams that need just-in-time card funding, where a card is funded only at the moment of authorization rather than pre-loaded. That JIT model is particularly valuable for procurement use cases where purchase order matching at the authorization level replaces post-spend reconciliation. Both support real-time spend controls, but Marqeta’s control model was built specifically for that use case from the start.
Which card issuing API is best for a marketplace payout use case?
Adyen Issuing is the strongest option for marketplace platforms already using Adyen for acquiring, because the same platform handles both inbound payments and outbound card issuance with a unified ledger. Payoneer is the strongest option for cross-border marketplace payouts where recipients are in multiple countries and need local currency access. For domestic marketplace payouts tied to deposit accounts, Unit provides the cleanest integration of card issuance with FDIC-insured account infrastructure.
Can virtual card APIs enforce spend policies in real time?
Yes, but only if the API vendor supports real-time authorization decisioning. Vendors including Stripe Issuing, Lithic, Marqeta, and Highnote send authorization requests to the platform before approving a transaction, allowing policy logic (MCC blocks, vendor matching, budget limits) to run in real time. Some lighter-weight virtual card APIs only offer post-transaction controls, meaning violations are flagged after spend occurs rather than prevented. For expense and procurement use cases, the distinction matters significantly.
What hidden costs should SaaS teams expect in a card program?
Beyond the per-card monthly fee and interchange split, SaaS teams typically encounter per-authorization fees (charged on every transaction attempt, approved or declined), physical card production minimums and shipping costs, chargeback handling fees, compliance reporting costs if the platform takes on program manager obligations, and potential card scheme fees passed through by the vendor. Programs that look economically attractive at small volumes sometimes compress at scale if volume tiers reduce interchange share or if per-authorization fees accumulate faster than expected.
How to Match a Card Issuing API to Your SaaS Product
The vendors on this list do not compete head-to-head across all use cases. Extend solves a different problem than Galileo. Payoneer operates in markets where Lithic has no cards. The framework that matters is not “which vendor is best” but “which vendor fits the authorization model my product requires.” If your product logic needs to enforce spend policy before a transaction clears, you need real-time decisioning. If your product only needs to deliver funds to a recipient, you need a disbursement model. Those are different products built on different infrastructure, and conflating them creates the kind of rework that costs six months and burns engineering goodwill.
The program manager question deserves more weight than most teams give it. Compliance obligations that transfer to the platform when the vendor’s bank sponsor relationship shifts are not theoretical. They have materialized for real programs, and the platforms that survived those transitions were the ones that asked the hard questions during contract review rather than after go-live. If you want a checklist for exactly that review process, the critical mistakes when choosing fintech infrastructure covers vendor dependency and bank sponsor risk in detail.
Card issuing is one of the few embedded finance primitives where the product decision and the revenue decision are the same decision. A well-designed card program generates interchange that partially or fully offsets the cost of running the program. A poorly designed one creates fraud exposure, compliance overhead, and customer support volume without generating enough interchange to justify it. Getting that balance right starts with picking the right vendor for the right use case, which is exactly what the table and framework above are built to help you do.
