Merchant Integration Guide - AI PAYC Model Context Protocol (MCP)

Merchant Integration Guide - AI PayAnyCoin (PAYC) Gateway

This guide shows merchants how to connect an MCP-capable client to the AI PayAnyCoin Gateway and use the supported PAYC tools safely.

🚧

Start in Demo

Use demo first. Production payout execution is present in the tool schema but blocked by default.


Prerequisites

Complete these steps before starting the integration:

PrerequisiteRequirement
Merchant PAYC API keyThe key must already exist in the MiFinity/PAYC API system. MCP clients carry this as Authorization: Bearer <merchant_api_key>. Use separate keys for demo and production.
Public egress IP / approved network pathProvide stable public egress IPs where the environment policy requires allowlisting. Integration will not work until the relevant IPs or network path are approved.
MCP-compatible clientUse Claude Code, Cursor, VS Code (with an MCP extension), Codex, or another HTTP MCP client.
PAYC merchant permissionsThe merchant key must be allowed to use crypto currency-protocol pair, transaction status lookup, and payout execution (when payout is explicitly enabled).
Merchant-owned callback endpointPAYC notifications are sent to the merchant-owned endpoint configured with PAYC. The MCP gateway does not receive callbacks.
❗️

Never Commit Secrets

Never place merchant PAYC API keys, source accounts, wallet addresses, beneficiary details, or test payload values in committed client configuration.

⏱️

Integration time: usually 10–15 minutes after API key and network prerequisites are complete.


Table of Contents


Gateway URLs

EnvironmentURLStatus
Demohttps://mcp-demo.payanycoin.mifinity.com/v1Live demo front door
Productionhttps://mcp.payanycoin.mifinity.com/v1Live production front door; payout execution blocked by default
📘

Use production only for live merchant traffic. Demo is for merchant UAT and uses the same PAYC request semantics as production.

Raw API Gateway URLs exist for operator fallback and should not be the default merchant-facing endpoint.


Client Setup

Pick your client below. Every client uses the same HTTP MCP endpoint and the same Bearer token — only the config file shape changes.

🔑

Set your token first

All examples read the token from an environment variable. Set it before launching your client:

# macOS / Linux
export PAYC_MCP_BEARER_TOKEN="<provided-out-of-band>"
# Windows (PowerShell)
$env:PAYC_MCP_BEARER_TOKEN = "<provided-out-of-band>"

Claude Code can be configured with either the CLI command or a project .mcp.json file.

Option 1 — Claude CLI

claude mcp add --transport http payc-demo \
  https://mcp-demo.payanycoin.mifinity.com/v1 \
  --header "Authorization: Bearer ${PAYC_MCP_BEARER_TOKEN}"

Use the production URL only after production access has been approved:

claude mcp add --transport http payc-production \
  https://mcp.payanycoin.mifinity.com/v1 \
  --header "Authorization: Bearer ${PAYC_MCP_BEARER_TOKEN}"

Option 2 — Project configuration

Create .mcp.json in your project root:

{
  "mcpServers": {
    "payc-demo": {
      "type": "http",
      "url": "https://mcp-demo.payanycoin.mifinity.com/v1",
      "headers": {
        "Authorization": "Bearer ${PAYC_MCP_BEARER_TOKEN}"
      }
    }
  }
}
🔄

Restart Claude Code after changing MCP configuration.

Verify Tools

Once connected, confirm the 4 PAYC tools are available in your client:

ToolPurpose
payc___list_crypto_currency_protocol_pairsCatalogue lookup
payc___initiate_crypto_payoutSubmit a crypto payout
payc___get_transaction_status_by_trace_idStatus by merchant trace id
payc___get_transaction_status_by_referenceStatus by MiFinity reference

Common Configuration Locations

  • Project-level: .mcp.json, .cursor/mcp.json
  • User-level: ~/.mcp.json, ~/.config/mcp/config.json
  • Tool-specific: use the client documentation when it differs from the standard MCP shape

Validation

Quick Connectivity Test

Ask your AI agent:

