Create a Lithic virtual card and handle transaction webhooks
domain: docs.lithic.com · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Authenticate all requests with the API key in the Authorization header as 'YOUR_KEY'
Create a card: POST /v1/cards with type: 'VIRTUAL', spend_limit (in cents), spend_limit_duration ('TRANSACTION', 'MONTHLY', or 'ANNUALLY'), and state: 'OPEN'; receive a card token, pan, cvv, and exp_month/exp_year in the response
Register a webhook endpoint in the Lithic dashboard or via POST /v1/webhooks; Lithic sends events for transaction.created, transaction.updated, and card state changes
On receiving a webhook, validate the Lithic-Signature header using your webhook secret and HMAC-SHA256 to confirm authenticity before processing
Parse the transaction event payload: inspect status (PENDING, SETTLING, SETTLED, DECLINED), amount, merchant.descriptor, and result to update your internal records
Known gotchas
The PAN and CVV are returned only at card creation time; Lithic does not expose raw PAN in subsequent GET /v1/cards responses — store or display them immediately or use the tokenized form
Webhook delivery is not guaranteed exactly-once; implement idempotent event processing keyed on the event token to avoid double-crediting or double-debiting
Spend limits are enforced at authorization time; a PENDING authorization reduces available balance, but the limit check uses the spend_limit_duration window — ensure your limits align with expected usage patterns
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?