What Is Card Issuing? How It Works and How to Choose a Platform

Key takeaways

• Card issuing creates and manages payment cards, including payment authorizations.
• Choose whether to launch your own card program or use cards from an existing program.
• This guide covers HaiPay's USD virtual cards and API for business spending.
• This guide helps you choose a path, compare platforms and check dashboard and API capabilities.

Two paths: launch your own program or use an existing one

Decide whether to operate a card program for customers or employees, or use cards from an existing program.

Choose whether to operate a program or use an existing one; customer versus employee is not the dividing line.

Cards for your company's spending

Use this path when your team needs to pay ad platforms, software subscriptions or suppliers. You use cards from an existing program and manage them through a dashboard or, where available, an API connected to your software.

Start with the work your team needs to do: create cards, control spending, investigate failed payments and match purchases to projects. Confirm the provider's application requirements and your ongoing duties in the agreement.

HaiPay fits this path with USD virtual cards and an API. Its offer in this guide covers company spending. For a customer card program, use the partner and responsibility questions below. The platform checklist and the later HaiPay task list show what to verify before choosing a service.

Your own card program

Use this path when you need to operate a card program for customers or employees, such as for a fintech app, marketplace or internal spending program. You need to plan onboarding, cardholder support, program rules and your share of compliance work. Branding is only one part of that decision.

Compare three ways to run the program:

• Become the issuer. An institution with the required issuing permissions and network membership for that market and card type can operate the program, using an outside processor if needed. This involves responsibility for the program and its compliance.
• Arrange a sponsor and processor. A licensed partner provides the issuing relationship. Your team builds the product and agrees who runs the ledger, authorization logic and daily operations.
• Use a bundled platform. A program manager can arrange the issuer and processing relationships. Your team still needs clear responsibilities for the product, compliance and operations.

In a bank-sponsored program, BIN sponsorship lets a business offer branded cards under the bank's license and network relationship. The bank identification number, or BIN, is the prefix of the card number that identifies its issuing institution. The bank retains oversight of the sponsored program.

The ledger records balances, while authorization logic determines how payment requests are assessed. Decide which of these your team needs to control before comparing partners.

The legal issuer and permissions depend on the country and program. Ask which institution stands behind the cards in each market, who contracts with it and what your team must operate. Do not choose a model from the API feature list alone.

How a card gets issued

For a business launching its own card program, setup typically includes these activities; the exact sequence varies. Businesses using an existing program follow its application and card-creation process.

1. Agree the card type, controls and operating model with the issuing partners.
2. Arrange the program's BIN and the required approvals.
3. Complete the identity checks required for the program and any credit assessment required for the credit applicant.
4. Create the card credentials, connect the account or balance, and configure spending rules.
5. Deliver the card digitally, or produce and distribute a physical card.

How card issuing and payments work

Who does what

Common roles include the following; a separate program manager is optional, and one organization may perform more than one role:

• Issuer: For the network cards covered here, the bank or other licensed institution behind the cards. It manages cardholder accounts and approves or declines transactions.
• Card network: Connects issuers, acquirers and merchants, and sets network rules. Visa operates a payments network. Mastercard is also a network.
• Issuer processor: Handles authorization messages, card status and transaction records on the issuing side.
• Program manager: Runs daily program operations and may arrange the issuer, processor, dashboard, API and support.
• Cardholder: The person or business using the card.

The issuing bank and the platform are separate roles, even when one provider bundles the services. Confirm who performs each role for your proposed program.

The five-step payment flow

In a typical online authorization and payment flow, the request travels from the cardholder through the merchant's acquirer and network to the issuer, with clearing and settlement following authorization.

1. The cardholder pays. They tap, swipe or enter card details.
2. The acquirer sends the request. The merchant's payment provider passes an authorization request to the network.
3. The network routes it. The request reaches the issuing side.
4. The issuing side decides. The issuer or a party acting on its behalf checks applicable funds or credit, account status, security and card controls, then returns an approval or decline.
5. Clearing and settlement follow. If the payment proceeds, transaction details are exchanged and funds move later.

In this flow, issuer-side card controls are checked at step 4. A spending limit or merchant restriction can stop a payment at authorization. Approval does not mean the payment has settled. See card payment clearing for the distinction between exchanging transaction details and moving funds.

In this typical online flow, the issuing side returns an approval or decline; clearing and settlement are separate later stages.

