How to Build a FinTech App with Card Issuing: Architecture and API Integration

Sooner or later, many fintech products reach the point where they need cards. But adding card issuing requires a separate infrastructure for card creation, authorization, processing, controls, and transaction data.

A card issuing API gives a fintech product access to this infrastructure without having to build it from scratch. With a single integration, you can issue virtual and physical cards, manage how they are used, and receive card and transaction data directly in your product.

In this article, the CardsPro team explains how to add card issuing to a fintech product through an API integration and how that setup fits into the product’s existing architecture and user flow.

The integration has four main layers:
Fintech App / Web App
↓
Fintech Backend & Business Logic
↓
Card Issuing API
↓
Issuing / Processing / Card Network Infrastructure

The fintech keeps its existing app and backend. The card issuing API connects that backend to the infrastructure needed to issue cards, process payments, manage card status and controls, and return transaction data.

The app decides what the user can do and how those actions appear in the interface. When a user requests a new card, changes a spending limit, freezes a card, or opens their transaction history, the backend sends the corresponding request to the issuing API. The API processes the request and returns the result or sends an event back to the backend when something changes.

In practice, this means card functionality becomes part of the existing fintech product. A user can open the app, issue a virtual card, see its status and balance, set or change limits, freeze and unfreeze it, and view card transactions without leaving the product. The fintech controls that experience, while the issuing provider handles the card infrastructure behind it.

Card issuing can be built into many types of fintech products:

• Virtual cards inside an app
• Physical cards linked to customer accounts
• Corporate and employee expense cards
• Cards for SaaS subscriptions and recurring payments
• Wallet and payment products
• Crypto-funded cards
• Cards for travel and cross-border spending

How the cards work depends on the product. An expense platform, for example, can issue separate virtual cards to employees or teams, with individual limits for each card. A SaaS management service can create a dedicated card for every subscription, making it easier to control recurring spend and track payments by service.

A crypto wallet can let users fund card spending with USDT or USDC. The crypto stays on the funding side, while the payment itself goes through Visa or Mastercard as a standard card transaction.
The same approach works for products built around international spending. Instead of adding a new card integration for every payment scenario, a fintech can use the card products and geographic coverage available through its issuing provider.

In each case, the fintech decides who gets a card, where the money comes from, what limits and controls apply, and how all of this works inside the app. The issuing API handles the card operations behind it.

The integration starts in your backend. Your app sends requests to the card issuing API, and the API handles the card operations behind them.

A typical flow looks like this:

1. Create or identify the customer
2. Complete the required onboarding or verification
3. Create the cardholder
4. Choose the card configuration
5. Issue a virtual or physical card
6. Connect the card to the balance or funding source
7. Set limits and other controls
8. Receive card and transaction updates through the API and webhooks

For the user, all of this stays inside the fintech product. They request a card, change a limit, freeze it, or check a transaction in the app. The backend turns those actions into API requests and updates the interface with the result.

Your app controls what the user can do, while the issuing API creates and manages the cards, applies controls, and returns card and transaction data.

For a deeper look at what happens between an API request and a card transaction, see How Card Issuing APIs Work: From Request to Transaction.

Once the card is issued, it can be used like any other card. For a standard card payment, the flow looks roughly like this:

Cardholder → Merchant → Acquirer → Visa or Mastercard → Issuing side → Approval or decline

When the card is used, an authorization request reaches the issuing side. The transaction can then be checked against the available balance, card status, spending limits, merchant restrictions, geography, and risk rules.

If the payment passes the required checks, it is approved. If one of those checks fails, the payment is declined and the response travels back through the network to the merchant.

Authorization is only one stage of the transaction. Clearing and settlement happen later, after the initial payment decision.

For the fintech app, the important part is the data that comes back from this flow. The backend can receive the transaction status, amount, merchant information, decline reason, and other available data, then show the relevant result to the user or trigger its own product logic.

We cover authorization, clearing, and settlement in more detail in How Card Issuing APIs Work. For decline reasons and troubleshooting, see Virtual Card Decline Rate: Reasons and How to Reduce It.

Issuing the card is only the first step. After that, users need to manage it inside the app.
Through the API, a fintech product can let users:

• Freeze and unfreeze a card
• Block or close it
• Set or change spending limits
• Manage funding
• Check card status
• View transaction history
• Reissue a card when needed

These actions stay inside the same interface as the rest of the product. But some card and transaction events happen outside the app. A payment can be approved or declined during authorization, a transaction status can change later, or a card status can be updated on the issuing side.

Webhooks send these events back to the fintech backend in real time. If a payment is declined, for example, the backend can receive the event, save the transaction, update the user's history, and show the result in the app.

This keeps the product synchronized with the actual state of the card and its transactions without constantly polling the API. In production, the backend should also handle duplicate events, verify webhook signatures, and process errors without creating inconsistent card or transaction data.

The card configuration should match the way the card will actually be used. That includes the BIN country, network, card type, currency, funding setup, 3DS, spending controls, and the markets and merchants the card is intended for.

A card used for SaaS subscriptions may need a different setup from one used for advertising, corporate expenses, travel, or crypto-funded spending. BIN country, merchant country, billing details, transaction currency, and card type can all affect how the payment is processed.

The goal is not to choose one BIN for every case, but to match the card configuration to the specific payment scenario. We cover this in more detail in How to Choose a BIN for Virtual Cards.

CardsPro provides access to 20+ BINs, including options across the US, UK, Hong Kong, Singapore, and Estonia, with Visa and Mastercard products.

CardsPro connects to your backend through the API and adds card issuing to the product you already have. Your app, users, pricing, roles, permissions, and business logic stay on your side.

With CardsPro, you can add:

• Virtual and physical cards
• Visa and Mastercard
• 20+ BINs
• USD and EUR support
• Card funding
• Limits, freezes, and blocks
• Transaction data
• Risk and antifraud controls

Your backend uses the API to issue and manage cards based on actions inside the app. If a user creates a virtual card, changes its status, tops it up, or opens their transaction history, the backend calls the corresponding API method and returns the result to the interface.

The CardsPro API documentation covers card issuance, top-ups, withdrawals, blocking, freezing, PIN management, and transaction retrieval. For a broader explanation of the issuing flow, see Virtual Card Issuing API: How to Issue and Manage Cards Inside Your Product.

If you already have a fintech app, start by defining how cards should work inside it: who can issue them, how they are funded, what limits apply, and which actions users need. Then connect those actions to your backend flow and test how card creation, management, and transaction updates work inside the product.