Issue Virtual Cards
Programmatically

You can issue virtual prepaid Mastercard (USD and EUR) and Visa (USD) cards programmatically via API. Each card supports 3D Secure 2.0, and Visa cards also support Apple Pay and Google Pay tokenization.

Most development teams complete integration in 1-3 days. Our REST API has clean, well-documented endpoints with working code samples in Node.js, PHP, Python, and more. The sandbox environment mirrors production exactly.

We currently offer Mastercard World USD (MCWORLDUSD), Mastercard World EUR (MCWORLDEUR), and Visa Platinum USD (VISAPLATINUMUSD). Mastercard products have a $5 issuance fee, Visa Platinum is $10.

Yes. Visa Platinum cards support Apple Pay and Google Pay tokenization out of the box. Cardholders receive a tokenization OTP via webhook (card.tokenization_otp event) to complete wallet enrollment.

All cards support 3D Secure 2.0 authentication automatically. When a merchant requires 3DS, the cardholder is prompted to verify the transaction. You receive real-time webhook notifications for every 3DS challenge.

Yes. You can freeze (POST /cards/{id}/freeze), unfreeze (POST /cards/{id}/unfreeze), and permanently terminate (DELETE /cards/{id}) any card at any time via API. Status changes take effect immediately.

We support 11 card-related webhook events: card.created, card.funded, card.unloaded, card.frozen, card.unfrozen, card.terminated, card.replaced, card.transaction.approved, card.transaction.declined, card.transaction.reversed, and card.tokenization_otp.

The minimum funding amount is $5 (or €5 for EUR cards). A funding fee applies based on your pricing plan — check the GET /account/pricing endpoint for your current rates.

No. Your integration inherits Fyatu's PCI DSS Level 1 compliance through our BIN Sponsor partners. You never handle raw card numbers — we manage all sensitive card data.

Card issuing is charged per card issuance (from $5 per card) plus transaction fees. Your business wallet is funded with USDT, and fees are deducted automatically. Volume discounts are available on Enterprise and Premium plans.

A card program is the top-level container for your issuing operation — it holds network access, BIN configuration, settlement currencies and the compliance policies everything else inherits. A card product sits one level below and defines a specific kind of card: virtual or physical, prepaid or debit-linked, its network, its spend controls, its MCC rules and its 3DS behaviour. A card is a single instrument issued against one product and owned by one cardholder. You pass a productId and a cardholderId when you create a card, which is the hierarchy showing up directly in the request body.

There is no hard limit. A single program commonly runs several products at once — a virtual prepaid product for online spend, a physical debit product for everyday use, and a corporate expense product with tighter MCC rules — all sharing the same program-level KYC and compliance configuration. Adding a product is a configuration change, not a new integration.

Yes. Network selection happens at the product level, not the program level, so one program can run a Visa product and a Mastercard product simultaneously. That matters in markets where one network has materially better merchant acceptance than the other, and it means switching or adding a network does not require re-integrating against a different API.

Daily, weekly and monthly limits on both transaction count and value; per-transaction minimums and maximums; MCC allow lists and block lists; currency and geographic restrictions; and single-merchant locks. Controls set on the product apply as defaults to every card issued under it and can be overridden per card via the API without reissuing the card number. Updates take effect on the next authorization attempt.

When a cardholder taps, swipes or checks out online, Fyatu posts the authorization request to a webhook endpoint you configure. The payload carries the amount, currency, merchant, MCC, card ID and cardholder ID, and your server returns approve or decline inside the authorization window. Because your ledger makes the decision, balances are never stale and you do not need to prefund card balances in advance. If your endpoint is slow or unreachable, a program-level fallback rule decides instead, and the event is logged for review.

It is included. Every card is enrolled in EMVCo 3D Secure 2.0 the moment it is created, and Fyatu operates the protocol at platform level — there is no separate access control server to procure or integrate, no 3DS SDK to embed in your app, and no second vendor contract. What you control is behaviour, configured on the card product: the risk threshold above which a transaction is challenged, which exemptions apply, and the fallback when an authentication cannot complete. Those settings can be changed without reissuing cards, and challenges can be simulated in sandbox before a live card exists.

By risk score. Each authentication request is evaluated against the cardholder's transaction history, device fingerprint consistency, billing address match and the amount relative to that cardholder's normal behaviour. Requests scoring below the threshold configured on your product complete frictionlessly, with nothing shown to the cardholder; requests above it are stepped up to a challenge — an OTP, a biometric or a push confirmation on a hosted page. Default thresholds are tuned to challenge fewer than 5% of transactions, so most cardholders never see 3D Secure at all. 3DS 1.0 is still supported for backward compatibility where a merchant has not moved to 3DS 2.0, but 3DS 2.0 is used whenever it is available.

Yes, and it applies to both flows. A frictionless authentication carries exactly the same liability shift as a completed challenge: for an authenticated transaction, fraud chargebacks that would otherwise land on your program are directed to the merchant's acquiring bank instead. Card-not-present fraud is the largest dispute category for most issuing programs, so this is usually where 3D Secure pays for itself.

Each transaction is evaluated against the PSD2 exemption categories — low-value payments under €30 subject to cumulative caps, trusted beneficiaries, recurring payments and corporate cards — and where one applies, the correct exemption indicator is included in the authorization message. If the acquirer declines to honour the exemption and soft-declines the transaction, it is automatically retried with a full strong customer authentication challenge rather than being lost at checkout.

Yes. Fyatu emits authentication.frictionless, authentication.challenge_initiated, authentication.challenge_completed and authentication.failed to your configured event stream. Each carries the authentication value (CAVV/AAV), the ECI indicator and the transaction ID, so you can correlate authentication outcomes with the authorization records that follow and see exactly where cardholders drop out of a challenge.

Document requirements are configured at the program level and typically include a government-issued photo ID, proof of address, and a selfie or liveness check, with lighter tiers available for low-limit products. Verification runs through integrated identity providers, and you receive webhook callbacks on completion, rejection or escalation to manual review. Cardholder PII is stored inside Fyatu's PCI DSS and GDPR-compliant environment — your platform holds a cardholder ID and retrieves the record over authenticated API calls rather than keeping personal data on your own servers.

Freezing a cardholder suspends every card linked to that cardholder immediately, and any authorization attempted while the freeze is active is declined. Unfreezing restores all of those cards instantly — you never need to reissue card numbers or ask cardholders to re-add cards to their wallets.

Every card program gets a sandbox environment where you can define products, issue test cards, and simulate approvals, declines and 3DS challenges without touching live networks or funds. The API surface is identical to production — the same endpoints, the same payloads, the same webhook events and error codes — so going live is a matter of swapping API keys.

Sandbox access is provisioned as soon as your program is approved, so your engineers can integrate issuance, webhooks and authorization handling while compliance review runs in parallel. KYB onboarding usually completes in three to five business days, and most programs — including BIN assignment, network setup and compliance policy definition — are live within one to three weeks.