Custom card issuing software development
Appfront builds the software around card issuance: requests, activation, setting budget and spending rules, blocking, and making transactions transparent. The issuing itself remains with a licensed party; we build the layer in which your organisation and your cardholders work. Get in touch to discuss what your situation requires.
What is card issuing software?
Card issuing software is the layer between your organisation and a card issuer. The issuer is a licensed party that actually issues the cards and processes the transactions; your software handles everything around that: who gets a card, with what spending allowance, which rules apply, how cards are activated or blocked, and how transactions flow into your own accounts.
That distinction matters. Issuing payment cards yourself requires licences and a connection to card schemes — that is not a software question but a licensing question. What does belong with a custom software developer is the programme logic: budgets, approvals, category rules, receipt handling and the integration with your accounting.
Appfront builds that layer as custom software on top of the API of an issuer you choose. For broader fintech requirements, see fintech custom development.
Rules before spending
Who receives a card, with what limit, for which categories and with which approval, defined as policy rather than as loose agreements.
Cardholders take action themselves
Activating, setting a PIN, temporarily blocking a card if it is lost and attaching a receipt to a transaction, without the finance team having to step in.
Transactions in your own accounts
Transactions come in, are enriched with cost centre and receipt, and flow into your accounting rather than sitting in a separate file.
What we do and don't do
With card issuing, the division of roles is essential, and it is fairer to make that clear upfront than afterwards.
The programme layer
Request and approval, budget and category rules, activation and blocking, receipt handling, transaction insight, reporting and integration with your accounting or ERP, all built on top of your issuer's API.
The issuing itself
Card issuance, connection to the card schemes, transaction processing and the associated supervision. That requires licences a software developer cannot provide. We do help with choosing an issuer and with the technical connection.
Our development process for your card programme
The choice of issuer determines what is technically possible, so we place it at the very start rather than running into it halfway through.
We map out who the cardholders are, which rules should apply, which approvals are needed and how transactions should reach your accounts. We also check which issuers support the features you need, as this differs considerably.
We design the rules model, the request and approval flow, the cardholder environment and the integrations with the issuer and your accounting software.
We build in short iterations with automated tests, structured logging and monitoring. You see working versions along the way and steer the work based on what your team actually needs in practice, rather than on a specification written months earlier.
Controlled go-live with validation and a safety net, followed by ongoing management, monitoring and further development as your card programme or choice of issuer changes.
What custom card software delivers in practice
What is needed varies by programme. These are the components that come up most often.
Requests and approval
A request flow with the approvals that fit your organisation, and issuing of physical or virtual cards through the issuer once approval is given.
Budget and spending rules
Limits per period, permitted categories, geographic restrictions and time windows, configurable per card or per group of cardholders.
Cardholder environment
Activating, viewing balance and transactions, temporarily blocking a card if it is lost and attaching a receipt, in an app or web environment in your own branding.
Receipts and accountability
Linking receipts to transactions, with reminders for missing receipts and a review and approval step for the budget holder.
Accounting integration
Passing transactions with cost centre, general ledger and VAT treatment through to your books, for example via an Exact Online integration.
Oversight and alerts
Alerts for unusual spending, cards that have gone unused for a long time and budget overruns, with an audit trail for every change to limits and rules.
Typical use cases in practice
We mainly see card programmes where money needs to be controlled by others.
Business expenses
Organisations that give employees a payment card rather than reimbursing expenses afterwards, with rules by role and direct accountability.
Mobility and fuel
Vehicle fleets and mobility schemes where spending is tied to the vehicle, category and sometimes location.
Social services and grants
Organisations that provide targeted spending allowances where spending is restricted to certain categories and accountability is required.
Platforms with payouts
Marketplaces and platforms that want to give participants spending power without first transferring money and reconciling afterwards.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology we use
Working with a card issuer means working within their API and their security and logging requirements. The exact choice depends on your processes, the systems to be integrated and your hosting preferences. We deliberately choose a stack your own team can manage and develop further, without dependence on per-user licences.
Why Appfront for your card programme?
Appfront builds custom software for a wide range of organisations in the Netherlands. With card programmes, we are clear up front about the division of roles: issuing belongs with a licensed party, the programme layer with us. That avoids a conversation halfway through in which it turns out something is not allowed.
We start by comparing issuers, because their API determines what can be built. Designing a programme and only then discovering that your issuer doesn't support category rules is an expensive order of work.
On every project we write clear documentation and make sure your own team, or a future supplier, can understand and manage the system. No black box: transparent code and clear agreements on monitoring, alerting and maintenance. You own the solution and pay no per-user licence fee.
Also see our broader services around custom software, fintech development and KYC/AML compliance software. Unsure about the approach? Get in touch.
Security for your card programme
Payment cards are subject to strict requirements for handling card data. Appfront designs so that sensitive card data does not flow through your own systems: the cardholder environment displays it directly via the issuer. This considerably limits your own obligations. We build to the OWASP ASVS.
Transaction data is personal data and says a great deal about how someone spends. We restrict access to those who functionally need it, record every change to limits and rules in an audit trail, and document the data flows for your record of processing activities.
More on our security approach: information security policy and CVD policy.
- Encryption in transit (TLS 1.2+) and at rest
- Role-based access following least privilege
- Audit trail for viewing and changes
- Secrets in a secure vault, not in code
- Documented data flows for your record of processing activities
- Card data stays with the licensed issuer
Frequently asked questions about building card issuance software
Answers to the questions we are asked most often.
No, and no software developer can. Issuing cards and processing transactions requires licences and a connection to the card schemes. That is done by a licensed issuer. We build the software around it — application, rules, cardholder environment, reporting and integrations — on top of that issuer's API, and help you choose.
Based on what your programme needs: which rules can be set per card, whether transactions arrive in real time, whether virtual cards are possible, which countries are covered and which costs apply. Those differences are large, and the choice determines what can actually be built in your software. We make that comparison before design.
A virtual card exists only as a number and is available immediately, suitable for online spending and for single use with a fixed amount. A physical card is needed for paying on location and at machines. Many programmes combine both, under the same rules.
Prevention through rules rather than after-the-fact checks: limits per period, permitted categories, geographic and time-based restrictions. In addition, alerts for unusual patterns and an audit trail for every change to a limit. Who is allowed to raise a limit is at least as important as the limit itself.
Yes, that is usually the biggest saving. Transactions arrive via webhooks, are enriched with cost centre and receipt, pass through the approval workflow you set up, and then go to your accounting system or ERP. This largely eliminates after-the-fact expense claims.
The cardholder can block the card directly in the app, which takes effect with the issuer straight away. A replacement card can then be requested under the same rules. Temporary blocking and unblocking are built in as standard, as that saves a lot of replacements for cards that were simply misplaced.
Your card issuer sets requirements on how you handle card data, and they are strict. In practice, we design the system so that sensitive card data never passes through your own systems: the cardholder environment displays it via the issuer directly. This keeps the scope of your own security obligations limited.
Many issuers provide their own portal, which is perfectly adequate for a simple programme. Custom development pays off when the rules or approvals are specific to your organisation, when you want to integrate with your own accounting or HR systems, or when cardholders should see an environment in your own brand rather than the issuer's.
Ready to build your card programme?
Tell us who the cardholders are, which rules should apply and how transactions should reach your books. We are happy to help you think through scope, integrations and the first version. A no-obligation first conversation will give you a clear picture of what is possible and whether custom development makes sense in your situation.