Crypto card funding
How 0Pools can support approved card-funding liquidity flows while keeping card and treasury operations separate.
Crypto card funding needs predictable conversion from fiat or stablecoin value into a card-usable balance. 0Pools can provide the liquidity quote and trade lifecycle for approved partners, while the card program remains a separate product and compliance responsibility.
Architecture
What 0Pools handles
- Entitled pool discovery.
- Quote preview and firm quote lock.
- Execution idempotency.
- Trade status.
- Balance and reconciliation records where enabled.
What 0Pools does not handle
- Card issuance.
- Card authorization.
- Scheme rules.
- Customer disclosures.
- Chargeback handling.
- Card ledger policy.
Example flow
- User requests a card top-up.
- Partner backend checks available pools and limits.
- Backend creates a firm quote.
- User accepts before expiry.
- Backend transacts once.
- Partner waits for
settled. - Partner credits the card balance ledger.
User-state table
| 0Pools state | Card app state |
|---|---|
| Quote active | "Review top-up quote." |
| Quote expired | "Refresh quote." |
| Reserved | "Top-up pending." |
| Settled | "Top-up complete." |
| Failed/released | "Top-up failed or cancelled; no final credit." |
| Returned | "Top-up under review." |
Important guardrail
Do not make card funds spendable on reserved. Card balance should become available only after your approved settlement policy and terminal state are satisfied.
Before and after
| Before 0Pools | With 0Pools-backed funding |
|---|---|
| Card program preloads stablecoin manually or keeps large buffers to handle conversion timing. | Backend requests a time-limited quote and only credits after the approved terminal state. |
| Product code mixes card authorization, conversion, treasury movement, and reconciliation. | Card ledger code stays separate from the pool quote/trade/status lifecycle. |
| Support agents investigate card ledger and crypto movement in separate systems. | Support starts with partner order id, quote id, trade id, status, and request id. |
| Users may see a stale top-up price if they take too long to confirm. | The quote expiry makes the acceptance window explicit. |
Settlement-safe funding timeline
The key product decision is when the card ledger becomes spendable. 0Pools can say a trade is reserved, settled, failed, released, or returned; the partner's card program decides how those states map into card balance availability.
Implementation records
Store the pool record separately from the card ledger record:
{
"card_top_up_id": "ctu_1009",
"user_id": "user_42",
"card_ledger_entry": "card_pending_778",
"pool_id": "EUR-USDT",
"quote_id": "pool_quote_123",
"trade_id": "pool_trade_456",
"pool_status": "reserved",
"card_status": "pending",
"available_to_spend": false
}When settlement completes, update the card ledger from the terminal trade state. Do not let browser callbacks, quote creation, or a non-terminal reserve event make funds available to spend.
Card funding boundary
0Pools can support funding liquidity, but the card program remains responsible for card authorization, spend controls, disputes, and card-network settlement.
| Concern | 0Pools | Card program |
|---|---|---|
| Quote fiat-to-stablecoin funding | Yes, for approved pools. | Displays accepted terms. |
| Execute funding movement | Yes, server-side. | Initiates from approved backend. |
| Card authorization | No. | Yes. |
| Card dispute/chargeback | No. | Yes. |
| User balance display | Provides funding status/ledger input. | Owns final wallet/card balance UX. |
Funding record
{
"card_funding_id": "cf_7841",
"pool_id": "EUR-USDT",
"quote_id": "pq_live_01J4",
"transact_id": "pt_live_9A2",
"card_account_reference": "card_acct_55",
"funding_status": "reserved",
"card_spend_enabled_after": "settled"
}Product rule
Do not make card spend available from a quote alone. Spend should unlock only according to the card program's approved balance rules after trusted 0Pools status and ledger records are processed.
Implementation depth
This page is about using 0Pools as the liquidity leg behind card funding flows. For developers, the durable boundary is simple: your product should depend on funding order, quote terms, trade status, and card/balance posting reference; it should not depend on card processor settlement, treasury refill, and liquidity route mechanics. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.
Product scenario
A card program lets a user fund spendable value from fiat into stablecoin-backed inventory. The card ledger posts only after 0Pools reaches the required terminal state.
Before and after in practice
| Before 0Pools | With 0Pools |
|---|---|
| Card funding logic and crypto conversion logic are mixed, so failures create unclear available balances. | The card program treats 0Pools as a conversion record and posts card balance from confirmed state. |
| Product teams infer liquidity behavior from provider-specific screens or manual notes. | Product teams branch on 0Pools objects: pool, quote, trade, balance, webhook, and ledger. |
| Support asks engineering to reconstruct state from logs. | Support starts from request id, quote id, trade id, event id, and ledger id. |
System flow
Records to keep
| Record | Why it matters | Example |
|---|---|---|
card_funding_id | Product-side funding id. | cf_123 |
quote_id | Accepted conversion terms. | pq_test_123 |
trade_status | Determines whether to post. | settled |
card_posting_id | Card ledger reference. | card_led_456 |
A useful implementation stores these records before adding optional analytics. Analytics can be rebuilt from durable state; missing ids usually cannot be reconstructed after a customer-impacting failure.
Example product record
{
"product_area": "crypto-card-funding",
"partner_reference": "partner_order_123",
"pool_id": "EUR-USDT",
"quote_id": "pq_test_123",
"transact_id": "pt_test_456",
"status": "reserved",
"request_id": "req_01HZY0POOLS",
"reconciliation_state": "open"
}This record is intentionally partner-facing. It references 0Pools objects and your own product ids, but it does not include private liquidity routes, treasury balances, raw provider payloads, or customer secrets.
Failure modes and recovery
| Failure mode | Product response |
|---|---|
| Card balance credited on reserved | Wait for required terminal state. |
| Card reversal not linked | Tie reversals to trade id. |
| Network fees mixed into card fees | Keep conversion economics separate. |
| Support cannot trace | Store card funding id with quote/trade ids. |
Use-case patterns
| Pattern | How 0Pools helps |
|---|---|
| Prepaid card top-up | Fund spendable balance. |
| Crypto rewards card | Convert reward inventory. |
| Expense card program | Move treasury value into card rails. |
Developer checklist
- Read runtime discovery and capabilities before rendering enabled actions.
- Create firm quotes only when the user is ready to accept the terms.
- Execute from your server with an idempotency key.
- Treat webhooks and status reads as the source of truth for settlement state.
- Reconcile by durable ids first, then by amount and timestamp.
- Do not branch product behavior on provider names, route names, reserve balances, or treasury assumptions.