When a payment fails, check both sides. Insufficient funds, a card limit, a merchant restriction or fraud checks can cause an issuer decline. Also check whether the merchant's payment setup supports the card type. Ask what decline reasons and alerts your team can see before choosing a platform.

Our credit card decline codes guide explains common codes from the merchant's side.

Responsibilities beyond payment approval

A live program also needs fraud monitoring, dispute handling, cardholder support and compliance work. Identity verification is part of know your customer, or KYC, checks. Anti-money laundering, or AML, monitoring looks for suspicious activity.

A platform may run daily tasks, but the licensed issuer retains responsibility to regulators and networks. Agree who investigates fraud, handles disputes, supports cardholders and monitors compliance. Make the escalation route part of the operating agreement.

Issuing vs acquiring: Issuing serves the cardholder by providing cards and approving payments. Acquiring serves the merchant by enabling card acceptance and receipt of funds. If you want to accept payments from buyers, start with our merchant acquiring guide.

Types of cards a business can issue

The main card types differ in how spending is funded.

A prepaid card does not require a linked bank account. These are general card categories, separate from the specific product details later in this guide.

Three other choices describe who uses the card and how:

• Consumer or commercial: Cards for individuals or for business uses such as expenses, fleet spending and supplier payments.
• Physical or virtual: A virtual card exists only in digital form, with a card number, expiry date and card verification value, or CVV.
• Single-use or reusable: A single-use card is intended for one transaction; a reusable card supports repeated payments.

Keep these choices separate in your brief. Name the intended cardholder, what they will pay for and whether you need digital or physical delivery. Then ask the provider which combinations its program offers.

What is a card issuing platform?

A card issuing platform is software a business uses to create and manage cards. It may bundle issuer and processor relationships, but the included services depend on the provider.

A platform can provide a dashboard for your team and an API for your software, connecting them to card management tools, transaction records, a processor and a licensed issuer.

A platform can connect interfaces and card tools to issuing partners; confirm the included scope rather than assuming every task is available.

An application programming interface, or API, lets your software perform supported card tasks. A dashboard lets people perform tasks directly. Compare the two separately: an action available in the dashboard may not be available through the API. Look for four functional areas:

• Creation: Setting up cards through the dashboard, API or both.
• Controls: Spending limits, merchant restrictions, freezing and closing cards.
• Records: Transactions, alerts and exports for investigation and reconciliation.
• Partners: The issuer and processor, whether included or arranged separately.

Card issuing as a service

Card issuing as a service, also called card as a service or CaaS, describes a provider supplying or arranging card program infrastructure. That can include creation, processing and an issuer relationship, accessed through a dashboard or API.

Treat CaaS as a description of the delivery model. Ask for the contracted scope: applicant review, card management, processing, compliance, fraud checks, support and disputes. Mark each task as the provider's, another partner's or your team's responsibility.

How to choose a card issuing platform

Use the following checklist to turn a feature list into a decision. Ask for answers in writing, then request a demonstration using the interface your team will use.

Start with eligibility, acceptance and cost

• Which business types and countries can apply? Check your company's registration country separately from the card program's region and the places where you plan to spend.
• Which networks, currencies and card formats are available? Specify virtual or physical cards and ask how charges in other currencies are handled.
• Will your intended merchants accept the cards? Name the merchants you plan to pay and ask how those payments have been handled. Do not treat a use-case label as confirmation of acceptance.
• What are the fees and commercial terms? Request setup fees, recurring charges, minimum commitments, card costs, transaction costs and currency conversion pricing in one written proposal.

For company spending, test controls and records

• Which controls exist, and where? Check spending limits, merchant locks, freezing and closing. Record whether each task is available in the dashboard, API or both.
• What records and alerts do you get, including for declines? Ask to see a transaction record, a failure alert and an export. Have finance identify the fields needed to match spending to a purchase or project.
• Who handles disputes, refunds and fraud checks? Agree the contact route and responsibilities before signing. Ask what information your team can see while a payment issue is investigated.

For your own card program, confirm the partners

• Does the provider bring the issuing bank, or do you arrange one? Identify the legal issuer and processor, and confirm which relationships your contract includes.
• Who runs the program? Assign applicant review, identity checks, fraud monitoring, disputes and cardholder support. Confirm what your team must supply and what remains with the licensed issuer.
• Who controls the ledger and authorization logic? Ask which decisions your software can make and which stay with the provider. Match that division to the operating model you intend to run.

