Changelog

Every blog post, doc page, and the API reference now has a clean Markdown twin you can hand to ChatGPT, Claude, or your favorite IDE agent in one click.

Copy for LLM

A new button sits next to the title on every blog and doc page. It opens a dropdown with four shortcuts: copy the page as Markdown, view it as Markdown, open it in ChatGPT, open it in Claude. The last two prefill the chat with the URL of the Markdown version, so the model has the actual content to work with, not a screenshot of an HTML page.

API reference as Markdown

The full API reference is now available at /api/docs.md, rendered from the live OpenAPI spec. Paste the URL into any LLM and ask “how do I create a payment with channel attribution?”, you’ll get a grounded answer instead of a hallucination.

The Markdown versions of doc pages live at the same path with .md appended, e.g. /docs/getting-started.md. All of them are indexed in llms.txt for IDE agents.

Every customer transaction that lands on a payment is now recorded as a separate row and surfaced everywhere you look at the payment: the public payment page, the merchant dashboard, the admin detail page, and the webhook payload.

Why this matters

The old tx_hash field held one hash. If a customer underpaid and then topped up, you saw only the latest transaction. Now you see all of them: amount, timestamp, the payer wallet (where applicable), and a tonviewer link.

For TON ephemeral-wallet payments, the cron monitor pulls each inbound trace from TonAPI and stores it in a new payment_deposits table. The data is available the moment the deposit lands.

New payer_deposits array

Added to:

• GET /api/payments/:id (public, customer payment page) — source_address is omitted.
• GET /api/merchant/payments/:id (your dashboard / headless API) — includes source_address.
• GET /api/admin/payments/:id — same.
• Webhook payload — same.

Each item:

{
  "tx_hash": "fa67b42d...46d77c5",
  "amount": "1035691177",
  "amount_human": "1.04 TON",
  "received_at": 1779091349,
  "source_address": "UQABCxyz...EnD"
}

Ordered newest first. Empty array when no deposits have landed yet.

tx_hash deprecated

The top-level tx_hash field on the payment object stays in place for backward compatibility, now holding the most recent payer hash. New integrations should read payer_deposits[0].tx_hash instead. The OpenAPI docs at mutopay.com/api/docs flag the field as deprecated.

Where to see it

• Customer payment page: a “Your transactions” section appears under the status display once funds land.
• Merchant dashboard: the Payer TX row on the payment detail page now lists every deposit with its amount and timestamp.
• Admin dashboard: a new Payer Deposits section card sits between the ephemeral wallet info and the sweep attempts list, with the full payer address on each row.

Backfill note

Only TON payments completed after this release populate payer_deposits. Older payments keep showing a single tx_hash and an empty deposit list. Non-TON chains still surface a single hash via the legacy field until they get their own deposit-capture pipeline.

This release adds sandbox channels so merchants can verify their integration end-to-end before going live: no real funds, no on-chain interaction.

Test channels

When creating a channel from the dashboard, you can now choose Test instead of Production. Test channels mint API keys with the prefix ep_test_… (production keeps minting ep_…), and the mode is permanent. To go live, create a separate production channel and swap the key in your environment. The same model as Stripe’s sk_test_ / sk_live_.

Test payments skip all chain interaction. The cron monitor doesn’t poll providers or scan blocks for them, and the on-page wallet/manual-send flows are disabled. They’re also excluded from your dashboard stats and volume totals.

Simulate payment outcomes

Open a test payment’s URL just like a customer would. A “TEST MODE” banner sits above the checkout card with four buttons: Simulate complete, fail, expire, and underpaid. Clicking one fires the matching webhook to your configured URL: real signed payload (X-MutoPay-Signature), real retry behavior, with a "test": true field added so your handler can branch if needed. The customer-side redirect_url fires too, exactly as it would in production.

The same simulate panel is also available on the merchant dashboard payment detail page for back-office testing.

This release introduces manual send for direct transfers, email notifications, and payment recovery for interrupted sessions.

Manual send for direct transfers

Customers can now pay by copying the merchant’s address and sending the exact amount from any wallet. No wallet connection required. Works for same-token, same-chain payments on all EVM chains and TON. The system generates a unique amount (with random dust digits) for each payment and automatically detects the transfer on-chain.

This is useful for customers who use hardware wallets, exchange withdrawals, or simply prefer not to connect their wallet to a website.

Email notifications

Customers can opt in to receive an email when their payment is confirmed so they can safely close the page after sending. Merchants can also opt in from the dashboard Settings to receive email alerts for completed payments, failures, or other events.

