How to Build a Fintech App That Includes Card Issuing

How card issuing works

Card issuing works through a chain of regulated partners, with your app as the front end and the rule maker. When your customer taps their card, this happens in a second or two:

1. The merchant sends the payment request through the card network.
2. The network routes it to your issuer processor.
3. The processor checks its own rules, then (if you set it up this way) asks your server whether to approve.
4. Your server checks the balance and your spending rules, and answers approve or decline.
5. Later the transaction settles, and the final amount may differ from the amount first authorised.

That last point surprises many teams. Holds, tips, fuel pumps, refunds and reversals all mean your ledger must track pending and settled amounts separately. If you are new to the wider topic, start with how to build a fintech app and come back here for the card layer.

The partners you need

You need an issuing bank, a card network, an issuer processor and an identity verification provider. Some companies bundle several of these roles into one card issuing platform, which is how most new programs start.

Partner choice depends on the countries you serve, debit or prepaid or credit, and consumer or business cards. Availability differs between Canada, the United States and the United Kingdom, so confirm coverage before you design anything. The bank will run due diligence on your company, and that process often takes longer than the software.

What your team builds

Your team builds everything the customer touches and the money logic behind it. The partner gives you card rails. The product is still yours to make.

• Onboarding and identity checks, with clear retry paths when a document photo fails.
• A double-entry ledger that tracks available, pending and settled balances and can be reconciled to the processor's files every day.
• Authorisation logic: the endpoint that answers approve or decline in real time. It must be fast and highly available, with a safe default if it times out.
• Card controls: freeze and unfreeze, spending limits, merchant category blocks, replace card, set PIN.
• The card screen: show card details securely, copy number, add to Apple Pay or Google Pay.
• Notifications for every transaction, decline and refund, with a reason the customer can understand.
• Disputes and support tooling: an internal admin console for your operations team is not optional.
• Funding: how money gets in, such as bank transfer or payroll, which is often its own integration.

Related reading: digital wallet app development and payment app development cover the funding and wallet side.

Keeping card data out of scope

The cheapest way to handle card numbers is to never touch them. PCI DSS applies to any system that stores, processes or transmits card data, so the goal is to keep your servers and your app code away from it.

• Use the processor's secure display components. Most issuing platforms offer an SDK or hosted view that shows the card number, expiry and security code directly from their servers. Your app only frames it.
• Use tokens everywhere else. Your database stores a card token and the last four digits, nothing more.
• Use the official wallet provisioning flow. Adding a card to Apple Pay or Google Pay from inside your app requires approval from the platform and support from your issuer. Plan for that review time.
• Never log card data. Check crash reports, analytics events and support screenshots as well as server logs.

Even with a small PCI footprint you still have obligations, and your sponsor bank will ask for evidence. Your own assessor or the bank will tell you which self-assessment applies. Our mobile app security guide covers the baseline app controls.

Building an audit-ready app

There is no single certificate that makes a fintech app "certified". What partners and auditors look for is evidence that you control access, changes and data. Build that evidence in from the first sprint, because adding it later is slow.

• Every money movement and every admin action written to an audit log that cannot be edited.
• Role-based access in the admin console, with two-person approval for sensitive actions such as manual balance adjustments.
• Separate development, staging and production environments, with no real customer data outside production.
• Code review and automated tests required before release, with a record of who approved what.
• Encryption in transit and at rest, managed secrets, and strong customer authentication with biometrics and device binding.
• An independent penetration test before launch and after major changes.
• Written policies for incidents, access reviews and vendor management. Short and followed beats long and ignored.

Be precise about who holds what. A development studio does not make your company compliant, and you should be wary of any vendor that claims to. Audits and attestations such as PCI DSS or a SOC 2 report are carried out by independent assessors on your organisation and your hosting. What a good build partner does is design the system so those reviews go smoothly. Regulation also depends on your model and country. In Canada, for example, registration duties for money services businesses and payment service providers may apply. Get legal advice early. Our overview of fintech app development and compliance in Canada is a starting point, not legal advice.

The order to build it in

Start the partner and legal track first, then build in the processor's sandbox while approvals run. A workable sequence:

1. Define the program: who the card is for, which countries, debit or prepaid or credit, virtual or physical.
2. Shortlist issuing platforms that support that program and start due diligence with the sponsor bank.
3. Design the ledger and the authorisation flow on paper. Review failure cases before writing code.
4. Build onboarding, ledger, virtual card and controls against the sandbox.
5. Build the admin console and reconciliation at the same time as the app, not after.
6. Run a closed pilot with staff and friendly users on real cards with low limits.
7. Add wallet provisioning, physical cards and disputes tooling, then widen access.

What drives cost and timeline

Cost varies with the program, so we quote after a scoping call instead of publishing a number. The main drivers are:

• Ledger and authorisation logic. This is the core engineering and the part you cannot cut.
• Number of countries and currencies.
• Physical cards, which add design approval, manufacturing, shipping and activation flows.
• Funding methods and any bank account or payroll integrations.
• Admin, support and dispute tooling.
• Security testing and evidence required by the sponsor bank.

Separate from build cost, expect partner fees such as platform fees, per-card and per-transaction charges, and possibly program minimums. Ask for these in writing early, because they shape your business model. On timeline, bank approval is often the longest item and is outside the developer's control.

We build the app, backend and admin tooling for fintech products. See fintech app development for how we work, or send us your card program idea and we will reply with questions and a fixed-scope quote.