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 DemoUse demo first. Production payout execution is present in the tool schema but blocked by default.
Prerequisites
Complete these steps before starting the integration:
| Prerequisite | Requirement |
|---|---|
| Merchant PAYC API key | The 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 path | Provide 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 client | Use Claude Code, Cursor, VS Code (with an MCP extension), Codex, or another HTTP MCP client. |
| PAYC merchant permissions | The 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 endpoint | PAYC notifications are sent to the merchant-owned endpoint configured with PAYC. The MCP gateway does not receive callbacks. |
Never Commit SecretsNever 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
- Client Setup — Claude Code · Cursor · VS Code · Codex · Other
- Validation
- Available Tools
- Recommended Flow
- Callback Guidance
- Demo Caveats
- Example Agent Prompts
- Troubleshooting
- Support
- Next Steps
- Security Best Practices
Gateway URLs
| Environment | URL | Status |
|---|---|---|
| Demo | https://mcp-demo.payanycoin.mifinity.com/v1 | Live demo front door |
| Production | https://mcp.payanycoin.mifinity.com/v1 | Live 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 firstAll 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.
VS Code requires an MCP-capable extension. Common options include Continue.dev or another extension that supports HTTP MCP servers.
Continue.dev example
- Install the Continue extension in VS Code.
- Open the Continue configuration.
- Add the PAYC MCP server:
{
"mcpServers": [
{
"name": "payc-demo",
"type": "http",
"url": "https://mcp-demo.payanycoin.mifinity.com/v1",
"headers": {
"Authorization": "Bearer ${PAYC_MCP_BEARER_TOKEN}"
}
}
]
}
Restart VS Code after setting the environment variable and changing MCP configuration.
Codex configuration varies by runtime. Use this general HTTP MCP pattern:
{
"mcp_servers": {
"payc-demo": {
"type": "http",
"url": "https://mcp-demo.payanycoin.mifinity.com/v1",
"headers": {
"Authorization": "Bearer ${PAYC_MCP_BEARER_TOKEN}"
}
}
}
}
Restart the Codex instance after updating configuration.
Most MCP clients follow the same pattern:
{
"mcpServers": {
"payc-demo": {
"type": "http",
"url": "https://mcp-demo.payanycoin.mifinity.com/v1",
"headers": {
"Authorization": "Bearer ${PAYC_MCP_BEARER_TOKEN}"
}
}
}
}All clients should send:
Authorization: Bearer <token>
Content-Type: application/jsonClients that support additional headers may also send:
x-request-id: <uuid>
Thex-request-idvalue is optional at the transport layer but strongly recommended — it is the fastest way to correlate API Gateway, Lambda, AgentCore, and Datadog evidence.
Verify Tools
Once connected, confirm the 4 PAYC tools are available in your client:
| Tool | Purpose |
|---|---|
payc___list_crypto_currency_protocol_pairs | Catalogue lookup |
payc___initiate_crypto_payout | Submit a crypto payout |
payc___get_transaction_status_by_trace_id | Status by merchant trace id |
payc___get_transaction_status_by_reference | Status 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:
- List supported currency/protocol pairs:
Show me the available PAYC currency/protocol pairs.- Check a specific pair before payout:
Can I send USDT over ERC20 using Pay Any Coin?- 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>- 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:
| # | Tool | What it does | When to use |
|---|---|---|---|
| 1 | payc___list_crypto_currency_protocol_pairs | Lists supported currency/protocol pairs | Always first — before any payout |
| 2 | payc___initiate_crypto_payout | Submits a crypto payout | After confirming the pair is enabled |
| 3 | payc___get_transaction_status_by_trace_id | Status by merchant traceId | After payout / on ambiguous results |
| 4 | payc___get_transaction_status_by_reference | Status by MiFinity reference | Support follow-up with a known reference |
1. payc___list_crypto_currency_protocol_pairs
payc___list_crypto_currency_protocol_pairsReturns 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
payc___initiate_crypto_payoutSubmits 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
traceIdis caller-supplied and required.- Demo merchant UAT accepts normal merchant traceIDs; the gateway does not require a MiFinity-specific prefix.
- The downstream MiFinity
Keyis 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
payc___get_transaction_status_by_trace_idLooks 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
payc___get_transaction_status_by_referenceLooks 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
- Call
payc___list_crypto_currency_protocol_pairs. - Confirm the intended crypto currency/protocol pair is enabled.
- Generate a unique
traceIdand keep it in merchant records. - Submit one payout request with
payc___initiate_crypto_payout. - If the result is pending or unclear, call
payc___get_transaction_status_by_trace_idwith the sametraceId. - Use callback notifications for asynchronous settlement updates.
Stateless GatewayThe 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 PayoutIf 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: TRC20Submit 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:
- Check that the MCP configuration file is valid JSON.
- Confirm
PAYC_MCP_BEARER_TOKENis set in the client environment. - Confirm the URL is correct for demo or production.
- 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
Keyargument was sent directly.
First actions:
- Confirm the bearer header is present.
- Do not send legacy auth headers or direct downstream
Keytool arguments. - Check the tool input shape against the example prompts.
401 Unauthorized
Cause: PAYC origin rejected the merchant API key.
First actions:
- Confirm the key belongs to the selected environment.
- Check for copied spaces, quotes, or shell escaping issues.
- 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:
- Confirm the public egress IP or VPN egress IP:
curl https://api.ipify.org- Ask DevOps to confirm allowlist status where required.
- If the tool is payout execution, confirm whether payout is enabled for the selected environment.
- Ask the PAYC/API owner to confirm merchant permissions.
Connection timeout or DNS failure
First actions:
- Confirm the URL is correct.
- Check DNS:
nslookup mcp-demo.payanycoin.mifinity.com- Test connectivity:
curl -I https://mcp-demo.payanycoin.mifinity.com/v1- 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:
- Capture timestamp, environment, MCP tool, JSON-RPC id,
x-request-id, and non-sensitive error text. - Do not retry payout execution automatically after an ambiguous failure.
- Use status lookup with the same
traceIdif payout may have reached PAYC. - 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:
- Test catalogue and status lookup in demo first.
- Confirm callback handling is configured in the merchant-owned PAYC endpoint.
- Use approved demo or merchant-system test data for payout validation.
- Implement client-side handling for network failure, 4xx/5xx responses, and ambiguous payout outcomes.
- Use status lookup with the same
traceIdinstead of repeating uncertain payouts. - Review the PAYC Gateway Runbook.
- 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.
Updated 7 days ago