Payments — Frege

← All use cases

The real problem is not generation

Most payment platforms do not struggle to describe their API. They already have OpenAPI specs, webhooks, merchant documentation, and authentication models. The hard part is exposing all of that to AI clients safely, across versions, without building a different adapter for every tool.

Refunds and writes need boundaries. A support workflow may need transaction lookups but not irreversible money movement.
Specs evolve constantly. New endpoints, changed schemas, and versioned behavior cannot silently break downstream AI clients.
Merchants need their own credentials. A single integration must still preserve strict tenant and organization boundaries.
Events matter as much as tools. Payment success, failure, chargeback, and payout lifecycle events should not disappear outside request/response flows.

How Frege fits a payments platform

Frege starts from your existing OpenAPI spec and docs. It turns operations into MCP tools, publishes markdown through a dedicated docs endpoint, and lets you expose both through one governed project. From there you control who can see which tools, which docs, and which versions.

Versioning that matches real release cycles

Every publish becomes an immutable version. Teams can compare versions, detect breaking changes, roll back quickly, and pin clients to explicit routes like /mcp/acme/payments/v2/tools while migrations happen on their own schedule.

Per-tool authorization for high-risk operations

Read-heavy tools like listPayments or getInvoice can be widely available while sensitive operations like refundPayment or captureCharge stay restricted to specific keys, users, or temporary grants.

Merchant-specific credentials

Each downstream organization can store its own encrypted target credentials. Frege resolves the calling organization, decrypts the correct credential in memory, and applies it through the outbound auth adapter automatically.

Webhook-driven MCP notifications

Payments are eventful systems. Frege parses OpenAPI webhook definitions, receives signed deliveries, and delivers them in-process as MCP notifications — so connected MCP sessions subscribe to events like settlement, payment failure, or dispute creation.

What this looks like in practice

A support agent asks Claude about a payment. Claude lists available tools through the MCP endpoint, reads docs when needed, then calls the governed tools Frege exposes for that merchant and role.

User: Show me the last 5 payments for customer cust_7Kx2

→ tools/list
→ payments.list({ "customer_id": "cust_7Kx2", "limit": 5 })

Assistant: Here are the last 5 payments:

  pay_9f2k  250,000 UZS  completed  Apr 13 09:14
  pay_a3mw  180,000 UZS  completed  Apr 13 11:42
  pay_b7xt  420,000 UZS  refunded   Apr 12 14:08
  pay_c1np   95,000 UZS  completed  Apr 11 16:30
  pay_d8qr  310,000 UZS  failed     Apr 10 08:55

Why payment teams care

Faster rollout: expose MCP from the OpenAPI spec you already maintain.
Safer change control: publish, diff, roll back, and pin by version.
Better merchant isolation: separate org credentials and scoped access.
More complete product surface: tools, docs, and webhook events all arrive in the same runtime model.

Turn your payments API into governed MCP infrastructure.