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 → HostFi → Fyatu (AUTHORIZATION_VERIFY)
        │
        ▼
3. Fyatu → Your webhook endpoint (CARD_AUTHORIZATION_VERIFY)
        │         ← You must respond within 2 seconds →
        │
        ├── Your server: APPROVE ──► Fyatu → HostFi → APPROVE
        │                                  │
        │                        CARD_AUTHORIZATION webhook
        │                        (informational, decision: APPROVED)
        │
        └── Your server: DECLINE ──► Fyatu → HostFi → DECLINE
               (or timeout > 2s)           │
                                 CARD_AUTHORIZATION webhook
                                 (informational, decision: DECLINED)

You control the approval decision. Fyatu forwards the authorization request to your registered webhook endpoint and waits for your APPROVE or DECLINE response before replying to the card network. The cardholder sees no delay — your server must respond within 2 seconds.

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"
  }'

The response is a single flat object — no nested 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
  }
}

Store "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 2 seconds for your response. You decide whether to approve or decline — Fyatu forwards your decision directly to the card network. Both type and reason are required in every response.

Approve

{
  "type":   "APPROVE",
  "reason": "APPROVE"
}

Decline

{
  "type":   "DECLINE",
  "reason": "VELOCITY_EXCEED"
}

Choose the reason that best describes why you are declining:

Code	When to use
`VELOCITY_EXCEED`	Your program balance is insufficient
`AUTH_DECLINE`	Generic authorization refused
`RESTRICTED`	Card is frozen or suspended
`SUSPECT_FRAUD`	Transaction flagged as fraud
`INVALID_MERCHANT`	Merchant not permitted for this program
`TXN_NOT_PERMIT`	This transaction type is not allowed
`BLK_MRCH`	Merchant is on your blocked list
`CASH_REQ_EXCEED`	Cash withdrawal limit exceeded
`DO_NOT_HONOUR`	Generic — do not honour
`NO_CASH_SERVICE`	Cash not available on this card
`SEC_ERROR`	Security error
`CLOSED_PICK`	Account closed
`FRAUDULENT_PICK`	Card flagged for fraudulent activity
`NO_ACTION`	No action taken

For the full webhook spec including 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:

{
  "event":      "CARD_AUTHORIZATION",
  "eventId":    "evt_01HXYZ987654FEDCBA",
  "businessId": "BUS1A2B3C4D5E6F",
  "timestamp":  "2026-05-27T14:32:00Z",
  "data": {
    "cardId":       "crd_01HXYZ5555ABCDEF1111",
    "amount":       42.50,
    "currency":     "USD",
    "merchantName": "Amazon",
    "decision":     "APPROVED",
    "timestamp":    "2026-05-27T14:32:00Z"
  }
}

`decision`	Meaning
`APPROVED`	Program had sufficient balance — transaction is proceeding
`DECLINED`	Program balance was insufficient, card was frozen, or card was terminated

This is an informational event — your server must return 200 OK but cannot influence the decision. The approval or decline has already happened by the time the 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	When it fires
`CARD_ISSUED`	JIT card created — `isJitfEnabled: true`
`CARD_AUTHORIZATION`	Every authorization attempt (approved or declined)
`TRANSACTION_AUTHORIZED`	Auth approved — funds reserved
`TRANSACTION_CLEARED`	Transaction settled — funds permanently moved
`TRANSACTION_REVERSED`	Auth reversed before clearing
`ACCOUNT_LOW_BALANCE`	Program balance below threshold

Documentation Index

​Just-In-Time (JIT) Cards

​How JIT Works

​Creating a JIT Card

​CARD_ISSUED Webhook

​How Your Server Must Respond

​Approve

​Decline

​Authorization Webhook

​Program Balance Management

​JIT vs Pre-Funded Cards

​Sandbox Testing

​Webhook Events Summary

Just-In-Time (JIT) Cards

How JIT Works

Creating a JIT Card

CARD_ISSUED Webhook

How Your Server Must Respond

Approve

Decline

Authorization Webhook

Program Balance Management

JIT vs Pre-Funded Cards

Sandbox Testing

Webhook Events Summary