Payment recovery

If the page is refreshed or the wallet connection drops during payment, the checkout now recovers automatically. Manual send payments resume the deposit screen with the exact amount still visible. Wallet-connected payments show a recovery screen where the customer can paste their transaction hash or start over.

If the customer already sent but can’t find their tx hash, the background monitor will still detect and complete the payment automatically.

This release adds a new headless API for programmatic senders and brings the payment page and merchant dashboard to five languages.

Headless payment API

A new POST /api/payments/headless endpoint returns a deposit address and exact amount in a single call. It’s built for senders who already know which chain and token they want to pay from: automated payout systems, partner platforms, scripts, and wallet apps that control their own UX.

Supports direct (same-token, same-chain) and deposit-based swap/bridge routes. Signed-order flows (EIP-712 intents, on-chain swap transactions) are not supported in headless mode. Integrations should fall back to the hosted /pay/{id} page for those routes.

Payment page and dashboard in 5 languages

The /pay/:id page and the full merchant dashboard are now available in English, Spanish, Turkish, Armenian, and Russian. The UI auto-detects the browser language and remembers the choice across visits. Language switchers live in the payment page footer, Pay Me page footer, and dashboard sidebar.

Reliability improvements

A round of fixes to payment monitoring, stuck deposits, and wallet connection issues.

This release adds headless API access, exact settlement tracking, QR codes for deposit payments, and a round of security hardening.

Breaking: API path renamed

