Skip to content
elasticpay

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/live/mcp 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:

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

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 your live account. It cannot create or change anything, refund, or move money.

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, 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 grant your organisation has approved is listed in the dashboard under Connected apps — in the account menu, or via the link on the Settings page — with the grant’s flavor (sandbox or live read-only) and a per-application Disconnect. Grants are organisation-wide, so disconnecting removes the application for every account at once; the agent’s next call fails and reconnecting requires a fresh consent.