🛒 Digital Goods MCP live

AI agents can now sell software, online courses and digital products through a merchant of record — with global sales tax / VAT handled. One remote MCP server, one set of tools, eight merchant-of-record platforms switched with a provider parameter: Paddle Billing, Lemon Squeezy, Polar, Whop, Creem, Dodo Payments, FastSpring and 2Checkout (Verifone). The merchant of record is the legal seller and remits tax worldwide; this server just forwards the calls and never touches funds.

Why merchant of record (and how it complements payments)

The local-payments family is for merchants who are their own seller of record and handle their own tax. This server is the complement: a merchant-of-record platform becomes the legal seller for your digital product, so an independent developer or creator selling via an AI agent does not register for tax in every country — the MoR calculates, collects and remits it.

Connect

{
  "mcpServers": {
    "digital-goods": {
      "type": "http",
      "url": "https://mor.wishpool.app/mcp",
      "headers": {
        "x-mor-provider": "polar",
        "x-mor-key": "your-platform-api-key",
        "x-mor-env": "sandbox"
      }
    }
  }
}

Get your key from the platform: Paddle (pdl_..., Developer Tools > Authentication), Lemon Squeezy (Settings > API), Polar (polar_oat_..., Settings > Developers), Whop (Dashboard > Developer), Creem (creem_test_..., Dashboard > Developers), Dodo Payments (Dashboard > Developer), FastSpring (Developer Tools > APIs — send x-mor-key as username:password for HTTP Basic auth), or 2Checkout (Control Panel > Integrations > Webhooks & API — send x-mor-key as MERCHANT_CODE:SECRET_KEY for the HMAC-SHA256 header). x-mor-env defaults to sandbox/test (no real money); use prod/live for real sales.

Tools

• create_checkout — hosted checkout link for a catalog item (Paddle price_id, Lemon Squeezy variant_id + store_id, Polar product_id, Whop plan_id, Creem product_id, Dodo product_id, FastSpring product path + store_id storefront, 2Checkout catalog product code). Returns checkout_url.
• query_order — unified order/transaction status: PAID / PENDING / FAILED / REFUNDED / PARTIALLY_REFUNDED / CANCELED / PAST_DUE + raw passthrough.
• issue_refund — Paddle full-only, Lemon Squeezy partial/full, Polar amount + reason, Dodo full-only, FastSpring full-only, 2Checkout partial or full; Whop & Creem refunds are dashboard-only (honestly reported as not supported via API).
• query_subscription / cancel_subscription — unified subscription status; cancel semantics differ per provider (documented).

Capability matrix (honest limits)

Registration & approval — disclosed honestly

• Paddle: production selling requires a Paddle-verified seller account (seller verification / KYC). Sandbox works immediately. This is Paddle's gate, not this server's.
• Lemon Squeezy: acquired by Stripe (2024); long-term it may steer sellers to Stripe Managed Payments. Works today.
• Polar: sandbox works immediately; production payout / KYC onboarding is not yet verified end-to-end.
• Whop: sign-up is immediate (create a company + plan, mint an API key). No sandbox host — production API only; test with a test/dev company. Refunds are dashboard-only.
• Creem: sign-up is immediate; test mode + creem_test_ keys on test-api.creem.io work right away. Refunds are dashboard-only.
• Dodo Payments: the test host works immediately; production selling requires KYC / business verification (typically 24–72h, Dodo's gate).
• FastSpring: after opening a store you create API credentials (HTTP Basic username:password) in Developer Tools > APIs. No separate sandbox host — test with a Test storefront.
• 2Checkout (Verifone): a new account is in DEMO mode (a built-in sandbox) instantly; going live requires Verifone to manually activate the account (their gate). Credentials are the Merchant Code + API Secret Key (MERCHANT_CODE:SECRET_KEY) with a custom HMAC-SHA256 auth header. Checkout is a locally-built ConvertPlus buy-link — signed buy-links / dynamic pricing need the separate Buy-Link Secret Word, which this stateless layer does not hold.
• Gumroad: intentionally not included — its API is capability-limited and its docs block automated access.

Why it is safe

• Stateless: no database — your API key travels per-request in a header and is never stored. Money always flows buyer → merchant of record → you.
• Owner policy guardrails: x-agentpay-max-amount, x-agentpay-approval-above, x-agentpay-allowed-tools — set by the human owner in client config; the agent cannot relax them. Applied to the amount on create_checkout / issue_refund.

One family

Local payments in 81 countries — mcp.wishpool.app. E-invoicing (Malaysia MyInvois, Saudi ZATCA, Poland KSeF, Mexico CFDI, Chile DTE, Brazil NF-e, Peru CPE, India GST) — inv.wishpool.app. Shipping & logistics — logi.wishpool.app. Same stateless bring-your-own-key pattern.

Trust & security

No database: your keys travel in a request header, are used once, and are never stored. We never hold funds and never take a cut. On rails that require cryptographic signing, you sign and we relay — the private key never leaves your side. Every server is MIT-licensed and self-hostable. Threat model, credential map and known limits: mcp.wishpool.app/trust.