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)

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 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

If your endpoint is unreachable, times out, or returns a non-2xx response, Fyatu approves automatically (fail open). Guaranteed blocking must be done via the card lifecycle endpoints (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

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 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

Getting Started

Concepts

Just-In-Time (JIT) Cards

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

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