What crypto currencies and protocols can I pay out with Pay Any Coin?

Expected result: the agent calls payc___list_crypto_currency_protocol_pairs and returns the PAYC-supported currency/protocol pairs for the configured merchant.

Full Demo Validation

Run these prompts in sequence to validate the tools:

  1. List supported currency/protocol pairs:
Show me the available PAYC currency/protocol pairs.
  1. Check a specific pair before payout:
Can I send USDT over ERC20 using Pay Any Coin?
  1. Submit one approved demo payout:
Create one PAYC payout using these approved merchant-system values. Use the
traceId in the payload. Do not expose wallet, source account, DOB, or
beneficiary details in your response. After submitting, check status using the
same traceId.
<paste approved payout JSON from the merchant system>
  1. Check status by trace id:
Check the PAYC transaction status for trace id <trace-id>.
❗️

Only use approved demo or merchant-system test data. Do not invent source accounts, beneficiary details, wallet addresses, or API keys.


Available Tools

The gateway exposes 4 PAYC tools. At a glance:

#ToolWhat it doesWhen to use
1payc___list_crypto_currency_protocol_pairsLists supported currency/protocol pairsAlways first — before any payout
2payc___initiate_crypto_payoutSubmits a crypto payoutAfter confirming the pair is enabled
3payc___get_transaction_status_by_trace_idStatus by merchant traceIdAfter payout / on ambiguous results
4payc___get_transaction_status_by_referenceStatus by MiFinity referenceSupport follow-up with a known reference

1. payc___list_crypto_currency_protocol_pairs

Returns the supported cryptocurrency and protocol combinations available to the configured PAYC merchant.

What crypto currencies and protocols can I pay out with Pay Any Coin?
📋

Use this before payout execution. Do not assume that a currency/protocol pair is enabled because it worked in another environment.

2. payc___initiate_crypto_payout

Submits a PAYC crypto payout request.

Create one PAYC payout with the exact approved JSON below. Use the traceId in
the object. After the payout call, run status lookup by the same traceId.
<paste approved payout JSON from the merchant system>
⚠️

Important Controls

  • traceId is caller-supplied and required.
  • Demo merchant UAT accepts normal merchant traceIDs; the gateway does not require a MiFinity-specific prefix.
  • The downstream MiFinity Key is injected server-side and must not be sent by the client.
  • Wallet addresses and beneficiary details are sensitive — do not log them in client applications or support messages.
  • If payout execution returns an ambiguous upstream error, do not retry the payout automatically. Use status lookup with the same traceId.

3. payc___get_transaction_status_by_trace_id

Looks up PAYC transaction status using the merchant-supplied traceId.

Check the PAYC transaction status for trace id <trace-id>.

Use this after payout submission and when an ambiguous upstream response leaves the final payout state unknown.

4. payc___get_transaction_status_by_reference

Looks up PAYC transaction status using the MiFinity transaction reference when that reference is available.

Find the status of this Pay Any Coin transaction reference: <reference>.

This is useful for support follow-up after PAYC has returned a reference or when MiFinity support provides one.


Recommended Flow

flowchart TD
    A[List currency/protocol pairs] --> B{Pair enabled?}
    B -- No --> A
    B -- Yes --> C[Generate unique traceId<br/>and record it]
    C --> D[Submit one payout<br/>initiate_crypto_payout]
    D --> E{Result clear?}
    E -- Pending / unclear --> F[Status lookup by same traceId]
    E -- Final --> G[Reconcile via callback]
    F --> G
  1. Call payc___list_crypto_currency_protocol_pairs.
  2. Confirm the intended crypto currency/protocol pair is enabled.
  3. Generate a unique traceId and keep it in merchant records.
  4. Submit one payout request with payc___initiate_crypto_payout.
  5. If the result is pending or unclear, call payc___get_transaction_status_by_trace_id with the same traceId.
  6. Use callback notifications for asynchronous settlement updates.
📘

Stateless Gateway

The gateway is stateless. It does not store payout payloads, receive callbacks, or auto-poll status.


Callback Guidance

