title: Cards
source_url: /developer-api/v1/cards-and-funds
summary: Issue cards, attach controls, and watch spend in real time — virtual or physical, agent-driven or human, embedded in your product or used directly.

content:
Issue cards, attach controls, and watch spend in real time — virtual or physical, agent-driven or human, embedded in your product or used directly.

How cards work

A Ramp card is a payment method that draws against a fund. Funds, spend programs, and approvals all live on the Spend Controls hub; this page covers the cards themselves — what each variant is, when to pick which, and how they're issued.

Every card in Ramp is one of these. The variant is set at creation; the rest of the card's behavior is just fund and policy configuration on Spend Controls.

Virtual

A 16-digit number, CVV, and expiration. Always tied to a fund. Use for online purchases, vendor payments, surfacing card details inside your own product, or any flow where plastic isn't needed.

Physical

A card shipped to an employee. Can draw from one or many funds (auto-matched by category) or carry independent spending restrictions. Use when an employee needs to spend in person — meals, travel, fuel, on-site purchases.

Agent

A per-merchant, per-amount payment credential generated at purchase time for AI agents, via Visa Intelligent Commerce. Use when an AI agent needs payment authority constrained to a specific purchase.

Virtual cards can be exposed two ways: server-side (Vault API, PAN to your backend) or browser-side (Ramp-served iframe, PAN never touches your servers). See Virtual cards for both patterns.

Standard API responses return masked card numbers. Full PANs and CVVs require the cards:read_vault scope and PCI qualification — submit a Developer API support ticket to start the qualification. All customers see full data in Sandbox.

A Merchant is the counterparty on a card transaction — the business where a swipe happened. Auto-populated from card network data and read-only; merchants are global (Home Depot is the same Merchant for every Ramp customer) and surface on transactions as merchant_id and merchant_name with a normalized name, logo, and category code. No dedicated CRUD endpoints — read merchants off the Transaction object.

For how Merchants relate to bill-pay Vendors and ERP Accounting Vendors, see Data relationships.

Virtual cards — issue virtual cards backed by funds, expose them to your servers (Vault API) or to a user's browser (iframe).

AI Agents — give an AI agent read access, action authority, and (with approval) real purchasing power via MCP, the CLI, and Agent Cards.

Spend programs — compose funds, spend programs, transactions, and webhooks to manage a recurring budget end-to-end.

Spend Controls — funds, spend programs, and approvals that back every card.

Bill Pay — vendor payments that don't fit a card.

Procurement — request-to-PO flow when spend needs approval upfront.

ERP Integrations — accounting vendors are the coding values card transactions map to for GL export.

Cards — physical card lifecycle.

Limits — the API behind funds; create, update, suspend, terminate. Virtual cards are issued here.

Transactions — settled spend, with filters by card and fund (limit_id).

Receipts — receipts attached to card transactions.

Cashbacks — rewards earned on card purchases.

Statements — monthly billing data.

Repayments — payments toward a card balance.

Trips — travel-tagged transactions, receipts, and reimbursements.

Webhooks — subscribe to transactions.cleared for real-time spend.

Rate limits and timeouts — guidance for high-volume card issuance.

Authorization — cards:read, cards:write, cards:read_vault scopes.