--- name: talo-go-live description: Take a Talo Pay integration from zero to production through the Talo Partner Hub — test the whole flow in sandbox autonomously (payments, simulated transfers, underpaid and overpaid cases, signed webhooks, pings), handle sandbox and production credentials safely (scoped keys, env vars, rotation), and run the go-live checklist before charging real money. Use when the user wants to test Talo payments, set up Talo keys or webhooks, or launch Talo in production. --- # From sandbox to production with the Talo Partner Hub Hub: `https://talopartnerhub.vercel.app` · docs for agents: `https://talopartnerhub.vercel.app/docs/index.md` (every page also as Markdown: `/docs/.md`, or the MCP tool `read_docs`). ## 0. Credentials, before anything - Two environments, two kinds of key: `tph_test_…` (sandbox, test money) and `tph_live_…` (production, real money). - Three scopes: `read` (look), `charge` (read + create payments + sandbox transfers + webhook pings), `full` (also refunds, price changes, keys, webhooks). Use the narrowest: **checkout servers get `charge`**. - Best way to connect yourself: the MCP server with OAuth. `claude mcp add --transport http talo https://talopartnerhub.vercel.app/api/mcp`, then authenticate; the person picks the environment and scope in the browser, and the key never passes through the conversation. - Otherwise `npx talo-hub login` (sandbox) / `npx talo-hub login --production`. The person must authorize Talo once per environment; you can't do that step for them. Tell them exactly what to click, then wait for the command. `npx talo-hub login` waits until the person authorizes and then exits by itself (0 = connected): that exit is your signal, so don't ask them whether they authorized. Show them the link and code it prints; they compare the code in their browser. If your tool notifies you when a background command exits (Claude Code's background commands do), run it in the background and continue when that notice arrives; otherwise run it in the foreground with a timeout of at least 10 minutes. If it gets cut off, run the same command again: it picks up the same login, with the same link and code. If it expired, running it again checks once whether the person finished in Talo anyway (and collects the key), and otherwise starts a new login with a new link and code. - Project keys: `npx talo-hub keys create --name --scope charge --dotenv .env.local` writes `TALO_HUB_API_KEY` into that file, and `--vercel production|preview[:]` stores it as a Vercel Secret; either way it never appears on screen. (MCP `create_api_key` returns it: write it straight to the env file.) Never into code, git, logs or the chat. Check `.env*` is gitignored. - Sandbox key in development/preview environments, production key only in production. Never mix them. - Rotation: create the new key, deploy it, then revoke the old one (`npx talo-hub keys revoke `). Revoke immediately if one leaks. ## 1. Test everything in sandbox yourself No real money moves in sandbox: run these without asking. 1. `create_payment { amount: 15000, external_id: "test-" }` (or `POST /api/v1/payments`). 2. `simulate_transfer { payment_id, amount: 14999 }` → `get_payment` shows **UNDERPAID**: the code must not fulfil. 3. `simulate_transfer { payment_id, amount: 1 }` → **SUCCESS**, events `payment.updated` + `payment.paid` (`list_events`). 4. New payment, `simulate_transfer` with more than the price → **OVERPAID** (counts as paid). 5. Webhooks: register the project's https endpoint (`create_webhook_endpoint`, or `npx talo-hub webhooks add --dotenv | --vercel `, which first checks the URL answers without redirects or Vercel's login), store the `whsec_` secret as `TALO_HUB_WEBHOOK_SECRET`, then `test_webhook { endpoint_id }`; it must report `delivered: true`. If it fails, fix the handler (raw-body HMAC verification, 2xx answer) and ping again. 6. Locally, relay events with `npx talo-hub events listen --forward-to http://localhost:3000/api/webhooks/talo`. Relayed events are unsigned and carry `talo-hub-forwarded: 1`: accept those only in development. 7. Refund (needs `full`): `refund_payment { payment_id }` and check it in `get_payment`. 8. `check_go_live` (or `npx talo-hub doctor`, `GET /api/v1/readiness`) until `ready: true`. Fix each failed check with its `fix` text. ## 2. Go to production Ask the person before each production step, saying what will happen. 1. Production authorization: they run `npx talo-hub login --production` or re-authorize the MCP choosing **Producción**. New Talo accounts can take up to 36 h to be ACTIVE; until then no CVUs. 2. Production key with scope `charge` for the server, into the production environment only. 3. Register the production webhook URL, store its new secret in production, ping it with `test_webhook` / `npx talo-hub webhooks test --production`. 4. One small real payment: create it, the person transfers from their bank, confirm SUCCESS and that the order was fulfilled once. 5. `check_go_live` with the production key → ready. Follow its `recommendations` (for example, replace full keys with charge). ## Rules in production - Before `refund_payment`, `update_payment_price` or creating a production key: confirm with the person, naming the payment and the amount. - Never treat UNDERPAID as paid. EXPIRED can't be paid: create a new payment. - `talo_reconnect_required` means the person must authorize again; `insufficient_scope` means this key can't do that, so ask for a key with the needed scope instead of working around it.