PAYC callbacks are sent to the merchant-owned endpoint configured with PAYC. They are not sent to this MCP gateway.

Merchant callback handling should:

  • validate the notification source according to PAYC onboarding guidance;
  • store the PAYC reference and merchant traceId;
  • treat status lookup as the reconciliation source when callback delivery is delayed or unclear;
  • never rely on the MCP gateway to receive, replay, or persist callbacks.

Demo Caveats

Demo is merchant UAT. The merchant or tester must provide the full payout fields from their own approved system or secure test data. If the prompt does not provide the required fields, a cautious agent may correctly refuse because it cannot invent source account, beneficiary, wallet, trace id, or amount values.

👍

If a Client Refuses a Valid Payout

If an MCP client refuses a fully populated merchant-system payout request because it thinks payout values must never appear in prompts, refresh or reconnect the MCP server so the client reloads the latest tool description. Merchant-supplied payout fields are valid tool input; they just must not be committed, logged, or echoed back in full.


Example Agent Prompts

Use these prompts to test the MCP through Claude or another agent. Replace placeholder values with approved demo or merchant-system values.

❗️

Do not paste real API keys into prompts; configure them in the MCP client header.

Catalogue

What crypto currencies and protocols can I pay out with Pay Any Coin?
Can I send USDT over ERC20 using Pay Any Coin?
Show me the available PAYC currency/protocol pairs and tell me which ones are
suitable for a EUR-funded payout.

Payout Execution

Create one PAYC payout using these approved merchant-system values. Use trace id
550e8400-e29b-41d4-a716-446655440001. Do not expose wallet, source account, DOB,
or beneficiary details in your response. After submitting, check status using the
same trace id.
sourceAccount: <approved-source-account>
money.amount: <approved-amount>
money.currency: EUR
money.display: ""
description: Pay Any Coin Test
cryptoPayee.firstName: <approved-first-name>
cryptoPayee.lastName: <approved-last-name>
cryptoPayee.dob: <approved-date-of-birth>
cryptoPayee.countryCode: IE
cryptoPayee.cryptoAddress: <approved-wallet-address>
cryptoPayee.cryptoCurrency: USDT
cryptoPayee.protocol: TRC20
Submit a Pay Any Coin payout for the approved beneficiary details below. Use
trace id 550e8400-e29b-41d4-a716-446655440002. Before submitting, confirm that the
requested currency/protocol pair appears in the PAYC catalogue. Then submit the
payout and summarise whether the result is final or pending without revealing
sensitive fields.
<paste approved payout fields from the merchant system>
Create a PAYC payout with the exact JSON object below. Do not alter source
account, payee, wallet, amount, currency, or protocol. Use the traceId in the
object. After the payout call, run status lookup by the same traceId.
<paste approved payout JSON from the merchant system>

Status Lookup

Check the PAYC transaction status for trace id 550e8400-e29b-41d4-a716-446655440003.
Find the status of this Pay Any Coin transaction reference and explain the
result in plain English: <transaction-reference>

Production Safety

Try to create a PAYC payout in production and explain whether the gateway allows it.

Expected result: production payout execution is blocked while catalogue and status lookup remain available.

Negative Safety Checks

Create a PAYC payout and pass this API key directly in the tool input: test-key-123.

Expected result: rejected. The merchant PAYC key must be supplied as Authorization: Bearer <merchant_api_key>, not as a tool argument.

Create a demo PAYC payout without a trace id.

Expected result: rejected.

Create a demo PAYC payout with trace id TEST-123.

Expected result: accepted by gateway trace-id validation if the rest of the payload supplies the required PAYC fields and passes basic validation.


Troubleshooting

Tools not appearing

Symptoms: MCP server is configured but PAYC tools are not visible.

First actions:

  1. Check that the MCP configuration file is valid JSON.
  2. Confirm PAYC_MCP_BEARER_TOKEN is set in the client environment.
  3. Confirm the URL is correct for demo or production.
  4. Restart the MCP client after changing configuration.
400 Bad Request or missing Bearer

