An MCP server covering both of Autopay's integration models — Online v1.1's hosted redirect and WhiteLabel's API-driven flow — as seven callable tools: list channels, start a payment, verify the confirmation. No UI, no card data touching this server, no human required in the loop.
SHA256("1|11|91|11.11|PLN|1|20010101111111|SUCCESS|AUTHORIZED|1test1")
= a103bfe581a938e9ad78238cfc674ffafdd6ec70cb6825e7ed5c41787671efe4
Both flows sign requests with the same SHA256/512(fields | shared key) scheme and confirm payments through the same ITN XML mechanism — they differ only in how the payer reaches Autopay.
The merchant signs a request and sends the payer's browser straight to Autopay's hosted payment page. One tool: build the signed fields, redirect.
The merchant calls Autopay server-to-server to discover channels and required consents, then starts the transaction on its own UI.
Grouped by what they're for, not forced into one fake sequence — WhiteLabel's three steps run in order, Online v1.1 needs only one call, and the rest are for testing.
Wrapping a checkout in a conversational widget is easy for any competing PSP to copy through their own WhiteLabel integration. Exposing checkout as MCP tools is a different claim — that the integration is agent-native, not just human-native.
Being early here isn't about inventing something nobody else has — it's about being the obvious, working choice the moment an agent needs to check out with Autopay, before anyone else in our market has one.
Autopay's docs weren't written for this — some of it is verified byte-for-byte, some is a best-effort reconstruction, and some genuinely isn't documented anywhere. All three are marked, in the docs and in this code, rather than smoothed over.
Deployed at mcp.autopaylab.com — clone the repo to run it locally instead, or read the full setup (Bearer token, WhiteLabel host, real credentials) in the README.
claude mcp add --transport http autopay-checkout \ https://mcp.autopaylab.com/api/mcp