PROGRAMMABLE CARDS · THE SPEND FIREWALL
Every purchase answers to a rule you wrote.
Hand an AI agent a plain card and it can buy anything. An APPEN Card is an Open Card: fourteen rule kinds you write, evaluated on every purchase before any money moves, with the reason kept on record for every decision. The agent never sees the number.
HOW IT WORKS
Commission a card
Set a budget and a refill schedule, then the rules: which merchants and categories, how much per order, and where.
Connect your agent
Point your agent at the card over the API or an MCP server. A few lines, and it's live.
It spends inside the lines
Every charge is checked against your rules in the moment, approved or declined, and written to an audit log.
TRY IT YOURSELF
Give an agent a card, then try to make it misbehave.
Pick an agent, set its budget and rules, issue the card, and send it shopping. This runs the same checks the APPEN API enforces, simulated here so nothing real is charged.
A person's food-ordering agent
# add APPEN as an MCP server claude mcp add appen https://mcp.getappen.com # your agent can now call # appen.request_purchase(merchant, amount)
PRIVACY BY ARCHITECTURE
Your agent can spend it. It can never see it.
The agent gets a handle to a card, not the card. It says what to buy; APPEN checks your rules and completes the payment behind a boundary the agent can’t cross. The number, the CVV, and the expiry never touch the agent, the model, or its logs, so there’s nothing to memorize, log, prompt-inject out, or leak.
card : "crd_9f2a…c41" // a handle
last4 : "••••4471"
status : "active"
budget : "$36.10 left"
pan : ⟨held by APPEN⟩
cvv : ⟨held by APPEN⟩
▶ request_purchase({
card: "crd_9f2a…",
merchant: "doordash",
amount: 2410,
})
◀ { status: "approved",
settled: "$24.10",
txn: "txn_7b3…" }APPEN mints a single-use, merchant- and amount-locked token (or injects the card at checkout), so the number is used without ever being handed back.
Illustration of the boundary · the card number is a mock test value · real issuance ships with our issuing partner (bank-sponsored, Mastercard network).
WHY WE’RE DIFFERENT
The consumer tools stop at caps and locks. We ship the rulebook.
Checked against each product’s own site and docs, fact-checked 2026-07-28 with an adversarial verify pass. The self-serve tools give you caps, locks, and a pause button, and they hand the spender the raw card number. Lithic ships a real rule engine with explained declines — for underwritten card programs behind a business agreement, not for a person with an API key. Each piece on this table exists somewhere. The full combination — self-serve for an individual, rules decided before a credential exists, every decision explained and kept, and a spender that never holds the number — ships nowhere else. The one row we concede is our own: cards moving money is what the issuing partner unlocks.
| CAN IT… | APPEN | ROBINHOOD | AGENTCARD | PRIVACY.COM | LITHIC | RAMP |
|---|---|---|---|---|---|---|
| A configurable rule engine (merchant, category, amount, cadence, time, human gates) | ✓ | ~ | ~ | ~ | ✓ | ~ |
| Rules decided before any card credential exists (the intent gate) | ✓ | ✗ | ~ | ✗ | ~ | ~ |
| Every decision explained rule-by-rule and kept on record | ✓ | ? | ✗ | ? | ✓ | ? |
| A budget per agent / per spender | ✓ | ~ | ~ | ~ | ✓ | ✓ |
| Spender never receives the card number | ✓ | ✗ | ✗ | ✗ | ~ | ✓ |
| Self-serve for an individual, no business account | ~ | ~ | ✓ | ✓ | ~ | ✗ |
| Real cards moving money today | ✗ | ~ | ✓ | ✓ | ✓ | ~ |
✓ SHIPS IT · ~ PARTIAL · ✗ NOT OFFERED · ? NOT VERIFIABLE IN THEIR PUBLIC DOCS · SOURCES: EACH PRODUCT’S OWN SITE AND DOCS, FACT-CHECKED 2026-07-28
ONE MORE THING
See the approval reach your pocket.
When a rule parks a purchase, the decision comes to you. Tap through the designed companion-app experience: the push, the per-rule reasons, one tap, and the whole rulebook re-runs.
Open the approval mockup →WHERE WE ARE
Everything you used above is real logic. The one piece not live yet is moving actual money, which is what the issuing partner unlocks.
- ✓The rule engine, running in production
- ✓Budgets and rules per card
- ✓Connect over the API or MCP
- ✓Plaid bank connection in sandbox (AI Startup Program)
- ✓A live audit log of every decision
- ·Issuing partner integration in progress (bank-sponsored, Mastercard network)
- ·The first live purchase by an agent
- ·Opening up beyond the first pilot users
Built solo, in St. Louis.
The rule engine is live and the cards are next. If you’re building agents that spend money, or you want to compare notes, I’d like to hear from you.