CXPay frequently asked questions

CXPay is a non-custodial crypto merchant gateway at cxpay.cash for checkout, links, invoices, and API integrations.

Visit /signup with email, password, business name, and payout wallet—or sign in with CoinExchange.

Use cxpay_test_ API keys and test webhooks before going live.

Authenticated merchants use /dashboard (not indexed for SEO).

Use the /contact form. Public pages do not list email addresses.

Merchant sign-up does not collect government ID or KYB documents in the described flow.

Yes. CoinExchange issues the shared login/JWT across the stack.

Email and password (or CoinExchange), business name, and payout wallet address.

Not for CXPay merchant onboarding as described here.

1% on standard checkout per payment.

0.5% when the payer selects the CXCASH rail.

$0.30 per payment even when the percentage would be lower.

No setup, monthly, or application fee in the product described on this site.

Network fees are shown to payers at cost on ETH and BTC rails.

Ethereum, Base, Arbitrum, Optimism, Polygon, Tron, Solana, Bitcoin (on-chain and Lightning), and CXCASH—see /accept pages for tokens.

No. Base supports ETH, USDC, and DAI.

Yes. SOL, USDC, and USDT on Solana are available when enabled on your merchant profile.

Yes. USDT (TRC20) is a standard checkout rail with absorbed Tron network costs for payers.

Yes. Payers can pay via Lightning invoice; on-chain BTC remains available with payer-paid L1 fees.

You provide a Lightning address, LNURL-pay endpoint, or connect BTCPay. CXPay requests a BOLT11 invoice from your provider for the locked USD amount; payers pay that invoice and funds settle to your Lightning setup—not a CXPay float.

Yes. After asset selection, checkout exposes Solana Pay-style URIs with amount and reference so wallets such as Phantom can pre-fill the transfer to your merchant Solana address.

Any wallet that supports TRC20 USDT or TRX transfers and tron: payment URIs—commonly TronLink and other Tron-compatible mobile wallets. Payers should match the quoted USDT amount exactly.

Quotes use the precision a payer can type: two decimals for USD stablecoins and TRX, four for SOL, six for ETH and on-chain BTC, and whole satoshis for Lightning. Payers send the exact quoted amount.

Retail exchange apps and some wallets limit stablecoin send amounts to cents, so a quote like 25.0004 USDC cannot be paid from them. Quoting to cents keeps the amount typeable everywhere.

No. Payments settle to your payout wallet.

Update merchant settings before new payments.

CXPay does not operate merchant hot-wallet sweeps for your sales proceeds.

No. Crypto only.

A CXPay page where payers complete payment for a payment intent.

Shareable URLs with a fixed USD amount.

Anything above 0.25% of the quote reports payment.overpaid so you can refund the excess; smaller differences settle as a normal payment.

Yes when quotes expire.

The amount identifies the payment, since funds go straight to your wallet instead of a per-invoice deposit address. Each open payment gets an offset of one payable unit, capped at five cents on small invoices and 0.5% of the order up to $0.25 on larger ones.

Most exchange withdrawals subtract the network fee from the amount typed into the form. Payers should pick the option that sends the full amount, often labelled "fee on top" or "receive amount", or pay from a self-custody wallet.

Yes. Sending the remaining amount to the same address before the quote expires adds to the earlier receipt, and the payment is re-evaluated against the 0.25% tolerance.

Solana checkout includes a Solana Pay reference key that identifies the transfer, with the amount as a fallback. Lightning payments are matched by the invoice payment hash, which is exact by design.

https://api.cxpay.cash/api/v1

Safe retries on POST /payment-intents.

cxpay-signature header with timestamp and HMAC-SHA256 v1.

payment.confirming, paid, succeeded, underpaid, overpaid, expired, failed, cancelled.

Yes from the dashboard with delivery logs.

Yes—request via /contact; configure API key, base URL, and webhooks.

No native app; use links or invoices for supported workflows.

Request through the contact form; no download link on marketing pages.

Crypto payments are not reversed by payer banks; refunds are merchant-initiated.

Use the dashboard or POST /refunds via API.

Merchants handle customer service; CXPay provides statuses and tooling.

Keep secret keys on your server only—in environment variables or a secrets manager—never in client-side code, mobile apps, or public repositories. CXPay shows publishable keys in the dashboard; secret keys are created once and must be stored by you.

Manual address blocklist screening is used.

No email addresses appear on public marketing pages.