For API integration, verify the actual workflow

• What does the API cover, and how do you test it? Request the supported action list, documentation and a sandbox. Confirm how test access is granted. A dashboard demo is not evidence of an API action.
• How do records reach your software? Ask about transaction queries, webhook notifications and the meaning of returned statuses. Request details of authentication, permissions, duplicate requests, webhook verification, retries and error recovery.
• What security checks apply? EMV 3-D Secure authenticates consumers for online card payments. Ask about its implementation and address verification. PCI DSS provides baseline security requirements for payment account data; ask how responsibilities apply to your integration.

These are evaluation questions, not claims about any provider's API. Request documentation or a demonstration for the actions your workflow depends on. Record anything still unconfirmed before deciding whether to proceed.

Run a short demonstration

Ask the provider to create a card through the interface you will use, apply your intended controls, run a test payment and show its transaction record. Agree an appropriate test environment and any costs first. Then have your finance team match that record to a purchase without help.

Include a failed payment in the walkthrough. Ask which reason is visible, where an alert appears and who investigates it. Use the same checklist for every provider so a strong demonstration in one area does not hide a missing requirement elsewhere.

A useful demonstration tests a payment and its record, not just card creation; agree the test environment and costs before starting.

Give each participant a specific job during the demonstration:

• Operations: Choose a card for a real spending use case, apply the intended limit or merchant restriction, run a test payment, then locate its transaction record. Ask to repeat the relevant step after freezing the card.
• Development: Request the same card action through the API, run a test payment, then retrieve its transaction data through the documented query or notification workflow. List any step that requires a person in the dashboard. Ask how your software should handle a failed request.
• Finance: Take the transaction export and match a purchase to the relevant team or project. Check whether the record contains the information your reconciliation process needs, without relying on the provider to explain every entry.

Keep a decision record with the requirement, the demonstrated result and any unresolved question. Ask the provider to confirm missing details in writing. For your own card program, add the responsible partner beside each operational task.

If a requirement your workflow depends on stays unconfirmed, keep the decision open. Before the call, send a short brief:

We are registered in [country] and need cards for [payments], used by [teams]. Our software must [create cards, lock cards, read transactions]. Our team will [set limits, close cards] in the dashboard. Finance needs [fields] to match each purchase to [project]. Please confirm we qualify and show each step.

Where HaiPay fits

HaiPay publishes this guide and sells the business virtual cards described here. Its card issuing offering is USD virtual cards for business spending, with an API for teams using their own systems.

Programs and eligibility

• Three programs: US, Hong Kong and Singapore. Each offers Visa and Mastercard cards, all in USD. The program names are labels for the card programs, not a list of countries that can apply.
• Card options: Reusable and single-use cards are available in all three programs.
• Eligibility: Companies registered outside mainland China can apply. Each application is reviewed case by case, and some industries are not accepted.
• Security checks: Cards support 3-D Secure and billing address checks through the address verification service, or AVS.

Dashboard and API task list

• Create cards: Dashboard or API, after HaiPay enables the issuing service on your account.
• Freeze and unfreeze cards: Dashboard or API.
• Set a spending limit per card: Dashboard.
• Lock a card to one merchant or merchant category: Dashboard or API, in all three programs.
• Close a card: Dashboard.
• Add notes or project tags: These appear in transaction records.
• Follow transactions: Real-time records, failure alerts and CSV exports. The API supports transaction queries and webhook notifications that send updates to your system.
• Test in a sandbox: Set up by the HaiPay team.

Use cases and limitations

Typical use cases are ad spend, AI subscriptions and issuing cards through the API. The US program is described for media buying including Meta and Google. The Singapore program is described for non-US online transactions, including TikTok media buying. Hong Kong program cards are not for OpenAI or Anthropic. Platform names describe enquiry use cases only: acceptance by any merchant is not guaranteed and no affiliation is implied.

If this matches your company's spending needs, start with the HaiPay card issuing page. Prepare your company details, intended merchants and required dashboard or API actions so the team can review the fit.

This guide is for general information, not investment, legal or regulatory advice. Its evidence was reviewed on 3 October 2026.

References

All sources accessed 3 October 2026.

• What we do, Visa.
• How are prepaid cards, debit cards, and credit cards different?, Consumer Financial Protection Bureau.
• EMV 3-D Secure, EMVCo.
• PCI Data Security Standard (PCI DSS), PCI Security Standards Council.