'API-first' is an easy claim to make and a harder one to deliver. If you are choosing a programmatic card issuer in Europe — to power agent spend, ad-account funding, contractor payouts or anything that needs cards created from code — the marketing all sounds similar. This guide is a practical checklist for telling a genuinely API-first European issuer from one that simply bolted an endpoint onto a consumer product.
Instant issuance you can rely on
The first test is whether you can create a card programmatically and use it immediately. Real API-first issuing means a single call returns a usable virtual Visa card — no manual approval step, no overnight batch, no support ticket. With 2card, card creation runs in roughly sub-200ms, which is fast enough to issue cards inline with a workflow rather than pre-provisioning a pool.
Ask for the latency figures and the consistency behind them. Issuance that is fast at the median but occasionally takes seconds will break any flow that mints a card per task. You want a tight distribution, not just a good headline number.
Per-card controls, enforced server-side
Cards without controls are a liability. The issuer should let you set, per card and via API:
- Hard spend limits enforced at authorization — so a cap is a real boundary, not a soft target your code has to police.
- Merchant whitelists — restrict each card to approved merchants or categories.
- Instant freeze and replace — stop a card in one call and reissue when ready.
The crucial detail is where enforcement happens. Controls applied in your own backend are only as reliable as your backend. Controls enforced at the authorization layer hold even if your service is down or an agent goes rogue. Insist on the latter. If spend safety for autonomous systems is your concern, our note on spend controls for AI agents goes deeper.
Webhooks and real-time decisioning
An issuer that only offers polling is not really API-first. You want webhooks for the events that matter — card created, transaction authorized, transaction declined, card frozen — delivered in real time so your systems stay in sync without hammering the API. 2card emits webhooks on card and transaction events for exactly this.
Check the event taxonomy, the delivery guarantees and the retry behaviour. Are events signed so you can verify origin? Is there an idempotency key so you can deduplicate redeliveries? These unglamorous details decide whether your integration is robust or perpetually almost-right.
Latency on authorization, not just issuance
Issuance speed gets the headlines, but for live spend the authorization decision latency matters just as much. When a card is presented, how quickly does the issuer approve or decline? 2card returns authorization decisions in around sub-100ms. Slow authorization shows up as checkout timeouts and failed purchases at exactly the wrong moment.
If the issuer lets you participate in the authorization decision, understand your time budget: you have milliseconds, and exceeding them means a default decision. Build for that envelope, and prefer issuers whose own decisioning is fast enough that your logic is the only variable to tune.
EU IBAN funding and SEPA
Here is where 'in Europe' has to mean more than a region setting. A European issuer should fund cards from a real EU IBAN over SEPA — including SEPA Instant and Direct Debit — in euro, with funds safeguarded and segregated. 2card puts one EU IBAN behind all your cards: you top up the IBAN, and every card draws from that euro balance.
This is not a cosmetic preference. A single EU IBAN means no foreign account to reconcile, no conversion just to load cards, and SEPA settlement that European finance teams already understand. If you want to understand the instrument itself, see our explainer on what an EU IBAN is. And because the accounts and issuing sit with myTU — an EU-licensed EMI supervised by the Bank of Lithuania — you get regulated European money movement, with 2card acting as myTU's marketing partner rather than as a bank.
Eligibility, KYB and who actually qualifies
An API is useless if you cannot get approved to use it. Before you build, confirm the eligibility criteria: which business types and jurisdictions are supported, what the KYB process looks like, and how long it takes. With myTU, KYB is fully online, which spares you the courier-documents era of business banking.
Ask the awkward questions early. Are your sector and country in scope? Are there restricted merchant categories that would block your use case? Is there a path to higher limits as you scale? Discovering a hard 'no' after you have written the integration is the most expensive way to learn it.
Self-serve vs sales-led — match it to your timeline
Finally, understand the access model, because it shapes your first week.
- Self-serve issuers let you sign up and hit a sandbox immediately — great for fast evaluation and prototyping.
- Sales-led issuers, common for regulated EU products, route you through onboarding and KYB first, after which you have a funded EU account and an issuer who understands your workload.
2card is sales-led via early access: you talk to us, complete KYB with myTU, and start issuing against a real EU IBAN. The trade-off is a little more upfront for a regulated, EU-native foundation underneath your cards. If you are mapping the wider landscape of programmatic payments on the continent, our primer on agentic payments in Europe sets the context.
The shortlist, in one place
- Instant, consistent issuance via a single API call.
- Per-card hard limits, whitelists and freeze — enforced server-side at authorization.
- Signed, idempotent webhooks across the events you care about.
- Low authorization latency, not just fast issuance.
- One EU IBAN, SEPA funding, safeguarded euro balances.
- Clear eligibility and fully-online KYB.
- An access model that matches your timeline.
Score any issuer against that list and the genuinely API-first European options separate quickly from the rest.