Just-In-Time Funding, Real-Time Authorization

Fewer than the category implies. Most issuing platforms decide authorizations themselves, against a balance you prefunded with them, and expose configuration screens instead of a decision hook. Fyatu is built the other way round: real-time authorization is the default path, every transaction calls your endpoint, and your code returns the outcome. If you are comparing which card issuing platforms support just-in-time funding and your own authorization rules, the questions worth putting to each vendor are whether the decision hook is synchronous or advisory, whether it can modify the amount rather than only approve or decline, how long the timeout window is, what happens when it expires, and whether prefunding is required at all. On Fyatu the answers are: synchronous, yes, configurable from 500ms, a program-level fallback you define, and none.

Yes — that is the normal way to run a Fyatu program. The card itself carries no balance. When an authorization arrives, your handler reads the user's wallet balance from your own ledger, applies whatever holds, pending items, or fee logic you maintain, and approves only what the wallet genuinely covers. Because the read happens inside the authorization window rather than on a sync schedule, there is no double-spend gap between two transactions racing on the same wallet. The wallet can be denominated in fiat, in USDT or USDC, or in points and credits you convert at decision time.

The `authorization.requested` event is a signed HTTPS POST whose JSON body carries `transactionId`, `cardId`, `cardholderId`, `merchantName`, `merchantId`, `mcc`, `amount`, `currency`, `country`, `transactionType` (PURCHASE, ATM, or ONLINE), `network`, `initiationType` (CUSTOMER, RECURRING, or INSTALLMENT), and the full `cardMetadata` object you attached at card creation. The signature is HMAC-SHA256 over the raw body using your webhook secret, so verify authenticity before acting on the payload. Field-by-field definitions, documented error codes, and worked code examples live in the API reference.

Three outcomes. `{"decision":"APPROVE"}` lets the charge proceed. `{"decision":"DECLINE","reasonCode":"INSUFFICIENT_FUNDS"}` blocks it — reason codes come from the ISO 8583 set Fyatu maps, including `DO_NOT_HONOR`, `INVALID_TRANSACTION`, `EXCEEDS_WITHDRAWAL_LIMIT`, `RESTRICTED_CARD`, `SECURITY_VIOLATION`, and `FRAUD_SUSPECTED`, and the code is surfaced to the merchant's POS terminal and, where the cardholder's banking app supports it, as a human-readable message. Or return `{"decision":"APPROVE","modifiedAmount":50.00}` for a partial approval against remaining headroom, a credit line, an FX-adjusted figure, or a loyalty-tier discount you compute at decision time. Partial approvals are supported across Visa authorization flows on the Fyatu network.

It applies to every authorization the card generates, and the payload tells you which kind you are looking at. `transactionType` separates in-store purchases from online checkouts, cash advances, and ATM withdrawals, while `initiationType` distinguishes a cardholder-initiated payment from a recurring subscription charge or an installment. Handlers commonly branch on those two fields — tighter headroom checks and lower ceilings on ATM withdrawals, a more forgiving balance rule on a recurring charge so a subscription does not fail over a rounding difference, and a stricter path for anything unusual for that cardholder.

Static spend controls — MCC locks, velocity caps, geographic restrictions, daily ceilings — are evaluated by Fyatu's network layer against configuration you set in advance, and they run first: a transaction rejected there never reaches your endpoint and consumes none of your handler's latency budget. Real-time decisioning is the dynamic layer above it, where your own code consults live sources no static rule system can see: balance ledgers, machine learning models, compliance lists, a customer's account standing. Most programs run both, letting the controls filter the obvious rejections and the webhook handle everything nuanced.

Your backend holds the user's USDT or USDC balance, in your own ledger or wallet. When a card authorization fires, Fyatu calls your endpoint; your handler checks the crypto balance, converts to the transaction currency at spot rate, and returns approve or decline. Visa and Mastercard settlement happens in fiat, so the blockchain never enters the card network path. You get crypto-funded cards with zero smart contract complexity and none of the chain-level operational risk.

Stablecoin-prefunding platforms require you to lock USDC or USDT into on-chain pools before any card can transact, which ties up working capital and pulls blockchain integration into your stack. Fyatu inverts that: card balances are $0 until authorization, and funds are pulled from your ledger in real time at the moment of the transaction — no prefunding, no blockchain dependency, no capital lock-up, no exposure to a depeg event mid-programme. You keep full crypto card functionality, because your backend still holds and manages the crypto balances; only the card network path is entirely off-chain.

If your handler does not respond inside the configured timeout — 1,500ms by default, 500ms minimum — Fyatu stops waiting and applies your program-level fallback: auto-approve, auto-decline, or a rule-based fallback that evaluates your spend controls without calling you at all. Fallback behaviour can differ per card or per BIN, and every fallback decision is logged with a `timeout` reason code and tagged for post-incident review, so a partial outage surfaces as a reviewable list rather than an unexplained shift in your approval rate.

Fyatu dispatches the webhook within 20ms of receiving the authorization request from the network, and P99 dispatch-to-response is 80ms for handlers hosted in major cloud regions such as AWS, GCP, or Azure. The card network window is typically five seconds, which leaves your handler at least a second of genuine processing time even after round-trips. For high-volume programmes, delivery is parallelised per card and rate-limited at program level to avoid thundering-herd effects; keep the handler stateless, run it as an edge function or autoscaling serverless deployment co-located with Fyatu's gateway region, and back balance lookups with an in-region cache so the cold path never dominates your latency.

Yes, on both counts. The card metadata object is mutable through a PATCH /cards/{cardId}/metadata call and appears in the very next authorization payload, so credit limits, KYC tier, or custom flags can change server-side without reissuing the card. And because your handler is ordinary application code, you can split traffic however you like: a common pattern is to route a percentage of authorizations through a challenger model, log both champion and challenger decisions, then evaluate them against settled transaction data in your analytics pipeline before promoting the challenger.

Yes. The Fyatu sandbox simulates the full authorization pipeline — webhook dispatch and signing, your response handling, timeout and fallback behaviour, and the resulting event log — driven by test authorizations you trigger from the sandbox cards API. No live funds, no production card data, and the same endpoints, payloads, events, and error codes as production, so going live is a matter of swapping API keys.