- MCP lets AI agents read your platform's operational data. Payneteasy uses the Model Context Protocol, an open standard, to let assistants query transaction statistics and related merchant, project, endpoint, gate and processor records. Through this interface, assistants cannot perform payment actions or change platform settings, and receive no raw PAN or CVV.
- What it does well today: transaction analytics (counts, amounts and ratios over time, by card type, by country and by decline/fraud reason, plus top-entity rankings), order-level lookup of a single transaction and its step-by-step processing trail, and fast navigation of your platform's reference data — finding the right merchant, project, endpoint, gate or processor and reading its configuration without clicking through the backoffice.
- Access without payment actions. Through Payneteasy MCP, the agent can query operational data but cannot authorise, capture, refund or change platform settings.
- Why now: AI assistants are starting to do real operational work. Payneteasy already exposes this read layer over its backoffice, so teams that wire it in early own the agent-native workflow before it becomes table stakes.
What MCP is
The Model Context Protocol (MCP) is an open standard for connecting AI agents to external systems. Instead of every assistant needing a custom plugin for every tool, an MCP server advertises the questions it can answer, and any MCP-capable client — Claude, Cursor, a coding agent — discovers and asks those questions over one common protocol.
Applied to the Payneteasy platform, the MCP server exposes the read side of your backoffice: the statistics your analysts already pull, and the merchant, project, endpoint, gate and processor records they already look up. It is a window for reading, not a lever for moving money.
You ask your AI assistant: Connect once with a scoped token,
then ask your AI assistant in plain words:
"Compare approved vs declined transaction volume
for merchant ACME this month, broken down by week."
The assistant's example answer: ACME, June 2026, weekly: approved turnover trending up week over week; declined count flat; filtered (fraud-blocked) share around 3% of attempts. (No payment actions were performed or settings changed.)
An example of how an assistant can use the platform's transaction statistics to answer a plain-language question.
What an AI agent can actually read
| Tool area | What the agent can answer | Example answer |
|---|
| Transaction summary | Sales, reversals, chargebacks, frauds and disputes for a date range — counts, amounts and decline/chargeback/fraud ratios, broken down by card type with a grand total | "May 2026: chargeback ratio 0.4%, fraud ratio 0.1%; Visa and Mastercard split shown, grand total included." |
| Transaction timeseries | Counts and amounts over time (per day/week/month), split by status — approved, declined, filtered | "Approved turnover by week for Q2, with declined and fraud-filtered series alongside." |
| Metric breakdown | A metric (turnover/sales/captures/transfers/auths/verifications) broken down as a bar chart — by status, by card-issuer country, by cardholder-IP country, or by decline/chargeback/fraud reason | "June declines by reason: insufficient funds leads, followed by do-not-honor and expired card." |
| Top entities | The top merchants, companies or processors ranked by a metric over a date range, highest first | "Top 10 merchants by turnover this quarter, largest first." |
All of these can be filtered by merchant, processor, manager, gate, currency and more — so a question like "how did approval rates move for this processor between May and June?" becomes a single query instead of an export-and-pivot exercise. Rankings and breakdowns return ids you can feed straight back in — drill from "top merchant this quarter" into that merchant's own numbers without leaving the conversation.
A note on precision. The statistics tools answer "how many / how much / what ratio / which ranks highest". When you need one specific transaction, the order tools below take over. The layer still carries no payout, settlement or per-dispute-case data — it answers operational and analytical questions, not bank-statement ones.
Individual orders
Statistics tell you the shape of the traffic; sometimes you need a single transaction — and the steps it went through. The MCP can now look one up and replay its processing trail.
| Tool | What the agent can answer |
|---|
| Order search | Find orders whose status changed within a date window — filterable by session status, merchant/processor/gate/endpoint/project, card type, currency, or an identifier (order id, merchant invoice number, customer id, amount). Returns safe order summaries with no cardholder PII. |
| Order details | Read one order in full: amounts, statuses, fraud/error flags, the customer's card metadata and masked contact, and the routing (endpoint/gate/processor/project) behind it. |
| Order logs | Read the processing trail of one order — its sessions and ordered stages, each with a timestamp and log message, so the agent can explain step by step how a payment progressed (or where it stopped). A fuller, unlimited trail is available on request. |
The privacy boundary is enforced by the token, not by trust: each section of an order's detail is returned only if the token is allowed to call the underlying API. Order search never exposes cardholder PII at all, and order details return card metadata and a masked contact — never a raw card number.
You ask your AI assistant: "Find the declined order for invoice INV-20455 last week, tell me why it
failed, and walk me through the steps."
The assistant's example answer: "Order for INV-20455, declined on 18 Jun: card type Visa, issuer country DE, decline reason 'insufficient funds', routed via the EU gate. Step trail: session opened → 3-DS requested → cardholder authenticated → authorisation sent to processor → declined (insufficient funds). Contact shown masked; no card number returned. (read-only — nothing was changed or charged.)"
Platform reference data
| Entity | What the agent can answer |
|---|
| Merchants | Find a merchant by name; read its profile, payment group and status |
| Projects | Find a project; read its manager, currency and rate plan |
| Endpoints | Find an endpoint; read its payment strategy, capture/return timeouts, form templates and flags |
| Gates | Find a gate; read its processor, manager, currency and rate plan |
| Processors | Find a processor; read its type/code, status and owning group |
| Managers / Superiors | Find platform users and read their profile and status |
Every one of these is search → read: the agent resolves a name to an id, then reads the record. None of it requires write access, and none of it touches card data.
Why this matters as AI agents grow up
The shift is from people clicking through the backoffice to assistants querying it directly. As agentic workflows move from concept to everyday operations, platform and operations teams will increasingly ask an assistant — not open six dashboards — "how did this processor's approval rate move this month?", "what's the chargeback ratio for this merchant by card type?", "which gate is this endpoint routed through?". Payneteasy MCP provides access to the operational data needed to investigate these questions. Platforms that wire it in now own the agent-native workflow before it becomes table stakes.
How it works, in practice
No manual coding — the agent simply connects and asks.
- Connect the agent. An MCP-capable assistant connects to the Payneteasy MCP server with a scoped token.
- It discovers the questions. The server exposes tools for querying transaction statistics, looking up orders and retrieving merchant, project, endpoint, gate and processor records.
- Plain-language answers. You ask in plain language. The assistant queries the available MCP tools and uses their results to prepare an answer.
The pattern that makes MCP safe to adopt
Three constraints define the read layer.
- NO PAYMENT OR CONFIGURATION CHANGES. Through Payneteasy MCP, the agent can query statistics, order information and configuration records. It cannot authorise, capture, refund, move money or change platform settings.
- NO RAW CARD DATA. The layer provides aggregates, configuration and order information — counts, amounts, ratios, statuses and routing details. The assistant may also receive card metadata and masked contact information, but no raw PAN or CVV.
- TOKEN-GOVERNED. Access runs through a scoped, time-bounded and revocable token, allowing teams to limit permissions and withdraw access when needed.
Where Payneteasy's MCP fits
Payneteasy MCP connects AI assistants to backoffice data, allowing teams to query transaction statistics, investigate individual orders and explore platform records — including merchants, projects, endpoints, gates and processors — in plain language. Access is controlled through a scoped token that can be revoked when needed. This helps operations, risk and support teams analyse payment activity while keeping payment actions and configuration changes outside the MCP interface.
