FAQ

In v0 we're test-mode only. Cards are issued against Stripe's Issuing test environment; no real charges happen. Live mode is gated on resolving Stripe Treasury pricing (currently quoted at $10-20k/mo BaaS tier) or finding an alternative rail (Increase / Column / etc). Expected resolution: weeks, not months.

Stripe authorizes the charge against our pre-funded Issuing balance. Our webhook handler catches the event, captures the auth-hold we placed on your saved payment method, and marks the card USED. Net effect: the merchant gets paid, you get charged for the held amount, we net zero on the float.

Three layers protect you. (1) API rate limit: 1000 req/hr per key. (2) Per-card spending_limit — even if an agent mints a card, Stripe enforces the cap at authorization time. (3) Your policy max_amount_cents — no card can be issued above it. If something still goes wrong, revoke the API key at /api-keys and all future requests fail instantly.

Only via Stripe's ephemeral-key mechanism. GET /v1/cards/:id returns an ephemeral_key_secret that expires in ~10 minutes and works with Stripe.js client-side. The PAN never transits our API. This is the Stripe-sanctioned pattern for revealing card secrets to authorized clients.

Usually yes. The card is a standard virtual Visa. Merchants that strictly check AVS need a matching billing address — we use your real KYB address so AVS passes. Merchants that require physical cards or specific issuing banks may fail; that's the nature of virtual cards everywhere.

Yes. After GET /v1/cards/:id + Stripe.js reveal, your agent has number, exp, cvc. It can paste these into a checkout form. Just be aware: this turns your agent into a handler of PCI data for that transaction, and you should not log the number anywhere.

Stripe Issuing's default spending_limit_max for virtual cards is $500 per transaction for new programs. It's raisable by request. We adopt it for v0 as a conservative default; per-card ceilings can be raised in v1 once we're comfortable with the loss profile.

Not yet. v0 cards are single-use — they self-destruct after one authorization. This is the #1 feature request from agentcard.sh users and we're prioritizing it for v1. In the meantime, use one card per purchase.

v0 pricing is finalized at launch. Expected: a free tier covering small hobby use, a flat-rate plan in the $10-20/mo range for active builders, and usage-based for teams. We'll be cheaper or comparable to agentcard.sh's $9 tier.

PostgreSQL in a US region. No card numbers, CVVs, or full PAN is ever stored by AgentPay — those live in Stripe's vault. We store: user email, API key hashes, KYB profile (name/DOB/address), saved payment method tokens (Stripe IDs, not numbers), card metadata, authorization events. All traffic is HTTPS. Session cookies are httpOnly+SameSite=Lax.

We inherit Stripe Issuing's PCI compliance by never handling raw card data ourselves. SOC2 and formal attestations are v1+ work. We are not a money transmitter because we never take custody of user funds.

We're protocol-agnostic in v0. A2A Agent Card publishing (declaring payment capabilities in an agent's .well-known file) is on the v2 roadmap as a potential differentiator. x402 integration depends on a customer asking for it.

Every error includes a request_id. Open an issue with the code + request_id and we'll trace it. For production incidents: revoke your API key, contact support. Status page and formal SLA come in v1.