All merchant dashboard endpoints have moved from /api/dashboard/* to /api/merchant/*. The old paths no longer work. Update your integrations accordingly.

Master API key

Merchants can now generate a master API key (msk_ prefix) from Dashboard → Settings. This key authenticates against all /api/merchant/* endpoints (create payments, list channels, manage settlement) without a browser session. Useful for backend services, scripts, and CI pipelines.

Master key management (generate, rotate, revoke) requires a browser login. A master key cannot rotate or revoke itself.

Settlement amount in webhooks

Webhook payloads now include dest_amount and dest_decimals: the exact number of tokens that landed in your wallet. This is critical for non-stablecoin settlements (e.g. TON) where amount_usd doesn’t tell you the token count. Divide dest_amount by 10^dest_decimals for the human-readable figure.

QR codes on deposit payments

Customers paying via deposit (Rubic cross-chain routes, TON, Tron) now see a scannable QR code above the copy fields. Chain-aware URIs: EIP-681 for native EVM, ton://transfer with memo for TON, Solana Pay with SPL token + memo, BIP-21 for BTC.

Channel edit page

Each channel now has a dedicated edit page at /dashboard/channels/:id with sections for branding, webhook URL, settlement override, API key rotation, and a danger zone for revoking access.

Pay Me Page channel

Setting up a Pay Me page now automatically creates a dedicated channel for it. This gives your Pay Me page its own branding, settlement destination, and webhook URL (independent of your other channels).

Webhook reliability

A new catch-all cron task fires webhooks for any payment that completed via inline status polling but whose webhook was silently skipped. No more missed notifications.

Security

• Rate limiting on admin login (5 attempts / 15 min per IP)
• CORS restricted to mutopay.com + localhost
• Content-Security-Policy header on all pages
• AES-256-GCM encryption for stored API keys
• Open redirect protection on return URLs

Merchants can now create and manage API channels entirely from the dashboard (no WooCommerce plugin required). Each channel can also have its own settlement destination, independent of the account default.

Create channels from the dashboard

A new + New channel button in Settings lets you create a manual API channel in seconds. Give it a name, optionally add a webhook URL, and optionally set a settlement override for that channel specifically. The full API key is shown once on creation. Copy it before navigating away.

This is the easiest way to integrate MutoPay into any custom storefront, mobile app, or backend service without going through the OAuth connect flow.

Per-channel settlement override

Every channel can now have its own settlement chain, token, and wallet address. If no override is set, the channel uses your account-level default. Overrides are managed inline in the channel card: click Override to set one, click the pencil to edit, or Remove override to revert to the account default.

The three fields (chain, token, and wallet address) are always saved and cleared as a bundle. This prevents mismatches where a chain is set but no matching wallet is present.

Inline channel editing

Channel names and webhook URLs can now be edited inline. Click the pencil icon next to either field, make your change, and save without leaving the page.

The webhook secret is now visible with a Copy button in each channel card, alongside the existing Test Webhook button.

Simplified onboarding

The new merchant onboarding flow merges the chain/token and wallet address steps into a single Set up settlement step. Chain, token, and wallet are all configured together in one form and saved in one API call.

API

Four new dashboard endpoints support these features:

Method	Endpoint	Description
POST	/api/dashboard/channels	Create a manual channel; returns { channel, api_key }
PATCH	/api/dashboard/channels/:id/webhook-url	Update webhook URL
PUT	/api/dashboard/channels/:id/settlement	Set per-channel settlement override
DELETE	/api/dashboard/channels/:id/settlement	Remove override (revert to account default)

MutoPay’s merchant and customer interfaces are fully redesigned, and merchants now have a personal payment page that accepts any amount (no fixed invoice needed).

Pay Me links

Every merchant gets a personal page at mutopay.com/pay/@yourname. Visitors enter any amount and an optional note. Useful for tips, freelance invoices, and open-ended orders. Set your page up from Dashboard → Settings → Pay Me Page.

Redesigned UI

All customer-facing and merchant-facing pages now share a consistent design language: unified cards, typography, and color system across the payment page, merchant dashboard, admin panel, and Pay Me page.

Mobile-ready

Every page (payment checkout, merchant dashboard, and admin panel) is now fully responsive. Customers and merchants can use MutoPay on any device.

Payment description

Merchants can attach a human-readable description when creating a payment (e.g. “Order #1042 – Blue Widget”). It appears on the customer’s checkout page as context for what they’re paying for.

Channel branding

Each merchant channel can now override the default business name and tagline shown to customers. Useful for merchants with multiple storefronts on one account. Managed from Dashboard → Channels → edit channel.

MutoPay now covers three major non-EVM chains. Customers can pay from TON, Solana, and Tron wallets, and merchants can settle in their native tokens.

New chains

• TON: accept TON or USDT-on-TON. Buyers connect Tonkeeper, MyTonWallet, or any TonConnect wallet with one tap. Ideal for Telegram bots and mini-apps.
• Solana: pay with any SPL token, settle in native USDC-on-Solana. Phantom and Backpack supported.
• Tron: accept and settle USDT-TRC20, the most widely circulated stablecoin rail in emerging markets.

Quote comparison

When multiple routes are available, the payment page now shows them side-by-side (bridge name, destination amount, and estimated time) so buyers pick speed or price.

Manual deposit flow

For routes we can’t sign directly (NEAR Intents and other intent-based bridges), the payment page shows a copy-friendly deposit address and exact amount, then auto-advances when the deposit lands.

New webhook events

• payment.kyc_required: the routing provider placed a temporary hold while the buyer verifies their identity. No merchant action needed; the eventual payment.completed or payment.failed is the final signal.
• payment.needs_manual_check: the provider returned an unexpected status. MutoPay ops investigates before the payment reaches a terminal state.

Every payment now reaches a deterministic outcome. None can silently stall in pending.

Payment page

Wallet connect flows straight into payment. No second click after connecting.

Payments can now be created in any of 50+ fiat currencies. The amount is converted to USD at real-time central-bank exchange rates when the payment is created.

Features

• 50+ fiat currencies: price in EUR, GBP, SAR, AED, JPY, AMD, and more. Conversion happens server-side using rates from the Frankfurter API, sourced from 30+ central banks.
• Auditable FX rates: each payment stores the original amount, currency, and the exchange rate used at creation time. Visible in the dashboard, admin panel, and webhook payloads.
• WooCommerce auto-currency: the MutoPay plugin now sends your store’s configured currency automatically. A EUR store creates EUR payments without any extra configuration.
• Backwards compatible API: the existing amount_usd field continues to work. The new amount + currency fields are additive.
• Resilient rate caching: FX rates are cached in Cloudflare KV with a 2-hour fresh window and 24-hour stale fallback, so payments keep working even if the upstream rate provider is temporarily unavailable.

We’re thrilled to launch MutoPay v1.0, the crypto payment gateway that converts any token into stablecoins.

Features

• Payment API: create payment links with a single POST request
• Multi-chain support: Ethereum, Polygon, Arbitrum, Base, Optimism, Avalanche, BNB Chain
• 1,000+ tokens: accept any token, always receive USDC, USDT, or DAI
• Cross-chain bridging: automatic routing via the best available protocol
• Merchant dashboard: monitor payments, manage API keys, configure webhooks
• Admin panel: platform-wide analytics, merchant management, fee configuration
• Webhook notifications: HMAC-SHA256 signed, with automatic retry and exponential backoff
• Self-custody: funds settle directly to the merchant’s wallet