Skip to main content

​
Overview

Card programs typically require users to deposit USDC upfront to fund their card. With Sprinter Credit, users lock DeFi collateral instead — and credit is drawn automatically at the moment of each card authorization.
This example uses Rain as the card issuer, but the pattern applies to any card program with a webhook-based authorization flow.

​
Integration Steps

1

Lock Collateral

Instead of prompting users to top up with USDC, prompt them to lock collateral. A single /lock call handles everything — including optional wrapping into a yield-bearing earn vault.First, fetch available earn strategies from the protocol config:
curl -X GET https://api.sprinter.tech/credit/protocol
This returns the credit configuration including a strategies field with available earn vaults and their IDs.Then lock collateral — add the earn param to auto-wrap into a vault in the same transaction:
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/lock?amount=1000000000000000000&asset=0xCOLLATERAL_TOKEN&earn=STRATEGY_ID'
The earn parameter wraps the asset into a yield-bearing vault before locking — collateral earns while the credit line is active. Use a strategy ID from /credit/protocol.
Returns { calls: ContractCall[] } — execute in the user’s wallet. Once locked, the credit line is active.
2

Check Available Credit

Display totalCollateralValue (spendable credit) and healthFactor in your card UI.
curl -X GET https://api.sprinter.tech/credit/accounts/0xUSER/info

{
  "data": {
    "USDC": {
      "totalCollateralValue": "5000.00",
      "principal": "0",
      "interest": "0",
      "healthFactor": "Infinity",
      "dueDate": null
    }
  }
}
See Credit Engine for how health factor and LTVs work.
3

Draw Credit

With collateral locked, you can draw credit (USDC) from the user’s credit line. In a card program, this happens in your authorization webhook handler — but the /draw endpoint itself is a general-purpose credit draw, not specific to card authorizations.
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/draw?amount=50000000&receiver=0xSETTLEMENT_ADDRESS'
ParameterDescription
accountUser’s wallet address (borrower)
amountUSDC in lowest denomination (6 decimals — $50 = 50000000)
receiverAddress to receive the USDC (e.g. your card program’s settlement address)
Returns { calls: ContractCall[] } — execute on-chain to deliver USDC to the receiver.
A 0.50% origination fee is deducted from each draw. See Fees for the full fee schedule.
For card programs, you’ll call /draw from your authorization webhook handler to fund each card swipe in real time:

Authorization Webhook Handler

Complete TypeScript implementation showing how to wire /draw into a card authorization flow with signature validation, credit checks, and sub-2-second execution.
4

Repayment

Credit runs on a 30-day billing cycle with a 7-day grace period. Repay before the due date to avoid the 15% overdue APR. See Fees.
curl -X GET https://api.sprinter.tech/credit/accounts/0xUSER/info
# Returns: principal, interest, dueDate
5

Unlock Collateral

When a user closes their card and has zero outstanding debt:
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/unlock?amount=1000000000000000000&asset=0xCOLLATERAL_TOKEN'
Returns { calls: ContractCall[] }. Execute in the user’s wallet to return collateral.

​
Delegated Credit Draws

Card authorizations must complete in ~2 seconds without user interaction. Your backend needs the ability to draw credit on behalf of users at swipe time. There are two approaches:
Users deploy a smart account (e.g. ERC-4337) that can execute draw transactions autonomously. The user retains full custody — the smart account automates signing based on pre-configured rules.How it works:
  1. User deploys or connects a smart account
  2. User configures a session key or module that authorizes your backend to call /draw
  3. At swipe time, your backend submits the draw calldata through the smart account
This is the most trust-minimized option — users never grant direct access to their credit line.

​
Integration Notes

Whether using smart accounts or the operator contract, the signing key that executes draws must be secured with HSM or cloud KMS (AWS KMS, GCP Cloud KMS) in production. Never store it in environment variables on shared infrastructure.
Confirm with your card issuer which address to pass as receiver in the draw call. This is the address that receives USDC on each authorization.
Always decline if the draw cannot be confirmed on-chain. A declined swipe is recoverable; an unauthorized spend is not.
Poll healthFactor from the info endpoint and surface alerts in your UI. See Risk Management for liquidation thresholds and collateral tiers.

​
Try It

Want to see the full card program lifecycle running end-to-end? The Card Program Demo executes every step above — lock, credit check, draw, repay, unlock — using real Sprinter API calls on Base. It also supports a dry-run mode for testing without on-chain transactions.

Card Program Demo

Clone the repo, add a wallet with USDC on Base, and run npm run ui to launch the demo dashboard. See the README for full setup instructions.
You can also point an AI coding agent (like Claude) at the Sprinter Credit API and your card issuer’s API docs to generate a working proof of concept in minutes — the API is simple enough that an agent can wire up the full flow end-to-end.

Credit Engine

Health factor, LTVs, and liquidation mechanics.

Risk Management

Collateral tiers and concentration limits.

Credit API Reference

Full API reference with interactive playground.