How Agents Manage Subscription Spend With Virtual Cards

An agent that provisions SaaS tools for customers — spinning up analytics, email, or API keys on signup — eventually hits the billing page. Every vendor wants a card on file. Naïve is the autonomous company infrastructure that gives agents real-world capabilities, and /cards is the primitive that turns "subscribe to this tool for Client A" into governed recurring spend the agent can complete without sharing one corporate Amex across every tenant. Part of the autonomous company use-case cluster.

This guide shows how to give a subscription-provisioning agent per-tool virtual cards: funded, capped monthly, approval-gated for new commitments, and scoped with naive.forUser(customerId) so multi-tenant SaaS platforms stay isolated. Enforcement lives in the card network and the Naïve gateway — not in a system prompt.

This tutorial connects to event booking cards, the corporate travel desk, and spend caps and approvals — same primitive, recurring use case.

Why subscription spend needs cards

Sharing one platform card across all customers fails isolation: every tenant's subscriptions bill the same balance, and one agent mistake affects everyone. Pasting card numbers into prompts fails the ceiling test — there is no hard monthly cap the model cannot exceed.

The Company → Employee → Primitive model applies: your platform defines policy, each customer's agent acts on their behalf, and /cards binds spend to that agent with a limit you set in cents.

Architecture

Four pieces work together:

• Users — one tenant user per customer.
• Account Kits — enable cards, default monthly limits, gate new subscriptions.
• Cards — virtual card per tool or vendor category.
• Approvals — human gate before large recurring commitments.

Setup

npm install @usenaive-sdk/server

import { Naive, isPendingApproval } from "@usenaive-sdk/server";
 
const naive = new Naive({ apiKey: process.env.NAIVE_API_KEY! });

Use naive.forUser(customerId) for every call that touches cards.

Step 1 — Encode subscription policy in an Account Kit

const saasKit = await naive.accountKits.create({
  name: "SaaS provisioning — standard",
  primitives_config: {
    cards: {
      enabled: true,
      requiresApproval: true,
      defaults: { spending_limit_cents: 50_000 }, // $500/mo default per card
    },
    formation: { enabled: false },
    verification: { enabled: false },
  },
});

requiresApproval: true on cards means creating or topping up a card freezes until a human approves — the right default when agents subscribe to tools with recurring fees.

Step 2 — Create a tenant user per customer

const customer = await naive.users.create({
  external_id: "acme-corp-001",
  email: "ops@acme.com",
  account_kit_id: saasKit.id,
});
 
const client = naive.forUser(customer.id);

Every card and transaction below is scoped to customer.id.

Step 3 — Issue a per-subscription card

When the agent provisions "PostHog for Acme — $89/mo," issue a card scoped to that tool:

const card = await client.cards.create({
  name: "Acme — PostHog analytics",
  spending_limit_cents: 9_000,
});
 
if (isPendingApproval(card)) {
  return { status: "pending_approval", approvalId: card.approval_id };
}

The spending_limit_cents value is the hard monthly cap — the network declines anything above it.

For lightweight tools under the documented prepaid maximum, a gift card may suffice. For higher recurring limits, use a managed virtual card after cardholder setup. See the cards docs.

Step 4 — Complete checkout and log the charge

Once funded and active, the agent completes the SaaS billing checkout through the governed API. Log the first charge:

// Manual logging uses the card log-transaction endpoint:
await fetch(`https://api.usenaive.ai/v1/cards/${card.id}/log-transaction`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.NAIVE_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    amount_cents: 8_900,
    merchant_name: "PostHog",
    description: "Monthly analytics — Acme",
  }),
});

Managed virtual cards may also capture recurring charges via webhooks; manual logging covers prepaid flows and reconciliation.

Step 5 — Revoke on churn

When a customer cancels, revoke their cards or session so no new subscription charges clear. See instant revocation for the broader pattern.

What this enables for SaaS operators

• Per-tool budgets — one card, one monthly cap, one approval gate.
• Multi-tenant isolation — each customer's tool stack bills only their balance.
• Clean offboarding — revoke stops the spend rail; pair with vendor cancellation in your agent.
• Audit trail — finance reconciles subscription spend per tenant without trusting agent summaries.

The agent still handles research and provisioning logic. /cards is what makes the payment step real and bounded.

Related reading

• Introducing /cards — primitive overview
• Event booking cards — one-time deposit pattern
• Corporate travel desk — per-trip card pattern
• Spend caps, approvals, and revocation — governance deep dive
• Cards documentation — API reference