T20 · Tutorial

Get production ready

Mint a live service-account key, pin expectedEnvironment live, configure Settlement, and map create → fund → capability_token — before attach.

~35 minIntroProductionproductStep track

Outcome: Live open works, policy validates, settlement rail is named, and you know how capability_token arrives for your rail.

Learning view: objectives and extras expanded. Switch for commands only.

Mental model

Production = live key + settlement rails + funded intent + attach. Sandbox smoke is evaluation only. Tenant still comes from the credential.

You will be able to

Distinguish paybond login sandbox keys from Machine access live service-account keys
Open Paybond with expectedEnvironment live against the hosted Gateway
Register paid tools in paybond.policy.yaml and run validate-tools --local-only
Configure Settlement for your rail (see Configure settlement rails)
Map create → fund (when needed) → capability_token for your rail — readiness only; bind next
Name where attach bundles are minted (Machine access → Agent middleware keys)

Prerequisites

· Tenant admin or operator access to Machine access (API keys) and Settlement
· Node 20+ or Python 3.11+ for open and policy validate
· Optional: First guarded spend so authorize → execute → evidence is familiar

Mint a live service-account key

In Console open Machine access → API keys. Create a live service-account key (paybond_sk_live_…). Store it in your secrets manager as PAYBOND_API_KEY — not in git and not via paybond login (device login is sandbox evaluation only).

Goal: Production deploy secrets must be operator-minted and rotated; device-login keys are for evaluation sandboxes.

Open Kit with live pin

Call Paybond.open with the live key and expectedEnvironment: "live" (Python: expected_environment="live"). Default Gateway is https://api.paybond.ai. Tenant is echoed from principal — never from user input.

Goal: Fail fast if a sandbox key is accidentally injected into a live deploy.

Ship a production policy

Own paybond.policy.yaml (or package it with your deploy). Register side-effecting tools with evidence_preset and ceilings. Validate with paybond policy validate-tools --file paybond.policy.yaml --local-only before promote.

Goal: Policy is the single source of truth for what agents may spend — same schema as sandbox, different ops and budgets.

Configure settlement rails

In Console open Settlement. Enable the rail your intents will use (Stripe Connect, ACH, x402, stripe_mpp, Shopify destination, …). Destinations are server-owned — create/fund payloads must not invent Stripe account ids or wallets. Full checklist: Configure settlement rails.

Goal: Paybond resolves payee destinations from tenant settlement config; create without a ready rail fails closed.

Map create → fund → capability_token

Production attach needs a funded intent and capability_token. Some rails mint the token on create (e.g. stripe_connect when hold succeeds immediately); delayed rails need fund (or fundWithX402 / fundWithMppCharge / fundWithMppSession). Walk Fund intents by rail and How intent funding works — you will execute create/fund in the next tutorial.

Goal: Without capability_token from a funded production intent, production attach and bind have nothing to guard.

Know attach bundle home (later)

After a funded intent exists, Machine access → Agent middleware keys mints a one-time production attach bundle (PAYBOND_ATTACH_INTENT_ID, PAYBOND_CAPABILITY_TOKEN, PAYBOND_ATTACH_BUNDLE). Payee and agent recognition seeds can instead live as APP_PAYEE_* / APP_AGENT_RECOGNITION_* env. Do not mint until the next tutorial has a real intent — just know the screen.

Goal: Gateway rejects empty recognition proofs on production mutations; attach material is separate from the service-account API key.

Console checklist (named screens)

Complete these in the authenticated Console before you write attach/bind code. Use the human labels below — paths are links only.

Machine access → API keys — mint paybond_sk_live_…; copy once into secrets manager.
Settlement — enable and verify the rail used for release/refund evaluation.
Machine access → Agent middleware keys — remember for attach bundles after fund (next tutorial).
Skip Intents / Disputes for now — those appear once you execute under production attach.

Commands you can run now

Local validate · no attach yet

