ChainPay helps merchants accept USDT/USDC through hosted checkout, WooCommerce, REST API, Telegram Bot and MCP/OpenAPI integrations. It includes sandbox testing, signed webhooks and a simple flow for stores, SaaS products and Telegram sellers.
No reviews yetBe the first to leave a review for ChainPay
Hunter
📌
Hi Product Hunt,
I built ChainPay for merchants who want stablecoin payments without turning blockchain operations into a side business.
The core flow is deliberately familiar: create an order, send the buyer to a hosted checkout, receive a signed webhook, then mark the order paid. On top of that, ChainPay supports WooCommerce, Telegram Bot and MCP / OpenAPI for AI-assisted payment workflows.
I would love feedback from WooCommerce store owners, SaaS builders and Telegram sellers.
Report
Hunter
Small product update from ChainPay: Batch Payout is now live.
Merchants can submit one payout batch from the dashboard or HMAC-signed API to send USDT/USDC to many recipients on TRON, BSC or Polygon.
It is aimed at payroll, commissions, bulk rebates and supplier settlement, with per-recipient status, approval thresholds, daily limits and clear payout fees.
How does the fee structure compare to something like Coinbase Commerce, especially for smaller stores that might be processing a few thousand a month?
Report
Hunter
Thanks Erol. For a store doing a few thousand a month, I would compare it less as a full processor replacement and more as a second payment rail.
ChainPay's incoming payment fee is currently 0%; the merchant still needs to account for network/withdrawal costs and their own accounting flow. Coinbase Commerce is broader and more established. ChainPay is intentionally lighter: hosted checkout, WooCommerce paid-state update, sandbox testing, and signed webhooks for USDT/USDC.
My practical suggestion is to offer it first to customers who already prefer stablecoins, then expand once support, withdrawals, and bookkeeping feel predictable.
Report
Hunter
Thanks Huriye. For a higher-volume WooCommerce store, I would compare total operational cost rather than only the headline processing fee.
Coinbase Commerce has the advantage of a broader, more established product surface. ChainPay is narrower: it is built to make USDT/USDC a predictable extra rail with hosted checkout, WooCommerce paid-state updates, sandbox testing, and signed webhooks.
At higher volume, I would test network choice, withdrawal batching, webhook idempotency, reconciliation, and support workflow. If those stay predictable, the 0% incoming payment fee can matter more.
Report
finally a crypto checkout that doesn't feel like a puzzle. the WooCommerce plugin dropped in cleanly and the sandbox webhook fired exactly when i expected, which is rare.
Report
Hunter
Thanks Fatma. That is exactly the flow I wanted to keep boring: WooCommerce order created, hosted checkout completed, signed webhook received, then the order moves to paid without the merchant needing to interpret chain data manually. Glad the sandbox behaved predictably for you.
Report
How does the fee structure compare to something like Coinbase Commerce, especially for higher volume stores already running WooCommerce?
Report
Hunter
Fee question came up today, so here is the short version.
ChainPay is positioned as a lightweight stablecoin checkout for merchants who want USDT/USDC as an extra payment rail, not as a full custody/payment stack. Incoming payment fee is currently 0%; merchants still need to account for withdrawal costs, network conditions and their own accounting workflow.
For a small or mid-volume WooCommerce store, I would test it as a second rail first: sandbox order -> signed webhook -> WooCommerce paid state -> withdrawal workflow. If those four steps feel predictable, then offer it to customers who already prefer stablecoins.
The sandbox + signed webhooks combo is a really thoughtful move, makes testing feel production-safe instead of just an afterthought.
Report
Hunter
Thanks Sebahattin. That was one of the main design constraints: sandbox should exercise the same order and webhook state machine, not feel like a mock demo.
The signed webhook is there so WooCommerce or SaaS code can trust the paid / failed / expired state without asking the merchant to parse chain events manually. Testing should feel close to production before a store exposes the payment rail to real customers.
Small product update from ChainPay: Batch Payout is now live.
Merchants can submit one payout batch from the dashboard or HMAC-signed API to send USDT/USDC to many recipients on TRON, BSC or Polygon.
It is aimed at payroll, commissions, bulk rebates and supplier settlement, with per-recipient status, approval thresholds, daily limits and clear payout fees.
Docs: https://chainpay.to/docs
Fees: https://chainpay.to/fees
How does the fee structure compare to something like Coinbase Commerce, especially for smaller stores that might be processing a few thousand a month?
Thanks Erol. For a store doing a few thousand a month, I would compare it less as a full processor replacement and more as a second payment rail.
ChainPay's incoming payment fee is currently 0%; the merchant still needs to account for network/withdrawal costs and their own accounting flow. Coinbase Commerce is broader and more established. ChainPay is intentionally lighter: hosted checkout, WooCommerce paid-state update, sandbox testing, and signed webhooks for USDT/USDC.
My practical suggestion is to offer it first to customers who already prefer stablecoins, then expand once support, withdrawals, and bookkeeping feel predictable.
Thanks Huriye. For a higher-volume WooCommerce store, I would compare total operational cost rather than only the headline processing fee.
Coinbase Commerce has the advantage of a broader, more established product surface. ChainPay is narrower: it is built to make USDT/USDC a predictable extra rail with hosted checkout, WooCommerce paid-state updates, sandbox testing, and signed webhooks.
At higher volume, I would test network choice, withdrawal batching, webhook idempotency, reconciliation, and support workflow. If those stay predictable, the 0% incoming payment fee can matter more.
finally a crypto checkout that doesn't feel like a puzzle. the WooCommerce plugin dropped in cleanly and the sandbox webhook fired exactly when i expected, which is rare.
Thanks Fatma. That is exactly the flow I wanted to keep boring: WooCommerce order created, hosted checkout completed, signed webhook received, then the order moves to paid without the merchant needing to interpret chain data manually. Glad the sandbox behaved predictably for you.
How does the fee structure compare to something like Coinbase Commerce, especially for higher volume stores already running WooCommerce?
Fee question came up today, so here is the short version.
ChainPay is positioned as a lightweight stablecoin checkout for merchants who want USDT/USDC as an extra payment rail, not as a full custody/payment stack. Incoming payment fee is currently 0%; merchants still need to account for withdrawal costs, network conditions and their own accounting workflow.
For a small or mid-volume WooCommerce store, I would test it as a second rail first: sandbox order -> signed webhook -> WooCommerce paid state -> withdrawal workflow. If those four steps feel predictable, then offer it to customers who already prefer stablecoins.
Fee page:
https://chainpay.to/fees?utm_source=producthunt&utm_medium=comment&utm_campaign=launch-week-2026-07&utm_content=fee-question
The sandbox + signed webhooks combo is a really thoughtful move, makes testing feel production-safe instead of just an afterthought.
Thanks Sebahattin. That was one of the main design constraints: sandbox should exercise the same order and webhook state machine, not feel like a mock demo.
The signed webhook is there so WooCommerce or SaaS code can trust the paid / failed / expired state without asking the merchant to parse chain events manually. Testing should feel close to production before a store exposes the payment rail to real customers.