How to pick card issuing for vertical software

Who this is for

The founder, COO, or head of product at a vertical software company or fintech that wants branded debit, prepaid, charge, or credit cards inside the product for users to spend. You are picking card issuing infrastructure on a partner bank’s BIN sponsor, not becoming the licensed issuer on day one.

Wall-off. This page is not card acquiring or PayFac-as-a-service. If the job is taking a rate on merchant checkout volume, read How to pick payments and the payments hub. It is not deposit accounts or BaaS balances as the primary job (How to pick banking, banking). It is not working capital (How to pick lending, lending). Issuing creates cards your users spend. Acquiring takes cards from their customers. A deposit sponsor bank and a BIN sponsor can be the same bank. They are not automatically the same role.

This page is also not a ranked table. The cards list is editorial. Order is not a score you can buy. Pair with The stack for where cards sit after payments, and Marqeta vs Lithic when you are down to those two issuer-processor shapes.

The decision tree (managed program manager vs bring-your-own BIN vs processor-tied issuing)

Three jobs get sold as “embedded cards.” They are not the same program. Name the job before you name a vendor. Embedded is how cards show up in the product. It is not who holds the BIN.

Managed program manager. An issuer processor (or program manager) supplies or introduces the BIN-sponsor bank, runs more of KYC/KYB, compliance, fulfillment, disputes, and network setup, and exposes an issuing API you brand. You control spend logic and cardholder UX. You are not the bank. Production is a sales conversation plus bank and network approval. On this directory that shape includes Marqeta Managed By Marqeta, Lithic Program Managed, Highnote as issuer processor and program manager, Galileo when SoFi Tech Solutions acts as program manager and processor (BaaS model on that listing), and i2c when you take a partner-bank / BIN-sponsor path they coordinate. What you get: a path to branded virtual and physical cards without standing up your own bank and BIN stack on day one. What you do not get: the issuing license, a self-serve live start, or (on most of these pages) a published platform rate card.

Bring-your-own BIN. You already have (or will obtain) a sponsor bank and BIN, network relationships, and the compliance program. The vendor is the issuer processor: APIs, authorization decisioning, card production hooks, and fraud tooling. You hold more regulatory and program responsibility. On this directory that shape includes Marqeta Powered By Marqeta, Lithic Processing (with Lithic’s Graduation Path as a described route toward a direct bank relationship while staying on Lithic processing), Galileo Direct Model (client contracts the sponsor bank; Galileo processes), and Stripe Issuing when you bring the BIN sponsor under Stripe’s processor-only posture. What you get: more control of bank relationship and program design on the same style of issuing API. What you do not get: a skip of bank diligence, a portable BIN you invent on this page, or production keys without a sales and bank path.

Processor-tied issuing. Card issuing is sold as a module on a payments or platform stack you already run (or are willing to standardize on). The vendor’s partner banks still issue. Access, funding, and often KYC sit inside that ecosystem. On this directory the clear adjacency is Stripe Issuing: commercial cards for business users on Stripe’s API, Stripe program management when Stripe supplies the issuing bank, processor-only when you bring the BIN sponsor, live platform access sales-led. Stripe publishes some Issuing line items (per-card and dispute fees on the listing) and still routes interchange revenue share through sales. What you get: issuing next to an existing Stripe money stack. What you do not get: a portable program you casually move off Stripe, a self-serve live start without use-case and bank-partner review, or a substitute for checkout acquiring.

Not this tree. Card acquiring and PayFac-as-a-service live on payments. Deposit accounts live on banking. Working capital lives on lending. Consumer checkout installment is a lending-branch job, not a spend-card program. If the job is only taking cards at checkout, do not force an issuing RFP.

There is no public volume number on this directory that tells you when to bring your own BIN, and no public month count that makes bank approval optional. Vendors will quote program timelines and minimums in a sales room. Those are commercial. This page will not invent a threshold.

BIN sponsor is the first honest question. Who holds the card-network range? Who is named as Issuer on the cardholder agreement? Managed paths introduce or supply that bank. Bring-your-own paths put your bank on the paper. Processor-tied paths name the vendor’s partner banks (or yours, if you bring the BIN). If you cannot get the Issuer named in one sentence, you do not have a pick yet. Read BIN sponsor and card issuing.

Diligence is the bank’s and the network’s, even when a program manager runs the API. KYB on businesses you board, KYC on cardholders where required, reserve funding, and program approval sit with policy the bank accepts. You can buy onboarding software and still not be the underwriter. Live cards on every listing on this table wait on a sales or bank path. Sandbox may be public (Marqeta, Lithic, Highnote). Sandbox may be request-only (Galileo). Production keys wait on contracting and bank due diligence on all of them.

Time-to-live is not a feature comparison. Nothing on the cards table is a self-serve charter or a self-serve live BIN. Vendor FAQs and guides cite weeks or months depending on product type and bank. Those are vendor claims, not Vert SLAs. This page does not print a month count. If a vendor will not say whether production waits on sales and a bank, believe the listing that already said sales-led.