Step 1 of 3
Validate production policy
Same validation as sandbox — ensure every side-effecting tool has evidence_preset.
Goal: Catch registry mistakes before a live reject on authorize.
Run this
```
$ paybond policy validate-tools --file paybond.policy.yaml --local-only
```
Example response
```
✓ tools registry ok
✓ every side-effecting tool has evidence_preset
✓ intent.allowed_tools aligned
```
You should see: Exit 0 with no missing evidence or allowlist misalignments.
Step 2 of 3
Optional status (with live env loaded)
When PAYBOND_API_KEY is the live secret in your shell, status confirms auth without writing device-login keys.
Goal: Confirm principal resolution before you write application bind code.
Run this
```
$ paybond status
```
Example response
```
Authenticated
environment: live
principal: service_account
tenant: ten_… (from credential)
```
You should see: Auth succeeds for the live service account; environment matches live.
Note: Do not run paybond login to obtain production credentials — mint live keys under Machine access → API keys.
Step 3 of 3
Not yet: sandbox smoke is not live attach
Green paybond agent sandbox smoke only proves gateway-composed sandbox guardrails. Live attach comes after create/fund and signing material.
Goal: Do not promote on a false green — live attach needs funded intent + recognition material.
Run this
```
# later (next tutorial): paybond agent production attach smoke --attach-intent-id …
```
Example response
```
# This path is skipped until create/fund + attach material exist.
# sandbox smoke ≠ production attach smoke
```
You should see: You can state sandbox smoke ≠ production attach smoke before continuing.
Note: Skip sandbox smoke here if you already completed First guarded spend.

Open session (SDK)

Pin expectedEnvironment to live so a sandbox key cannot accidentally open a production session.

open-session.ts

TypeScript: Paybond.openSwipe to inspect long lines

import { Paybond } from "@paybond/kit";

// Live service-account key from secrets manager — not paybond login
const paybond = await Paybond.open({
  apiKey: process.env.PAYBOND_API_KEY!, // paybond_sk_live_…
  expectedEnvironment: "live", // SDK accepts "live" | "sandbox" only
  // gatewayBaseUrl optional; default https://api.paybond.ai
});

// Tenant is session-bound from principal — do not accept client tenant ids
await paybond.aclose();

Result: open succeeds only with a live service-account key; tenant comes from principal, never client input.

Deep references (fund and rails): Configure settlement rails · How intent funding works · Fund intents by rail · Production attach. Next: create/fund a live intent, attach smoke, then protect your first tool without sandbox: true.

Verify before you continue

Check these off against your terminal or timeline output — progress stays on this device.

0/6

paybond_sk_live_… is in a secrets manager (not git, not from paybond login)
Paybond.open with expectedEnvironment: "live" succeeds (hosted Gateway or staged URL)
paybond policy validate-tools --file paybond.policy.yaml --local-only exits clean
Settlement checklist complete for your rail (or gap named)
You can state create vs fund for capability_token on your rail
You know Agent middleware keys mints attach bundles after fund

If something goes wrong

If you see
Using paybond login for production deploy secrets
Do this
paybond login writes sandbox PAYBOND_API_KEY to .env.local. Live keys stay Machine access → API keys / secrets manager only — never device-login for prod.
If you see
expectedEnvironment production throws at open
Do this
Kit accepts "live" | "sandbox" only. Use expectedEnvironment: "live" (TS) / expected_environment="live" (Python).
If you see
Tenant or env selected from request body
Do this
Never pass tenant IDs from unauthenticated input; open one session per service-account key and trust principal environment from the Gateway.
If you see
Treating sandbox smoke as production readiness
Do this
paybond agent sandbox smoke never exercises live attach or recognition proofs. After rails and a funded intent, use production attach (next tutorial) and paybond agent production attach smoke.
If you see
Skipping settlement config before create/fund
Do this
Paybond resolves payee destinations from server-owned settlement config — set rails under Settlement (Configure settlement rails) before create.

Self-check

Answer without scrolling up — then reveal the model answer to compare.

What three places must a live service-account key never appear when you ship Kit into a product, and what must be true on the intent before production attach?

Next steps

Pick a branch — not every path needs every tutorial.

Recipes are copy-paste production smokes — not repeated inside this tutorial.