Operate a Live Account

The sandbox server is for building an integration; the live read-only server is for operating one. A support or reconciliation agent connects to https://mcp.elasticpay.co/mcp/live and can answer questions like “why did this customer’s payment fail?” or “did last night’s renewals run?” against your real account — under a grant that is scoped, revocable, and physically incapable of writing.

This is strictly safer than the alternative people reach for: pasting a sk_live_ key into an agent’s config. A live key can move money; this grant cannot, and you can kill it at any time from the dashboard.

Connecting

Live mode is OAuth-only — there is no API-key path. In Claude Code:

claude mcp add --transport http elasticpay-live https://mcp.elasticpay.co/mcp/live

Then /mcp → Authenticate, as with the sandbox connect. The consent screen is explicit about what you’re approving:

Approving grants this application read-only access to the live account you choose below. It cannot create or change anything, refund, or move money.

With a single live account, the screen names it instead of offering a choice. Either way the connection reads that one account; to read another, reconnect and choose it on the consent screen.

Connecting requires an active live account — organisations that haven’t gone live yet are directed back to the dashboard. Verify with whoami:

{
  "auth": "oauth",
  "mode": "live",
  "access": "read-only",
  "biller_id": "acct_…",
  "biller_name": "Your Business",
  "organisation_id": "org_…"
}

What the agent can do — and can’t

The live server exposes the documentation tools plus ten read tools: whoami, list_customers, get_customer, list_customer_payment_intents, list_payment_methods, get_payment_intent, list_payment_plans, get_payment_plan, list_plan_payment_intents, and list_webhook_events — parameters in the tool reference.

What it cannot do is not a policy layered on top — the write tools do not exist on this server (nor do the customer-import and payment-plan-import tools, which are sandbox-only until live enablement ships), the OAuth grant carries a read-only permission set enforced by the API on every call, and the token is bound to the live server so it is rejected outright if presented to the sandbox write endpoint. Card data stays tokenised throughout: reads return masked details only.

The triage flow

Operator questions are answered events-first — the webhook event feed is the source of truth for what happened; the resource fetches explain why:

1. list_webhook_events with event_type: "payment_intent.failed" — what failed, and whether your webhook endpoint was successfully notified.
2. get_payment_intent on the failing intent — status, amounts, and failure detail.
3. get_customer / list_customer_payment_intents — is this customer’s history a pattern or a one-off?
4. For recurring trouble: get_payment_plan and list_plan_payment_intents show what a plan has generated and how each attempt fared.

Revoking access

Every connection your organisation has approved is listed in the dashboard under Connected apps — in the account menu, or via the link on the Settings page — one row per application and account, with the connection’s flavor (sandbox or live read-only) and a Disconnect. Disconnecting removes the application from that account only; its other accounts’ connections keep working. The disconnected agent’s next call fails, and reconnecting requires a fresh consent.