Just-In-Time (JIT) Cards
A JIT card is a virtual card with no pre-loaded balance. Rather than funding the card before it can be used, Fyatu approves each authorization in real time against your program ledger. If the program has sufficient funds, the transaction is approved and the amount is settled from the ledger. If not, the transaction is declined.
JIT is the default model for programs that want fully centralised control over spending — no money sits idle on individual cards, and you never need to pre-fund a card before issuing it.
JIT must be enabled on the product, not on the card itself. Contact your account manager to set up a product with hasJIT: true. Once the product is created, every card issued against it is automatically JIT-enabled.
How JIT Works
1. Cardholder taps card at POS
│
▼
2. Card network → Fyatu (AUTHORIZATION_VERIFY)
│
▼
3. Fyatu → Your webhook endpoint (CARD_AUTHORIZATION_VERIFY)
│ ← You must respond within 2 seconds →
│
├── Your server: APPROVE ──► Fyatu → card network: APPROVE
│ │
│ CARD_AUTHORIZATION webhook
│ (informational, decision: APPROVED)
│
└── Your server: DECLINE ──► Fyatu → card network: DECLINE
(or timeout > 2s) │
CARD_AUTHORIZATION webhook
(informational, decision: DECLINED)
Creating a JIT Card
JIT cards are issued the same way as regular cards — the only difference is that amount is optional (you do not need to pre-load a balance):
curl -X POST https://api.fyatu.com/api/v3.20/cards \
-H "Authorization: Bearer $FYATU_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"cardholderId": "chl_01HXYZ1234ABCDEF5678",
"productId": "prd_01HXYZJIT123"
}'
issuanceData wrapper. features.hasJIT: true confirms the card is JIT-enabled:
{
"success": true,
"status": 201,
"message": "Card issued",
"data": {
"id": "crd_01HXYZ5555ABCDEF1111",
"cardholderId": "chl_01HXYZ1234ABCDEF5678",
"productId": "prd_01HXYZJIT123",
"status": "ACTIVE",
"cardType": "VIRTUAL",
"cardBrand": "VISA",
"maskedPan": "445123******4123",
"last4": "4123",
"createdAt": "2026-05-27T10:00:00Z",
"updatedAt": "2026-05-27T10:00:00Z",
"nameOnCard": "John Doe",
"expirationDate": "06/2030",
"balance": 0.00,
"currency": "USD",
"features": {
"hasJIT": true,
"has3DS": true,
"hasApplePay": false,
"hasGooglePay": false,
"hasSpendControl": false,
"hasMccControl": false,
"isReloadable": false,
"isOneTimeUse": false
}
},
"meta": {
"requestId": "req_01HXYZ123456",
"platform": "Fyatu CaaS",
"timestamp": "2026-05-27T10:00:00Z"
}
}
The CVV is not included in the POST /cards issuance response. Retrieve it at any time via GET /cards/{id}, which fetches live card details (CVV, balance, spending limits) directly from the card network.
Even on a JIT card, you can optionally pre-load a starting balance at issuance by passing "amount": 50.00. This is useful if you want a small buffer for immediate use. The card will draw from that balance first, then from the program ledger once it is exhausted.
CARD_ISSUED Webhook
When a JIT card is issued your server receives a CARD_ISSUED webhook. The key signal is "isJitfEnabled": true:
{
"event": "CARD_ISSUED",
"eventId": "evt_01HXY123456ABCDEF",
"businessId": "BUS1A2B3C4D5E6F",
"timestamp": "2026-05-27T10:00:00Z",
"data": {
"cardId": "crd_01HXYZ5555ABCDEF1111",
"status": "ACTIVE",
"cardType": "VIRTUAL",
"cardBrand": "VISA",
"cardholderId": "chl_01HXYZ1234ABCDEF5678",
"maskedPan": "445123******4123",
"last4": "4123",
"expirationDate": "06/2030",
"balance": 0.00,
"currency": "USD",
"is3ds": true,
"isTokenized": false,
"isJitfEnabled": true
}
}
"isJitfEnabled": true against this cardId so your system knows never to show a per-card balance UI — the cardholder’s spending ability is determined by the program ledger, not the card.
How Your Server Must Respond
When a JIT card is used, Fyatu calls your registered webhook endpoint with a CARD_AUTHORIZATION_VERIFY event and waits up to 1 second for your response. You decide whether to approve or decline — Fyatu forwards your decision to the card network.
Respond within 1 second. If your endpoint does not reply in time, Fyatu automatically approves the transaction (provided your program balance is sufficient). Do not call slow external services in this handler.
Approve
{
"decision": "APPROVE"
}
Decline
{
"decision": "DECLINE",
"reason": "VELOCITY_EXCEED"
}
reason is optional on a decline but recommended for your own audit trail. Choose the code that best describes why you are declining:
| Code | When to use |
|---|
VELOCITY_EXCEED | Your program balance or per-card limit is insufficient |
INVALID_MERCHANT | Merchant not permitted for this program |
BLK_MRCH | Merchant is on your blocked list |
TXN_NOT_PERMIT | This transaction type is not allowed |
SUSPECT_FRAUD | Transaction flagged as suspicious |
RESTRICTED | Card is suspended or access is restricted |
CASH_REQ_EXCEED | Cash withdrawal limit exceeded |
DO_NOT_HONOUR | Generic — use when no specific code applies |
freeze, terminate), not via the authorization webhook.
For the full webhook spec including payload fields, HMAC verification, and code examples, see CARD_AUTHORIZATION_VERIFY.
Authorization Webhook
Every authorization attempt — whether approved or declined — fires a CARD_AUTHORIZATION webhook to your endpoint after the decision is made:
{
"event": "CARD_AUTHORIZATION",
"eventId": "evt_01HXYZ987654FEDCBA",
"businessId": "BUS1A2B3C4D5E6F",
"timestamp": "2026-05-27T14:32:00Z",
"data": {
"cardId": "crd_01HXYZ5555ABCDEF1111",
"cardholderId": "chl_01HXYZ1234ABCDEF5678",
"amount": 42.50,
"feeAmount": 1.25,
"currency": "USD",
"merchantName": "Amazon",
"merchantMcc": "5999",
"merchantCountry": "US",
"decision": "APPROVED",
"timestamp": "2026-05-27T14:32:00Z"
}
}
decision | Meaning |
|---|
APPROVED | Your server approved (or no CARD_AUTHORIZATION_VERIFY webhook is registered and program balance was sufficient) |
DECLINED | Your server declined, the program balance was insufficient, or the card was frozen/terminated |
200 OK but cannot influence the decision. The approval or decline has already happened by the time this webhook fires.
For the full field reference see CARD_AUTHORIZATION.
Program Balance Management
Because JIT cards draw directly from the program ledger, keeping your program funded is critical:
- Subscribe to the
ACCOUNT_LOW_BALANCE event — fires when the program balance falls below your configured threshold
- Top up the program balance via the CaaS Portal or programmatically via
POST /account/deposit
- Monitor balance in real time via
GET /account/balance
If the program runs dry, all JIT authorizations will be declined for every card in that program simultaneously. Fund the program proactively.
JIT vs Pre-Funded Cards
| Pre-funded card | JIT card |
|---|
| Balance location | On the card | On the program ledger |
| Fund before issue | Required | Not required |
| Fund before purchase | Required | Not required |
| Auth decision | Auto-approved by network | Fyatu checks ledger in real time |
| Best for | Per-employee budgets, one-time use | Corporate spend, dynamic allocation |
features.hasJIT | false | true |
isJitfEnabled in webhook | false | true |
Sandbox Testing
In SANDBOX mode, JIT authorizations always approve regardless of program balance. This lets you test the full card issuance and transaction flow without managing sandbox funds.
Switch to LIVE mode to exercise real-time balance checks.
Webhook Events Summary
| Event | Direction | When it fires |
|---|
CARD_ISSUED | Fyatu → you | JIT card created — isJitfEnabled: true |
CARD_AUTHORIZATION_VERIFY | Fyatu → you | Synchronous — cardholder is at the terminal, awaiting your APPROVE/DECLINE |
CARD_AUTHORIZATION | Fyatu → you | Post-decision record of every authorization (approved or declined) |
TRANSACTION_AUTHORIZED | Fyatu → you | Auth approved — funds reserved from program ledger |
TRANSACTION_CLEARED | Fyatu → you | Transaction settled — funds permanently moved |
TRANSACTION_REVERSED | Fyatu → you | Auth reversed before clearing |
ACCOUNT_LOW_BALANCE | Fyatu → you | Program balance below threshold |
