Acquiring Bank vs Issuing Bank: A Business Guide
Understanding the acquiring bank vs issuing bank distinction helps a business map the people and responsibilities behind a card transaction. The acquiring bank supports a merchant that accepts card payments; the issuing bank provides a card programme on behalf of the cardholder. Card networks connect the two sides, while programme managers and BIN sponsors can support businesses that want to launch branded cards. These are related roles, but they are not interchangeable.
For business buyers, getting the terms right matters when deciding whether a product needs merchant acceptance, card issuing, or both through separate arrangements. Intercash focuses on B2B card issuing infrastructure and programme management. It is not an acquiring bank and does not provide acquiring or payment processing services.
What is the difference between an acquiring bank and an issuing bank?
An acquiring bank, also called an acquirer, works on the merchant side of card acceptance. It enables a merchant to accept card payments and connects the merchant's transactions into the card-network process. The issuing bank, or issuer, is on the cardholder side. It issues or supports the payment card and handles the cardholder relationship and related account decisions.
A simple way to remember the distinction is to follow the two parties in a purchase:
- Merchant side:
the merchant accepts the card and works with an acquirer or other acquiring service provider.
- Cardholder side:
the customer uses a card provided by an issuer.
- Connection:
the relevant card network routes messages between participants under its operating rules.
In a typical card purchase, the merchant sends transaction information through its acceptance arrangements. The acquiring side forwards the authorization request through the card network to the issuer. The issuer decides whether to approve or decline based on its processes, and the response returns through the network. Later clearing and settlement processes account for the transaction between the participants. The exact operating arrangement depends on the programme and providers involved.
It helps to separate the stages rather than treat a card purchase as one action. First, the merchant accepts the card details and submits an authorization request through its acceptance provider. Next, the network carries that request to the issuer, which checks the account and applies its decision process. The approval or decline travels back through the same chain. If approved, the merchant can complete the sale; clearing and settlement follow under the parties' arrangements. A business launching cards should recognize that its issuing partner's role is on the cardholder side, even though the card may later be used at merchants supported by acquirers.
The U.S. General Services Administration describes a purchase-card flow in which the acquiring bank receives authorization from the issuing bank through a brand network. The Office of the Comptroller of the Currency's handbook also discusses operational risk in merchant processing, including settlement-related risks. These sources illustrate why the acquiring and issuing functions need to be understood as separate sides of the card ecosystem.
See the GSA SmartPay explanation of how a card transaction works and the OCC Comptroller's Handbook on merchant processing.
How do the roles fit into a card transaction?
Businesses often hear several terms together: merchant, cardholder, issuing bank, acquiring bank, network, BIN sponsor and programme manager. Each describes a different place in the ecosystem. The table summarises the usual distinction; specific contracts and operating models may allocate particular tasks differently.
Participant | Side or function | What the role generally covers | Business buyer's question |
Merchant | Accepts a payment | Sells goods or services and accepts card credentials from a buyer. | Do we need to accept cards from customers? |
Acquiring bank / acquirer | Merchant acceptance | Provides or supports the merchant's card acceptance relationship and routes transactions into the network process. | Who will enable our merchant acceptance and handle acquiring services? |
Card network | Connects participants | Provides network rules and transaction messaging between acquiring and issuing participants. | Which network access and programme arrangements apply? |
Issuing bank | Cardholder and card programme | Issues or supports the card and makes issuer-side decisions for card transactions. | Which licensed issuer and card programme model will support our product? |
BIN sponsor | Issuing programme access | Supports a business programme's access to card-network issuing arrangements through established relationships. | Can the programme use an existing issuing structure rather than seeking direct scheme membership? |
Programme manager | Programme operations | Coordinates operational elements of a card programme between the business, issuer and other service providers. | Who will coordinate setup, ongoing programme processes and oversight? |
Cardholder | Uses the issued card | Receives and uses the card product offered by the business programme. | What card experience will our own customers, employees or participants receive? |
The table is a starting point, not a substitute for reviewing the specific contractual model. A provider may perform several services, and the names used in a commercial agreement can differ. The important task is to identify who is responsible for each function, rather than assuming that one organisation fills every role.
Consider a purchase made with a company-issued card. The company may define who receives the card and how it fits its programme, while the issuing bank and programme partners support issuer-side operations. A separate retailer accepts the card through its own merchant arrangements. The retailer's acquirer and the cardholder's issuer each have a role in the transaction, even though the company that sponsored the card is neither party to the retail sale. This distinction is useful when mapping which organisation can answer a cardholder question versus a merchant acceptance question.
What does an acquiring bank do?
An acquiring bank supports a merchant's ability to accept card payments. It is commonly involved in the merchant acceptance relationship and the movement of transaction information through the card network. The merchant-facing focus is the key distinction: acquiring is about accepting card payments from customers, not creating a branded card product for a business's own users.
For a retailer, marketplace or service provider, acquiring questions might include whether the acceptance arrangement supports the business's sales channels, what transaction information is available for reconciliation, and how exceptions are handled. A business evaluating acquiring services should establish which party is the acquirer, which provider manages day-to-day merchant services, and which entity handles each operational issue.
For example, a merchant that sells through a website and in person should map the acceptance channels it needs to support. It can ask who receives transaction data, how the merchant gets records for reconciliation, where it directs an acceptance issue, and which party explains a transaction that was declined. These questions concern the merchant's acquiring arrangement. They are distinct from selecting a card programme for the merchant's own staff or customers.
Acquiring is not the same as issuing. A company may have a merchant account for its own sales and separately offer a card programme to employees, customers or platform participants. Those needs can involve different service providers, contracts and workflows. If the business only wants to issue its own branded cards, acquiring is not automatically the service it needs.
What does an issuing bank do?
An issuing bank sits on the cardholder side of the transaction. It issues or supports payment cards within an issuing arrangement and performs issuer-side functions, including responding to authorization requests. The cardholder may be an employee, customer, contractor, marketplace participant or another user who receives a card through a business programme.
A business launching cards does not necessarily become a bank or need to build every part of the issuing infrastructure itself. Depending on the model, a licensed issuing bank, network relationships, a BIN sponsor, a programme manager and technology providers each contribute defined parts. The business determines the product purpose and branded experience, while the participating providers' agreements establish the operating responsibilities.
Issuer-side planning begins with the intended user and purpose. A company could issue cards for employee expenses, a fintech could offer a branded card to its customers, or a platform could provide cards as part of a payout programme. Each case raises practical questions: who qualifies for a card, what experience the user sees, how programme records are reviewed, and where the business escalates an issue. The issuing bank remains distinct from the business whose brand appears on the card and from the merchant where the card is used.
Intercash is a B2B payment solutions provider focused on card issuing. It supports issuing infrastructure and programme management, rather than merchant acquiring. Its role should not be confused with that of the licensed issuing bank. Businesses can learn more about BIN sponsorship and how that function relates to a card programme.
Where do card networks, BIN sponsors and programme managers fit?
Card networks connect issuing and acquiring participants and set network rules for their programmes. A business launching a card product must understand how network access is provided and which parties take responsibility for network-facing requirements. Direct scheme membership is not the only way a business may participate in a card programme.
A BIN sponsor can support access to issuing arrangements using established relationships and ready BINs. A programme manager coordinates elements of the issuing programme, working among the business, licensed issuer and other participants. The precise scope varies, so buyers should ask for a clear responsibility map rather than rely on a role label alone.
Intercash operates as a BIN sponsor and programme manager for issuing programmes, with relationships that support access to Visa, Mastercard and Discover networks. It offers a turnkey approach to card issuing so businesses can avoid building the full issuing chain and supporting infrastructure in-house. That is distinct from acquiring merchant transactions.
In practical terms, the network is not the same as the bank that issues an individual card, and neither role is the same as the business programme's operational coordinator. For a buyer, this means reviewing how the pieces fit together: what issuer relationship supports the programme, how network access is arranged, which party coordinates programme operations, and what the business itself must manage. A clear answer should identify an accountable party for each function and explain how handoffs work when something needs attention.
For more background, read the guide to becoming a card issuer and how white-label card issuing works. These topics help clarify how a business can offer cards under its own brand while relying on specialist issuing infrastructure. Buyers can also compare B2B debit card issuing, virtual and physical card formats, white-label debit card programmes, mass payout APIs and corporate card programme planning.
Which model does a business need: acquiring, issuing or both?
Start with the business outcome, not the name of a provider. If the need is to take card payments from buyers, investigate merchant acceptance and acquiring. If the need is to give branded cards to customers, employees, contractors or programme participants, investigate card issuing. Some businesses need both capabilities, but they should evaluate them as distinct requirements.
- Define the use case.
Write down who will use the product, what the card is meant to do and whether the company must accept customer card payments as well.
- Map the transaction.
Identify who pays whom, where the card is used, and which side of the transaction the business needs to support.
- Separate services.
List merchant acceptance, issuing, payouts, programme operations and technology integration as distinct workstreams. Do not assume an issuing partner also provides acquiring.
- Identify accountable parties.
Ask which organisation is the licensed issuer, which entity sponsors the BIN, who manages the programme, and who provides any acquiring service if required.
- Check geography and product scope.
Confirm that the proposed arrangement supports the intended markets, card types, programme model and users.
- Review controls and integration.
Understand how onboarding, KYC/KYB, AML monitoring, PCI DSS responsibilities, fraud monitoring, reporting and APIs are addressed across the parties.
- Document handoffs.
Record who handles authorisation questions, cardholder support, reconciliation, exceptions and programme changes. Confirm how information flows between providers.
For example, a marketplace that wants to pay its participants with branded cards may be focused on issuing and payouts. A retailer that wants to accept shoppers' cards needs merchant acquiring. A company that sells to customers and also equips staff with expense cards may need to assess both, with separate service scopes. Intercash's focus is B2B card issuing and payout solutions, not pay-ins or merchant payment processing.
Use a short requirements note to make the distinction concrete. It can name the intended card users, the business purpose, any merchant acceptance need, the markets involved, and the systems that need to exchange information. Then ask each prospective provider to mark the items it covers, the items another party covers, and the items that remain with the business. This simple exercise makes gaps visible before implementation planning begins.
Related guides can help teams scope a specific programme: starting a white-label card programme, evaluating a card issuing platform, and understanding a cross-border payout API.
What should business buyers ask providers?
Use direct questions to avoid gaps between the sales description and the operating model. Ask each provider to distinguish its own responsibilities from those of its bank, network and technology partners.
Which legal entity is the issuing bank, and what is its role in the programme?
Who provides the BIN sponsorship and programme management, and what tasks fall within each scope?
Does this proposal include acquiring or merchant acceptance, or is it limited to card issuing and payouts?
Which card types and programme models can be supported, such as physical, virtual, gift, metallic or debit cards?
How are onboarding and KYC/KYB, AML monitoring, PCI DSS responsibilities and fraud monitoring addressed?
What systems, APIs and reports are available to connect the programme to our operations?
Who supports cardholders, and which support responsibilities remain with our business?
What markets and currencies are in scope, and which partner or entity supports each market?
How are responsibilities, escalation paths and service boundaries documented in the agreements?
Ask for answers in terms of a real event, not only a generic service description. For instance, if a cardholder reports that a transaction was declined, who receives the initial question and what information do they need to investigate? If a merchant asks about acceptance, is that handled by the cardholder's programme or the merchant's own provider? If a programme record does not match an internal report, which party supplies the relevant data and who coordinates resolution? These examples help expose handoffs that can be overlooked when teams discuss only the product features.
It can also help to distinguish launch responsibilities from ongoing responsibilities. During setup, teams may need to agree on the programme design, operational workflows, user communications, integration requirements and escalation paths. Once cards are in use, recurring work can include reviewing reports, handling support requests, monitoring programme activity and managing changes. The provider's role and the business's role should be clear at both stages, rather than assumed from the initial implementation plan.
These questions apply whether a business is an established financial institution, fintech, marketplace, employer or brand exploring a new card product. Industries listed for card programmes are examples, not a complete boundary on programme possibilities. Scope the business model first, then confirm that the proposed providers can support it.
Ready to discuss an issuing programme?
Once the business has separated its acquiring needs from its issuing goals, it can evaluate the right partners and operational structure. For businesses exploring branded cards and payouts, a focused conversation can clarify the issuing-side model, programme responsibilities and integration requirements.
Frequently asked questions
Can a business use the same provider for acquiring and issuing?
Sometimes a provider group may support services on both sides, but acquiring and issuing remain distinct functions. Confirm which legal entities and agreements provide each service, and do not infer acquiring coverage from an issuing proposal.
Is a BIN sponsor the same as an issuing bank?
No. A BIN sponsor supports a programme's access to issuing arrangements, while the issuing bank has the issuer role. Their responsibilities depend on the specific programme structure and agreements.
Does a company launching branded cards need to become an acquiring bank?
No. A business can offer cards to its own customers, employees or participants through an issuing programme without becoming an acquiring bank. The business should establish which issuer, sponsor and programme manager support the product.
Does Intercash provide acquiring or merchant payment processing?
No. Intercash focuses on B2B card issuing infrastructure, programme management and payout solutions. It does not provide acquiring, pay-ins or merchant payment processing.
Knowing which side of a card transaction your business needs to support is the first step toward choosing an appropriate programme structure and provider responsibilities.
