Launching a new card program creates a classic chicken-and-egg problem: Should you approach the issuing bank first or the processor first?
There is no universal answer.
The right partner to approach first depends on what is most likely to constrain your program.
- If risk, compliance, the customer base, geography, or an unusual product structure could prevent the program from being approved, start with the issuing bank.
- If the program is relatively conventional but depends on specialized technology or functionality, start with the processor.
Define the Program Before You Start Shopping
Before approaching either an issuing bank or processor, you need a coherent description of the program.
You do not need every fee, transaction limit, or operational detail finalized. But your potential partners should be able to understand the opportunity without spending multiple sales calls helping you figure out your own business model.
At a minimum, you should be prepared to explain:
- Who the customer is
- What problem the product solves
- Where customers will be located
- How customers will find and enroll in the program
- Which features are required at launch
- Which features are planned for later
- How money moves through the product
- Who will handle customer service, fraud, disputes, reconciliation, complaints, and compliance
- What your expected cardholder and transaction volumes look like
- What experience your team has operating a payments program
Approaching banks and processors before defining the program is like interviewing candidates before writing the job description.
You may hear good answers, but you will not have a consistent way to compare them.
Define the role first: what the program needs, what responsibilities the partner must take on, and which capabilities are non-negotiable.
Once those requirements are clear, you can evaluate each issuing bank and processor against the same standard instead of allowing each sales conversation to shape the program in a different direction.
Start With the Issuing Bank When Risk Is the Constraint
The issuing bank should usually be your first serious conversation when the program has characteristics that may fall outside a bank's normal risk appetite.
Examples of higher-risk programs:
- Cryptocurrency-related products
- Gaming/Gambling
- International money movement
- Non-U.S. customers
- High transaction or account limits
- Novel funding methods
- Unusual customer groups
- New business models without an established operating history
The processor may technically be able to support the product, but that does not mean the issuing bank will allow it.
That point of difference is critical.
Imagine you want to launch a debit program for affluent customers with cryptocurrency rewards and a $30,000 purchase limit.
A processor may tell you:
Yes, our system can support a $30,000 daily purchase limit.
That answers only the technology question.
The issuing bank still has to determine whether it is willing to accept the regulatory, fraud, financial, and reputational risks associated with the program.
The bank may want to understand:
- Who the customers are
- How they are verified
- Where funds originate
- How transactions are monitored
- What fraud controls exist
- How the cryptocurrency component works
- Why the higher limit is necessary
- How complaints and disputes will be managed
A technically feasible program is not necessarily an approvable program.
The Issuing Bank Controls More Than the Card
The issuing bank is not simply another vendor in the implementation.
It is the financial institution responsible for sponsoring the program and overseeing the regulatory risks associated with it.
Depending on the program, the bank may approve or heavily influence:
- Customer eligibility
- Geographic scope
- Transaction limits
- Account limits
- Credit limits
- Credit eligibility
- Fees
- Cardholder agreements
- Disclosures
- Marketing language
- Compliance policies
- Information-security requirements
- Identity-verification processes
- Sanctions screening
- Fraud controls
- Complaint management
- Dispute processes
- Vendors and subcontractors
- Final authorization to launch
The exact requirements vary by issuing bank.
That is why a higher-risk program should not assume that processor capability equals bank approval.
Start With the Processor When Technology Is the Constraint
The processor should generally come first when the product is relatively conventional but depends on a technical capability that is not universally available.
For example, you might be launching a fairly standard payroll, gift, debit, or general-purpose reloadable product, but your customer experience requires:
- A specific API
- Real-time transaction controls
- A particular digital-wallet capability
- Push-to-card functionality
- Custom transaction limits
- Virtual-card issuance
- Unique account structures
- Specialized reporting
- Particular customer-service tools
- A feature that only certain processors support
In this situation, it makes sense to determine whether the processor can support the product before spending months negotiating with an issuing bank.
The processor's primary question is:
Can the system do this?
The issuing bank's question is:
Will we allow this program to do it, and under what controls?
Those are different questions.
Be Careful When a Processor Says “Yes”
One of the easiest mistakes to make during processor selection is assuming that a salesperson's “yes” means the functionality is available today.
A feature may be:
- Already available through configuration
- Available only through a specific workflow
- Available through another vendor
- On the processor's future roadmap
- Available only through paid custom development
- Dependent on issuing-bank approval
- Dependent on network certification
Those distinctions can completely change your launch timeline and budget.
If a feature is critical to your product, ask for evidence.
That may include:
- A live demonstration
- API documentation
- Technical specifications
- A test environment
- References from programs already using the feature
- Written confirmation in the implementation documentation
- Contract language where appropriate
A roadmap-critical feature should not depend on a vague verbal assurance made during a sales call.
You Will Usually Talk to Both Partners Early
Choosing which partner comes first does not mean ignoring the other.
Bank and processor discussions frequently overlap.
For example, a higher-risk program might:
- Begin issuing-bank due diligence
- Simultaneously evaluate several processors
- Negotiate processor pricing
- Review APIs
- Request demonstrations
- Test a processor sandbox
The important distinction is between evaluating a partner and committing to the partner.
If bank approval remains uncertain, you may not want to execute a processor agreement that immediately begins implementation fees or monthly minimums.
Likewise, if your entire product depends on a processor capability that has not been verified, you may not want to complete a lengthy bank negotiation around a product that cannot actually be built.
Do Not Start With the Card Network
Founders sometimes assume that Visa, Mastercard, or another payment network should be the first call because the network's logo will ultimately appear on the card.
That is never the most efficient starting point.
The issuing bank and processor typically already maintain the direct operating relationships with the payment networks. Those partners understand the applicable network rules, certifications, and approval processes.
The network remains important throughout the launch, particularly for areas such as:
- Card design
- Brand usage
- Network rules
- Certain approvals and certifications
But for most new programs, the immediate question is not:
Which network should we call?
It is:
Can we find an issuing bank willing to sponsor this program and a processor capable of operating it? If so, what networks are they contracted with?
Use the Biggest Constraint to Decide Who Goes First
The simplest way to determine your starting point is to identify what could kill the program.
Ask:
What is the biggest unresolved question about this product?
If the question sounds like:
- Will a bank approve this?
- Will the bank accept these customers?
- Will the bank permit these transaction limits?
- Will the bank accept this funding method?
- Will the bank support this country or geography?
Start with the issuing bank.
If the question sounds like:
- Can the platform support this feature?
- Does the processor have this API?
- Can transactions be controlled this way?
- Can the processor support this account structure?
- Can the processor integrate with our existing systems?
Start with the processor.
That approach prevents you from spending time solving the wrong problem first.
A Practical Starting Sequence
For most new U.S. card programs, the early process should look something like this:
- Define the customer, product, features, operating model, and roadmap.
- Build an initial financial and volume model.
- Document the program clearly enough that a partner can evaluate it.
- Identify the biggest constraint: bank risk appetite or processor technology.
- Approach the partner most capable of answering that question first.
- Begin evaluating the other partner shortly afterward.
- Verify critical capabilities rather than relying on sales statements.
- Understand which approvals and dependencies must be completed before contracts begin generating costs.
The process will rarely be perfectly linear.
That is normal.
The goal is not to create a perfect sequence. The goal is to prevent your team from spending money, months of implementation time, and credibility on a program that one critical partner cannot support.
The Bottom Line
Do not choose an issuing bank first simply because someone told you that is the correct order.
Do not choose the processor first simply because technology feels like the most tangible part of the product.
Start with the partner that controls your biggest unknown.
If risk is the constraint, start with the issuing bank.
If technology is the constraint, start with the processor.
And before approaching either one, make sure you can clearly explain what you are actually asking them to help you build.