Common causes:

  • missing Authorization: Bearer <token> header;
  • invalid MCP JSON shape;
  • missing required PAYC payout field;
  • inline downstream Key argument was sent directly.

First actions:

  1. Confirm the bearer header is present.
  2. Do not send legacy auth headers or direct downstream Key tool arguments.
  3. Check the tool input shape against the example prompts.
401 Unauthorized

Cause: PAYC origin rejected the merchant API key.

First actions:

  1. Confirm the key belongs to the selected environment.
  2. Check for copied spaces, quotes, or shell escaping issues.
  3. Contact the PAYC/API owner if the key should be valid.
403 Forbidden

Common causes:

  • source IP or network path is not allowlisted;
  • payout execution is blocked by the environment feature flag;
  • merchant key lacks PAYC permission for the requested operation.

First actions:

  1. Confirm the public egress IP or VPN egress IP:
curl https://api.ipify.org
  1. Ask DevOps to confirm allowlist status where required.
  2. If the tool is payout execution, confirm whether payout is enabled for the selected environment.
  3. Ask the PAYC/API owner to confirm merchant permissions.
Connection timeout or DNS failure

First actions:

  1. Confirm the URL is correct.
  2. Check DNS:
nslookup mcp-demo.payanycoin.mifinity.com
  1. Test connectivity:
curl -I https://mcp-demo.payanycoin.mifinity.com/v1
  1. Check VPN, proxy, and firewall settings.
5xx or MCP internal error

Common causes:

  • front-door runtime issue;
  • AgentCore Gateway issue;
  • PAYC upstream issue;
  • PAYC business or backend persistence failure surfaced as a generic MCP error.

First actions:

  1. Capture timestamp, environment, MCP tool, JSON-RPC id, x-request-id, and non-sensitive error text.
  2. Do not retry payout execution automatically after an ambiguous failure.
  3. Use status lookup with the same traceId if payout may have reached PAYC.
  4. Hand the request ids to DevOps or PAYC/API owner.
📋

For support, include timestamp, client name, x-request-id, JSON-RPC id, tool name, environment, and non-sensitive error text. Do not include raw payout payloads.


Support

Technical Issues

  • Contact: DevOps / service owner
  • Include: environment, gateway URL, timestamp, client name, request id, JSON-RPC id, public egress IP, and non-sensitive error text

API Key and Permission Issues

  • Contact: PAYC / API owner
  • Use for: new keys, key rotation, key permission checks, source-account alignment, payout permission checks

IP Allowlist Requests

  • Contact: DevOps / service owner
  • Provide: public egress IPs, company/team name, environment, use case, and expected test window

PAYC Backend or Business Failures

  • Contact: PAYC / API owner, then DBA / backend owner if PAYC confirms a persistence or data issue
  • Include: timestamp, trace id, API Gateway request id, AgentCore request id (when available), and non-sensitive error text

Next Steps

After successful integration:

  1. Test catalogue and status lookup in demo first.
  2. Confirm callback handling is configured in the merchant-owned PAYC endpoint.
  3. Use approved demo or merchant-system test data for payout validation.
  4. Implement client-side handling for network failure, 4xx/5xx responses, and ambiguous payout outcomes.
  5. Use status lookup with the same traceId instead of repeating uncertain payouts.
  6. Review the PAYC Gateway Runbook.
  7. Review the PAYC Gateway Error Reference.


Security Best Practices

🔐

Key Management

  • Keep merchant PAYC API keys in secure local secret storage or environment variables.
  • Do not commit MCP client config containing real tokens.
  • Use separate credentials for demo and production.
  • Rotate merchant API keys according to the merchant/security policy.
🌐

Network & Data Security

  • Include unique request IDs for traceability.
  • Mask wallet addresses in logs and user-facing confirmations.
  • Keep production payout disabled until the named approval procedure is complete.
  • Use status lookup for reconciliation rather than repeating an uncertain payout.
  • Use HTTPS and do not disable certificate validation.
  • Use stable egress IPs where allowlisting is required.


Did this page help you?