Give an agent a key, and keep the decisions.

Payments.lk runs an MCP server, so Claude, Cursor, VS Code, Codex or your own code can read your payments, summarise a day and make payment links. Anything that moves money is prepared by the agent and approved by a person in the dashboard, every time.

Open the dashboard See a working sample

Connect in a minute

Issue an agent key in the dashboard under AI agents, name it for the agent you are connecting, tick what it may do, and paste it in. The endpoint is https://api.payments.lk/mcp and the key travels as a bearer token.

Claude Code

claude mcp add --transport http payments-lk https://api.payments.lk/mcp \
  --header "Authorization: Bearer ak_test_YOUR_AGENT_KEY"

Cursor, Windsurf and most desktop agents

{
  "mcpServers": {
    "payments-lk": {
      "url": "https://api.payments.lk/mcp",
      "headers": { "Authorization": "Bearer ak_test_YOUR_AGENT_KEY" }
    }
  }
}

Codex CLI, with the key in an environment variable

[mcp_servers.payments-lk]
url = "https://api.payments.lk/mcp"
bearer_token_env_var = "PAYMENTS_LK_AGENT_KEY"

The Claude API, with the beta header anthropic-beta: mcp-client-2025-04-04

{
  "model": "claude-sonnet-5",
  "max_tokens": 1024,
  "messages": [{ "role": "user", "content": "How did we do today?" }],
  "mcp_servers": [
    {
      "type": "url",
      "url": "https://api.payments.lk/mcp",
      "name": "payments-lk",
      "authorization_token": "ak_test_YOUR_AGENT_KEY"
    }
  ]
}

Claude.ai, the Claude apps and ChatGPT connect custom servers by signing in rather than by pasting a key. That sign in is what we are building next.

Twelve tools

get_accountneeds read: Status, whether live payments are on, the plan and this month's usage against its monthly limit, the rates in force, and what the key may do.
list_paymentsneeds read: Payments over a period, by status, customer or amount.
get_paymentneeds read: One payment with every refund on it, the fee and the net.
list_refundsneeds read: Refunds over a period, by status or payment.
list_payment_linksneeds read: Your links, their URLs, and how many payments each has taken.
list_eventsneeds read: The same event log your webhooks deliver.
summarise_dayneeds read: Takings, fees, net, failures and refunds for one Sri Lankan calendar day, as figures and one sentence.
search_docsneeds read: Search what Payments.lk publishes about itself, so the agent quotes rather than recalls.
get_actionneeds read: Whether something the agent prepared is waiting, approved, executed, failed, declined or expired.
create_payment_linkneeds links: Make a link for an amount and a title. Moves no money by itself.
retire_payment_linkneeds links: Stop a link taking payments.
refund_paymentneeds refunds: Prepare a refund for a person to approve. Nothing is refunded by this call.

Two more follow when the data behind them exists: get_payout once Payable’s settlement feed is connected, and respond_to_dispute with dispute intake. A tool that invents an answer is worse than a missing one.

A refund, end to end

You ask the agent to refund Rs. 1,000 on a customer’s order.
The agent prepares it and hands back a link. Nothing has been refunded.
You open that link, read one sentence, and press Approve.
The refund is made as you, through the same path as the refund button on the payment.
The agent sees the outcome through get_action, and your webhook receives refund.succeeded.

A prepared refund waits 24 hours and then lapses. At most 20 can wait at once, so a key that is not behaving cannot bury the real ones.

What a key can do

read: On every agent key. Payments, refunds, links, events, the account and a day's summary, with customer names and contact details masked.
customers: Whole names, emails and phone numbers instead of masked ones. Tick it only if the agent needs them, because those details leave for a model we do not run.
links: Create and retire payment links. No money moves.
refunds: Prepare refunds for you to approve. Preparing is not refunding.

Built for a key that leaks

An agent key ends up in a settings file on somebody’s machine. So the design assumes one day it gets out, and bounds what that is worth.

Every key ends on a date
You choose 30, 90 or 365 days when you issue it. A key nobody remembers stops working by itself.
Revoking reaches backwards
It stops the agent at once, and also stops anything that key has already asked you to approve.
One key, one mode
A sandbox key sees sandbox payments only. It cannot practise on real money or report test figures as real.
It opens this server and nothing else
An agent key is refused everywhere on the REST API, so a leaked one never becomes a secret key.
Customer details are masked
Unless you tick customer details. Searching still matches the whole email or phone, so the agent stays useful.
Every call is in your audit trail
With the tool, the outcome and which key made it, listed on the AI agents page.

Already readable by agents

Separately from the server, every fact about Payments.lk is published in a form a model can quote, so when a founder asks which Sri Lankan gateway to use, the answer can be checked. The search_docs tool reads the same text.