Agentcard vs Turnkey Agentic Wallets

Agentcard

Purchases need the user's passkey approval by default, cards carry spending rules, and card creation takes an idempotency key. No status page, published rate limits beyond the token endpoint, or privacy policy of Agentcard's own was found, and the Trust Centre could not be read. Issuing costs $5,000 a month.

Turnkey Agentic Wallets

An agent gets a non-root user that can sign nothing until a policy allows it, with DENY rules taking precedence and human co-approval available. Policies cap value per transaction only, with no daily or rolling limit found, and each organisation gets five policies below Enterprise. Signing endpoints returned elevated errors for five hours on 27 August 2026.

Agentcard

1. Mint a platform token with POST /api/v2/oauth/token and cache it for its one hour. The endpoint allows 30 requests per 5 minutes per IP
2. Send the same Idempotency-Key on every retry of POST /api/v2/cards, and the same idempotency_key on every retry of buy_checkout
3. Pass source: "issued" to the MCP create_card tool for a card number. Without it the tool may start Vault setup and return a link
4. Call get_card_details only at the payment form and never log the result. Each read notifies the member and may return approval_required
5. Treat transaction.authorized and order.* webhooks as the record of a payment, and deduplicate deliveries on the event id

Turnkey Agentic Wallets

1. Use a non-root user's key. Refuse root credentials for unattended work, because root bypasses every policy
2. Scope every signing ALLOW policy by wallet.id or wallet_account.address, or it covers every key the user can reach
3. Check the activity status on each response. ACTIVITY_STATUS_CONSENSUS_NEEDED means a person must approve within 24 hours
4. Retry with the identical body to stay idempotent. Changing timestampMs creates a new activity
5. Back off with jitter on 429 and poll get_activity sparingly, since polling counts against the same 1 to 3 requests a second