PayMongo HomeGuidesAPI ReferenceStart Building
Guides

Use Cases

The PayMongo MCP server is most useful when you need to interact with PayMongo data conversationally — without switching to the Dashboard or constructing API calls manually. This page walks through practical examples of what that looks like across common scenarios.

Investigating a failed payment

When a customer reports a failed payment, the typical workflow involves pulling up the Dashboard, searching for the transaction, checking the payment status, and cross-referencing the error code. With the MCP server, the same investigation happens in a single conversation.

Example prompts

  • "Look up payment pay_xxxxxxxxxxxxxxxxxxxxxxxx and tell me why it failed."
  • "Find the most recent failed payment for 500 PHP and show me the error details."
  • "What payments failed in the last 24 hours?"

The MCP server retrieves the payment object, surfaces the relevant error code and detail, and lets you ask follow-up questions in the same context — for example, whether a refund was already issued, or whether the customer attempted payment again.

Issuing a refund

Refunds typically require navigating to a specific payment in the Dashboard or making a correctly structured API call. With the MCP server, you can issue a refund directly from a conversation — with the AI handling the API call after you confirm the action.

Example prompts

  • "Issue a full refund for payment pay_xxxxxxxxxxxxxxxxxxxxxxxx."
  • "Refund 250 PHP from pay_xxxxxxxxxxxxxxxxxxxxxxxx with reason 'requested by customer'."
  • "Find the payment for Order #4821 and refund it in full."

Because refunds are write actions, your AI host will ask for explicit confirmation before executing. The MCP server returns the refund object on success — including the refund ID and status — so you have an immediate record of the action taken.

Summarizing payout activity

Reconciling payouts against expected settlements usually means exporting data from the Dashboard or querying the API with date filters. The MCP server lets you ask for summaries in plain language and drill down without leaving the conversation.

Example prompts

  • "Show me all payouts from the last 7 days."
  • "How much was settled last week? Break it down by day."
  • "Are there any failed payouts in the last month?"

This is particularly useful for operations and finance teams who need regular visibility into payout status without direct API access — the MCP server handles the query, and the AI presents the result in a readable format.

Monitoring disputes

Disputes require timely responses — missing a response window can result in an automatic loss. The MCP server lets you query open disputes, check their status, and surface the details you need to prepare a response without navigating between multiple Dashboard views.

Example prompts

  • "List all open disputes."
  • "Show me the details for dispute dsp_xxxxxxxxxxxxxxxxxxxxxxxx."
  • "Which disputes are closest to their response deadline?"

Debugging webhook delivery

When an expected webhook event doesn't arrive — or your handler behaves unexpectedly — the MCP server lets you inspect event history and webhook endpoint configuration without leaving your development environment.

Example prompts

  • "Show me the last 10 payment.paid events."
  • "Did event evt_xxxxxxxxxxxxxxxxxxxxxxxx get delivered successfully?"
  • "List all my registered webhook endpoints and their current status."

For deeper delivery inspection — including payload logs and retry history — use the Dashboard event log alongside the MCP server. The MCP server is best suited for querying event data; the Dashboard gives you the full delivery audit trail.

Managing webhook endpoints

Endpoint configuration tasks — enabling, disabling, and updating subscriptions — can be handled conversationally without switching to the Dashboard or constructing API calls.

Example prompts

  • "Disable the webhook endpoint wh_xxxxxxxxxxxxxxxxxxxxxxxx."
  • "Update endpoint wh_xxxxxxxxxxxxxxxxxxxxxxxx to also listen for refund.succeeded events."
  • "Which of my webhook endpoints are currently disabled?"

Endpoint updates and status changes are write actions and require confirmation before the MCP server executes them.

Accelerating development and debugging

During active development, the MCP server reduces the friction of switching between your editor, the Dashboard, and API documentation. You can query test data, inspect resource states, and verify integration behavior without leaving your AI-powered development environment.

Example prompts

  • "Show me the last payment intent created in test mode."
  • "What's the current status of payment intent pi_xxxxxxxxxxxxxxxxxxxxxxxx?"
  • "List all events from the last hour in test mode."

This is most useful during integration testing, where rapid iteration between code changes and data inspection shortens the feedback loop significantly.

What the MCP server is not for

A few things worth clarifying to set accurate expectations.

It is not a substitute for the API in production workflows. The MCP server is designed for interactive, conversational use — human-in-the-loop scenarios where the goal is speed and convenience. Automated, high-volume, or latency-sensitive workflows should use the PayMongo API directly.

It does not surface data outside your API key's permissions. The MCP server operates within the same access boundaries as the API key used to authenticate the session. It cannot access data from other accounts or environments.

It does not replace the Dashboard for full operational management. Some tasks — such as reviewing full delivery logs, managing team access, or configuring account settings — are better handled in the Dashboard. The MCP server complements the Dashboard; it does not replace it.