Read Client Stories
Lace Brunsden
Key Takeaways
- A fintech cannot issue cards by itself. A bank sponsors the BIN under its network license, and that bank keeps primary regulatory responsibility for every card carrying it.
- Pick the operating model before the vendor. A managed program hands program management to your processor. Processor only means you negotiate the bank, network, and vendor contracts yourself, keep more interchange, and wait longer to launch.
- Program manager describes a job, not a company. Read which of onboarding, servicing, disputes, and marketing the contract actually covers.
- Keep full card numbers out of your own systems. Tokenized issuing APIs leave most of the PCI DSS burden with the processor, while storing or displaying a PAN pulls your stack into scope.
- Budget four to twelve months for a first US program, with six to nine months the common outcome. Sponsor bank diligence and network registration, not code, usually set the pace.
- Walk away when the card does not change the product. Interchange alone rarely covers the support, disputes, and reconciliation load a program adds.
You want to put a card in your customers' hands, and every vendor you speak to says they can do that. So how do you decide?
What the pitches tend to leave out is that a card issuing program is mostly a set of contracts. The software is the smallest part of it.
Get that structure wrong, and you find out later when something happens, like when the bank's risk appetite caps a feature you have already shipped, interchange lands below what your model assumed, or a dispute arrives and nobody agreed who answers it.
Vendor titles make this harder rather than easier, because a title describes a market position rather than the obligations written into the agreement in front of you.
Four parties matter; one of them has to sponsor your BIN under its network license, and the operating model you pick decides how much of the rest you carry yourself.
Visa names a banking relationship, an issuer processor, and likely a program manager as the launch participants.
Let's go over each role and what it owes you, the two operating models, the compliance work that reaches your own engineers, and a responsibility map to take into partner conversations.
If that scoping work lands on an engineering team you have not hired yet, Trio places senior fintech engineers who have built card and ledger integrations before.
What is a card issuing program?
Offering cards and accepting card payments serve different product needs.
Issuing concerns the cards your intended users will spend with.
Acceptance concerns receiving customers’ card payments, such as at checkout.
That side of the transaction, embedded payments, involves different partners and a different build.
Let's think about a hypothetical US fintech that wants businesses to manage employee expense spending through branded cards. Its product idea includes the spending experience, requested controls, and information a business administrator needs.
Turning that idea into a program also requires answers about partner support, customer service, and ongoing operation.
The program brief should explain how the proposed service will work and which questions remain open.
Keep those operating questions visible while evaluating the product.
Do you actually need your own card program?
Start with the customer problem you expect the card to solve.
In the business-expense example, the founder might want administrators to manage spending within an existing workflow. Treat that as a product hypothesis to examine with intended customers.
Compare a custom program with using an existing card product.
If an available service meets the customer’s needs, document what a custom integration would add.
A specific missing workflow will give the investment a clearer purpose than a general wish to add financial features, and also make it easier to justify to shareholders.
Customer fit: Identify the spending problem and the people who experience it.
Product fit: Explain why cards belong inside your product and which existing alternative falls short.
Operating capacity: Name the internal people who can resolve product questions, coordinate partners, and oversee ongoing work.
Investment boundary: Separate what you need to investigate now from features you may consider later.
If the unresolved question concerns how businesses would use virtual cards, explore those virtual-card use cases before committing to an issuing project.
If the customer problem remains vague, focused product discovery may be the more useful next step.
Who does what in a card issuing program?
As we have already mentioned, four roles sit behind every US card program, and one vendor may hold several of them.
What matters is which obligations your contract names, because anything it leaves out stays with you.
1. Issuing bank, your BIN sponsor
The bank holds network membership and sponsors the Bank Identification Number your cards carry.
Column's participant explanation puts oversight of program policies and procedures, plus daily settlement with the networks, on the bank.
The bank also keeps primary responsibility for customer identification, due diligence, transaction monitoring, sanctions screening, and suspicious activity reporting.
In some cases, you may perform that work under contract, but you cannot move it off the bank's books, which is why bank diligence runs long and why product changes often need bank review before they ship.
2. Issuer processor
The processor connects to the networks, authorizes transactions in real time, and passes messages to whoever runs the program.
Your engineers will spend most of their integration time here: card creation, spend controls, webhook delivery, and the clearing and settlement files you reconcile against.
Ask which systems you connect to directly, what the sandbox covers, and where processor support stops.
3. Program manager
Program management covers the daily work: onboarding, card servicing, disputes, customer support, and marketing review.
Someone needs to perform these tasks either way, but a managed arrangement puts it with your processor or a third party, while running it yourself keeps more interchange along with more headcount.
Ask which activities the proposal names. Treat anything unnamed as yours.
4. Card network
Visa and Mastercard set the operating rules, route transactions, and publish the interchange schedule.
You rarely contract with them directly, since direct membership generally means holding a banking license, meeting capital requirements, passing network certification, and staffing the operations that go with all of it.
Network rules still reach you through the bank's agreement.
Regulation II, the Durbin rule, requires every US debit and prepaid card to enable at least two unaffiliated networks so merchants can choose how to route, and it caps interchange for issuers holding more than $10 billion in assets.
Smaller sponsor banks probably sit outside that cap, which seems to be one reason so many US debit programs end up with them.
Do you need a BIN sponsor to issue cards?
There is almost no way for a fintech to issue cards without a sponsoring bank, because the BIN attaches to that bank's network membership.
The only way around is to become a bank yourself, which is expensive and often unrealistic.
Almost every US fintech card starts on a sponsor's BIN rather than one of its own.
Shared or dedicated matters more than founders expect.
A shared BIN sitting under a platform launches faster and costs less to set up, while a dedicated BIN gives you more control over card design and routing, and leaving a shared BIN later means reissuing every card in the field.
Get the service boundaries in writing: Request a list of participating organizations, included work, exclusions, dependencies and escalation contacts. Keep unconfirmed responsibilities open until the relevant documentation or agreement resolves them.
Should you pick a managed program or processor only?
Two arrangements cover most first programs, and the choice shapes your headcount more than it shapes your code.
A managed program puts your processor, or a partner it works with, in the program manager seat.
The processor acquires the BIN range, holds the bank and network relationships, and you integrate against one API.
It seems to be the normal starting point, and it suits a first program, a low-volume experiment, or a small team.
Processor-only means you negotiate the bank, network, and vendor agreements yourself, then secure your own BIN once they are signed.
You keep more interchange and real control over pricing and partners. You also absorb card production, compliance tooling, and the coordination a program manager would otherwise do, and you launch later.
Starting managed and moving to your own BIN later is a common path and probably the most realistic financially.
Budget for the reissue, because cards sitting on a shared BIN have to be replaced when the BIN changes.
Which card issuing platforms should you shortlist?
The shortlist gets shorter once you know which category a vendor sits in, because the category tells you what you still have to go and find somewhere else.
Six groups cover almost every option a US team gets shown. One vendor can sit in two of them, and several have moved between groups, so check the current arrangement rather than a comparison post from last year. Galileo, for one, now trades as SoFi Tech Solutions.
Pure-play issuer processors. Marqeta, Lithic, Highnote, and Qolo. You get network connectivity, authorization, and the card lifecycle APIs your engineers build against. You still source a sponsor bank yourself, plus program management, unless the processor bundles it.
Banking-as-a-service platforms. Unit, Treasury Prime and Synctera. The sponsor bank relationship and much of the program management arrive bundled, which is why first programs often start here. You give up pricing control, and you face a migration if you outgrow the arrangement.
Banks and bank-owned infrastructure. Column, Cross River, Increase, Green Dot and Pathward. Sponsorship comes straight from the chartered entity rather than through an intermediary. How much processing and program management comes with it varies widely between them.
Enterprise and legacy processors. Fiserv, i2c, CoreCard and Q2. These carry credit programs and portfolios at a scale the newer platforms generally do not, and they are what most incumbent banks already run on. Implementations take longer.
Full-stack payment processors. Stripe Issuing and Adyen. Issuing sits beside acceptance on one contract, which suits a team already running payments there. Stripe Issuing cards are issued by Stripe's bank partners, so the sponsorship question is answered for you, with less room to negotiate it.
International specialists. Thredd, Paymentology and Wallester are worth a look when the program is not US-only. Wallester markets BIN sponsorship directly, and Thredd makes introductions through its own sponsor network.
Six names come up most often for a first US program. Each one below says what you still have to bring, since that tends to set the timeline more than any feature does.
Published pricing stays thin across all six, so program economics will come out of a conversation rather than a rate card. Ask for the interchange split, the per-card and per-transaction fees, and any monthly minimum in the same email.
Two questions sort that list faster than any feature grid. Does the vendor bring a sponsor bank, or expect you to arrive with one? And does the contract name program management, or leave it sitting unassigned?
Marqeta
We recommend that you start here if you want to try the API before talking to anyone.
Marqeta publishes a public sandbox you create yourself, and its Core API models a program as cards, users, funding sources, and fund loads, which maps onto most spend products without much translation.
Private sandboxes come later, once you are a customer.
What the docs leave open is the bank, so ask early whether the sponsor relationship is one Marqeta brings or one you hold.
Lithic
Lithic states the managed versus processor-only choice more plainly than anyone else here, which helps while you are still deciding.
Processor Client means you own the bank relationship.
Lithic Program Management means Lithic carries the bank, network, and compliance work instead.
Balances sit in native Financial Accounts on an immutable double-entry ledger, and the sandbox simulates authorizations, clearing, and webhook events, so your reconciliation logic can be tested before a real card exists.
While it's a great option in specific circumstances, you need to keep in mind that Lithic itself is a fintech, not a bank.
Highnote
Highnote runs on a single GraphQL API over one core ledger.
This quickly becomes an architecture decision, since your team writes queries instead of REST calls, which changes how the integration gets built and tested.
Debit, credit, prepaid, fleet, and virtual programs are all supported, and cards can be physical, virtual, or tokenized.
On sponsorship, Highnote's own site says it operates under a bank sponsorship model while it pursues licenses of its own, so confirm which partner sits behind your program.
Unit
Unit suits a team that wants accounts and cards from one place, with deposit accounts, credit accounts and cards on a single native ledger.
The bank relationship arrives bundled, which takes a negotiation off your critical path, and also means you do not pick the bank.
Unit describes itself as a financial technology company and not a bank, and says banking services come from its bank partners without naming them publicly, so get the specific institution and its risk appetite in writing before you design anything that depends on either.
Column
Column takes out a contract and a hand-off, because the bank and the processor are the same company.
Column N.A. is a nationally chartered bank, Member FDIC, that built its own core and ledger, and it supports debit, credit, charge, secured, and unsecured programs.
The docs expose card programs, card accounts, authorization policies, and card tokens directly, and sandbox signup is self-serve.
What is interesting here is that they allow you to bring your own balance sheet or use theirs. Consider this carefully, since that choice shapes your funding model more than any API will.
Stripe Issuing
Stripe answers the sponsorship question in public, which almost nobody else does. Its own disclosures name the issuing banks: Celtic, Lead, Fifth Third and Cross River for commercial charge cards, and Sutton, Lead and Cross River for commercial prepaid and debit.
Stripe will act as program manager, or as processor only if you keep your own banking relationships and licenses.
One limit to check against your roadmap is that commercial issuing covers the US, Canada, the UK, and supported EEA countries, while consumer issuing stays US-only.
What should you prepare before approaching partners?
Give prospective partners a specific proposal to assess.
For example, “We want branded cards” leaves too much open. Instead, you need to describe the intended customer, spending use case, proposed card model, and US market scope.
Mark assumptions wherever you still need advice or confirmation.
For the hypothetical expense product, the founder could describe business administrators managing employee spending, with no credit feature or international expansion proposed.
The funding arrangement still remains an open question. These boundaries focus partner discussions without implying that the final product has been approved.
Describe who will use and administer the cards.
Explain the spending workflow and proposed physical or virtual card experience.
Separate requested features from confirmed partner capabilities.
Identify unresolved funding, eligibility, and product-model questions.
Ask partners and counsel which requirements apply to the proposed arrangement.
Revise the brief as partner responses arrive. Keep a requested feature marked as an assumption until the relevant party confirms support and conditions.
Keep broader financial-product ideas in a separate track, because embedded finance raises its own partner and regulatory questions.
How do you plan a card program launch?
Connect each stage to evidence: a product brief, written partner responses, documented ownership questions, an integration scope, and agreed readiness requirements.
The following sequence is a proposed planning approach, subject to your selected partners and agreements.
Write the product brief: Record the customer problem, intended users, US scope, requested capabilities, and unresolved assumptions. Verify that the founder and product lead agree on the proposed first release.
Establish partner fit: Share the same brief with prospective partners. Obtain written responses about supported scope, participating organizations, exclusions, and further review requirements.
Clarify agreements and ownership: Ask partners and counsel to resolve responsibility questions. Record agreement references where available and maintain an open-questions register.
Bound the integration work: Ask engineering to distinguish partner-provided functionality from proposed product interfaces, internal tools, and ongoing maintenance. Identify dependencies before requesting a build estimate.
Review readiness and ongoing operation: Agree with partners on the evidence required before launch. Name internal contacts for unresolved issues, operating reviews, and future integration changes.
The agreement stage deserves deliberate attention.
In its October 12, 2026 guidance, Venable recommends explicitly allocating operational responsibilities, compliance obligations, risk, and liability among the parties. Use that recommendation to frame questions about your arrangement.
How long does it take to launch a card program?
Four to twelve months covers most first US programs, and six to nine months describes the typical one.
Sponsor bank selection and diligence alone often takes four to twelve weeks. The integration rarely sits on the critical path, which we find often surprises teams who budgeted for a card program as an engineering project.
Who owns what after launch?
Clarify each major workstream before launch: onboarding, card servicing, transaction decisions, disputes, financial reporting and reconciliation.
For each one, ask each partner to define what they directly perform, what you retain, and what documentation (from the contract, service schedule, or workflow guide) specifies the operating responsibility.
The map below is a planning aid, conditional on US product scope, contracts, and partner arrangements. Its internal owners are suggested people to lead questions and decisions.
Contractual accountability, compliance duties, and liability remain unassigned until confirmed.
Workstream | Question for prospective partners | Proposed internal decision owner | Evidence to obtain |
|---|---|---|---|
Onboarding | Who collects information, reviews it, and communicates outstanding requirements? | Product or operations lead | Written workflow, required inputs and escalation contacts |
Card servicing | Who handles card changes, freeze requests, replacements, and customer communication? | Customer operations lead | Service scope, supported actions and responsibility boundaries |
Authorization decisions | Who sets spending rules, makes transaction decisions, and handles exceptions? | Product lead with engineering | Documented decision boundaries and supported controls |
Disputes | Who receives disputes, gathers information, communicates updates, and performs each next action? | Operations lead | Agreed workflow, applicable deadlines, and escalation route |
Reporting | Which reports are available, who can access them, and who responds to reporting requests? | Finance or operations lead | Report examples, access terms, and named contacts |
Reconciliation | Which records will be compared, who investigates differences, and who confirms resolution? | Finance lead with engineering | Available records, proposed matching approach, and exception ownership |
Integration maintenance | Who monitors service changes, updates the integration, and coordinates releases? | Engineering lead | Change process, support boundaries, and maintenance scope |
Reconciliation requires you to compare relevant records and investigate differences.
Before scoping that work, ask what records partners provide and which internal team would review unresolved items.
Which compliance work reaches your engineers?
Most compliance obligations sit with the bank, and three of them still turn into code on your side.
PCI DSS scope
Keep full card numbers out of your systems, and your PCI DSS scope stays small. Issuing processors expose a card token for normal operations, so your servers never hold the primary account number.
Scope grows the moment you decide to show a cardholder their own number or CVV inside your interface.
Most teams solve that with an iframe or hosted element served by the processor, so the sensitive values render in the browser and never touch your backend.
Decide this early, because retrofitting the pattern costs far more than building it.
KYC and customer identification
Your bank owns the customer identification program and tells you what it needs collected. Your engineers build the collection and the evidence trail: identity fields, document upload, retry handling, audit logging, and a clean way to re-run a check when a case gets escalated.
Expect the bank to review that flow before launch, and expect at least one round of changes.
Network routing rules
Debit and prepaid cards carry the Regulation II routing requirement, so your BIN has to run on two unaffiliated networks.
Your bank and processor usually configure that rather than your team, though it still reaches your testing, since a transaction can arrive over either network and your reconciliation has to handle both.
When is a card program the wrong move?
Plenty of fintechs would be better off not issuing. Four patterns show up often enough to check yourself against.
The card does not change the product: If cardholders could use any existing card and get the same outcome, a program adds support volume, disputes, and reconciliation without adding retention.
Interchange is the whole business case: Interchange on a small US debit program rarely covers program fees, card production, support headcount, and the engineering time to keep an integration current. Revenue that depends on volume you have not reached yet is a forecast, not a plan.
Nobody owns operations: A card program generates work every day: stuck authorizations, lost cards, disputes with deadlines, settlement breaks. Without a named owner, that work lands on whoever answers first, usually an engineer.
The timeline does not fit the runway: Four to twelve months of partner work before meaningful revenue reads differently at eighteen months of runway than at six.
An existing card product, a payout rail, or a reimbursement flow solves a surprising share of the problems founders reach for cards to fix. Worth testing before you commit.
Are you ready for engineering discovery?
Only proceed to scoped engineering discovery after the major dependencies (meaning partner support, product fit, and ownership boundaries) have credible written answers.
You can use the readiness checks below to surface what still needs validation from product, partners, or internal operations before you ask engineers to estimate or build.
Define the customer problem: Verify that the written use-case brief explains the intended user, spending need, and reason for considering a custom program.
Document partner fit: Retain written responses identifying supported scope, participating functions, exclusions, and unresolved reviews.
Expose ownership gaps: Give each open responsibility question a named internal contact and record the partner or agreement evidence needed to resolve it.
Assess operating capacity: Ask proposed internal owners to review their expected work and flag missing capacity or unclear authority.
Bound engineering discovery: List the workflows to investigate, partner documentation required, assumptions to test, and questions outside engineering.
Pause the build commitment if a central dependency remains unanswered, such as whether the proposed product fits the partner arrangement. Continue the specific investigation needed to resolve it.
What to bring to your next partner conversation
Assemble the use case, US market scope, prospective partners, responsibility map, and engineering unknowns into one concise brief.
Ask the relevant partners to review the assumptions before using it to scope integration work.
When the brief identifies a concrete software need, our fintech engineering teams can assist you.
To find out more, or to start the hiring process, request a consult.