Pricing posture. Most cards listings on this directory are not published for a usable platform buy rate or interchange share you can mark up from marketing alone. Stripe Issuing publishes some per-card and dispute fees and still puts interchange revenue share behind sales. Highnote’s pricing page marks Issuing Standard as Custom. Marqeta, Lithic, i2c, and Galileo do not publish a platform rate card on the surfaces used for those listings. Ask for fee schedule, interchange share, plastics, KYC, and dispute costs in writing. Do not invent APR-style math for spend cards from a blog.

What you actually own is usually the product UX, spend controls, branding, and a fee or interchange share under the program. You do not own the BIN on day one on a managed path. You do not own the issuing license unless you later become a principal issuer. Ask whether PANs and BINs port if you leave, who cardholders call on disputes, and what happens to open cards if you turn the program off.

Start here / Skip if

Start with a managed program manager if you want branded virtual and physical cards inside the product, you do not want the first conversation to be “we already have a BIN sponsor,” and you will still accept bank and network diligence through the vendor. Read Marqeta and Lithic as two managed-vs-powered forks on modern issuer-processor APIs (Marqeta vs Lithic). Read Highnote, Galileo, and i2c as additional program-manager / processor shapes on the live cards table. That is a fit check, not a rank.

Start with bring-your-own BIN if you already have (or will obtain) a sponsor bank and BIN, you want the processor to stay the API layer, and you will run more compliance and program ops yourself. Read Powered / Processing postures on Marqeta and Lithic, Galileo’s Direct Model, and Stripe Issuing’s processor-only path. Confirm the named bank on the cardholder agreement before you treat “API live” as “program live.”

Start with processor-tied issuing if the rest of the money stack is already on that processor and you want commercial cards for business users next to it. Read Stripe Issuing before you add a second issuing vendor. It is not portable by default. If you might leave that processor, prefer a standalone issuer-processor row.

Do not start by becoming the issuer. Skip that job if you cannot name a BIN sponsor, a compliance program, and the ops that will run disputes and monitoring. Skip a published buy rate this directory will not invent for opaque vendors. Skip this page if the job is only checkout acquiring, only deposit accounts, or only merchant working capital.

Live cards peers. Editorial fit only. Not a rank, not a buy order.

Marqeta: Managed By Marqeta or Powered By Marqeta. Partner-bank issuing API. Sales-led. Pricing not published.
Lithic: Program Managed or Processing. Optional Graduation Path. Sales-led. Pricing not published.
Stripe Issuing: Processor-tied commercial cards for business users. Some per-card fees published; interchange share via sales. Sales-led live access.
Highnote: Issuer processor and program manager with integrated ledger. Sandbox open. Live sales-led. Issuing Standard priced as Custom.
Galileo: Issuer processor; Direct or program-manager models. Sandbox request-only. Pricing not published.
i2c: Issuer processing for credit, debit, and prepaid with partner-bank / BIN-sponsor paths. Sales-led. Pricing not published.

Card issuing: Creating spend cards; the software company is typically not the licensed issuer.
BIN sponsor: Who holds the card-network range.
Know Your Business: Entity checks programs still require when you board businesses.
Marqeta vs Lithic: Head-to-head on managed vs bring-your-own forks for those two APIs.
The stack: Where cards sit after payments.
Cards: Full live table. Editorial order only.

FAQ

Does embedding card issuing make my company a bank?

No. The BIN sponsor / issuing bank is the Issuer on the cardholder agreement. You are a software platform or program marketer on that bank’s program. Confirm the named Issuer on the contract and on customer-facing card materials.

Should we start managed or bring our own BIN?

Depends on the job, not on a volume number this page will not invent. Managed is one integration and a vendor that already has bank programs. You still go through bank diligence, and you should ask what happens to cards if you leave. Bring-your-own BIN puts your bank on the paper and removes some program-manager layer. You still need a processor and you still do not own a charter by default. Processor-tied issuing is the third fork when the stack is already standardized on that processor.

Is card issuing the same as taking cards at checkout?

No. Issuing creates cards your users spend. Acquiring takes cards from their customers. Different license, different BIN, different hub (cards vs payments).

Why is pricing “not published” on so many cards listings?

Because most issuer processors keep platform buy rates and interchange share off marketing sites. Stripe Issuing publishes some per-card and dispute fees; interchange revenue share still goes through sales. Highnote marks Issuing Standard as Custom. Ask for the commercial stack in writing. Do not paste a blog fee into a board deck as if Vert certified it.

If we change processors, do the cards come with us?

Often no, unless the agreement and the bank program say the PAN/BIN relationship ports. Cards sit on a BIN under a bank program. Ask who disclosures name and what a migration actually remaps before you assume portability. This directory does not invent a migration path.