Card issuing & wallets
Card programmes and wallet balances on a ledger you own.
Virtual and physical cards, wallet balances, spend controls and the transaction feed that keeps them honest. We build the programme logic and the ledger. The BIN sponsorship, the scheme membership and the cardholder KYC obligations sit with a regulated issuing partner or with your own licensed entity.
Where it fits
The problem
Balances live in four provider dashboards and nobody can answer what a single customer holds right now. Support reads one screen, finance reads another, and the two disagree by a pending authorisation. Spend controls turn up as an afterthought once a customer buys something the programme was never meant to allow.
What we build
We build a double-entry wallet ledger you control, with authorisation holds, settlements and reversals as separate postings. Card issuing runs through the partner API behind an adapter. Spend rules sit in your policy layer, versioned and testable, so a merchant category change ships as a config release rather than a support incident.
How we engage
Senior engineers who have taken card programmes through partner certification and the first production dispute. The wallet ledger runs in your infrastructure, on your database, with your migrations and your audit trail. We pair with your team, write the operational runbooks, and leave you a programme yours to run.
What we build
Six parts of a card and wallet programme we build most often.
Virtual card issuing
Cards get created against a programme, funded from a wallet, and returned to the app as a display token with the sensitive fields fetched inside an iframe. Users can pay within the same session. The before-state is an employee paying with a personal card and waiting on a reimbursement form that clears weeks later.
Physical card programmes
Physical plastic brings a fulfilment vendor, an embossing file format, carrier copy and a postal address you now hold. We build the activation flow, PIN set and reset, replacement for a lost card, and the states in between. Teams that skip this discover it during the first stolen-card call.
Wallet ledger
Every movement becomes an immutable posting pair, and balances are derived rather than stored as a mutable number. Available balance and cleared balance are separate answers, because an authorisation hold is money committed and not yet spent. Support and finance finally read the same figure for the same customer.
Spend controls
Merchant category rules, per-card limits, velocity windows and country blocks live in one policy engine that answers the partner authorisation webhook within its timeout budget. Every decline carries a reason your support team can read out. Without this, controls arrive as tickets after a customer spends where they should not have.
Transaction webhooks
Authorisation, clearing, reversal and dispute events arrive separately and rarely in the order you would like. We match clearing records back to the original hold, expire stale holds on the network clock, and keep an event log you can replay when a balance looks wrong. Guesswork stops there.
KYC and onboarding
Cardholders must be identified before a card ships, and the partner sets the standard. We build the onboarding flow, the document capture handoff, the screening result states and the re-verification prompts, with decisions recorded for audit. The messy part is a pending case that blocks a card nobody told the customer about.
A wallet, a card and a declined purchase
The demo issues a virtual card against a funded wallet, then shows a blocked merchant category and the ledger postings behind both.
How we work
Discover
Systems, constraints, and the regulation you operate under get mapped before implementation starts, so the design accounts for what already runs and for what examiners will ask about.
Architect
A design that fits your stack. Integration-first, self-hostable, and built to change as rules, regulation, and volume do.
Build
Senior engineers ship in tight increments, each tested and reviewed as it goes, so the system is reviewable at every step instead of only at the end.
Harden
Security, compliance, and load-testing run inside the build, so controls, audit trails, and peak-volume behavior are proven before launch.
Run
The handover includes clean, documented systems, with the option to keep the same engineers operating them once they are live.
Why Oxagile
The ledger stays yours
Balances derived from your own double-entry postings mean you can answer a customer, a regulator or an auditor without opening a provider portal. If the issuing partner changes, the ledger survives the migration. That is the difference between a programme you operate and a dashboard you visit.
Straight talk on BIN sponsorship
A card programme needs a BIN, scheme membership and an issuer that carries the regulatory obligation. We are none of those. We work alongside the issuing partner you choose, build to their certification checklist, and tell you early where their rules will constrain the product you had in mind.
Controls designed before launch
Spend rules, limits and dispute handling get specified in the same sprint as the happy-path issuance, because retrofitting them into a live programme means reissuing cards and explaining the gap to your partner. We would rather have that argument during design than during an incident review.
Questions
Who is the issuer of record and who holds the licence?
The issuing partner or, if you hold the permissions yourself, your own licensed entity. They own the BIN, the scheme relationship and the regulatory obligation for the programme. We are the engineering team that builds the wallet ledger, the spend policy and the integration into their API. We do not hold a licence and never present ourselves as the issuer.
Do we have to run KYC on every cardholder?
In practice yes, and the standard comes from your issuing partner and the regulator behind them. Identity checks, sanctions screening and periodic re-verification apply to cardholders, with the depth varying by product type and jurisdiction. We build the flows and the audit record. The accept or reject decision stays with the party holding the licence.
Can we keep our own balances instead of relying on the provider's?
Yes, and we recommend it. Your ledger holds the authoritative postings and reconciles daily against the partner records, so a mismatch becomes a visible break with an owner. You still cannot move money without the partner, and the funds sit in their safeguarded or settlement account. Ownership here is about the record, the reporting and the customer answer.
How fast can the authorisation webhook decide, and what if we time out?
Networks give the issuing partner a short window, and the partner passes you a slice of it. Our policy engine reads precomputed limits and cached balances rather than doing joins on the hot path. You also choose the fallback, approve or decline, when your service does not answer in time. That default belongs in a written decision with your partner and your risk team.
Part of Embedded Finance
The finance layer inside your product, built and run by the same engineers.
Financial features,
native to your product.
Tell us what you want to embed: payments, cards, lending, payouts. We'll build the integration, orchestration and ledger around your providers.