Payment evidence.
Your order logic.

Add the frontend widget

Download and review the source package, then copy public/js/mcrtpay.js to your own site at /vendor/mcrtpay.js. Serve the reviewed file from your own origin and pin your deployed version. The address-copy flow needs no third-party JavaScript. If you add QR rendering, self-host a reviewed, pinned QR library too. Your server creates an invoice for the signed-in customer before rendering checkout. Lock the exact MCRT amount and quote expiry on that invoice. Pass the same values to the widget:

<script src="/vendor/mcrtpay.js"></script>
<div id="mcrtpay-container"></div>
<script>
// invoice comes from YOUR authenticated server
new MCRTPay({
  walletAddress: invoice.walletAddress,
  paymentAmount: invoice.usdAmount,
  mcrtAmount: invoice.mcrtAmount,
  quoteExpiresAt: invoice.expiresAt, // epoch milliseconds
  planId: invoice.id,
  backendUrl: '/api/mcrtpay/verify',
  successCallback: () => refreshOrder()
});
</script>

The widget sends invoiceId and planId using the configured planId. It only fires the callback when your backend returns both success: true and fulfillmentCommitted: true. Never grant access from browser state.

For React or Next.js, mount the same widget in a client component after the container exists. Keep the widget instance and call widget.destroy() when the component unmounts. Creating a new widget in the same container retires the previous checkout, including pending requests and timers. A confirmed fulfillment removes payment instructions and calls the callback once for that instance. Your authentication, invoice database and server route are application-specific; they are not provided by this snippet.

Run the tested verifier

curl -fLO https://mcrtpay.com/downloads/mcrtpay-source.zip
unzip mcrtpay-source.zip
cd mcrtpay
npm ci
cp .env.example .env
# Configure your own receiving wallet, then:
npm test
npm start

MCRTPAY_WALLET_ADDRESS=0xYourReceivingWallet
MCRTPAY_MIN_CONFIRMATIONS=3
HOST=127.0.0.1
PORT=3000

Use Node.js 22 or newer. Put the server behind HTTPS. The default bind is loopback. The verifier needs no wallet private key and no BscScan API key. Do not place keys or seed phrases in the frontend or environment.

The maintained server implementation is the source of truth for canonical token filtering, 9-decimal integer amounts, bounded provider responses and confirmation checks. Use it instead of a copied, divergent verifier.

The merchant contract

Complete every requirement before inviting customers to pay. This is integration work in your application, not a feature switched on by the widget builder.

• Authenticate and authorize: bind each invoice to the signed-in customer. Apply CSRF protections and request limits to your merchant endpoint.
• Lock the quote: save the recipient, canonical token, BNB chain, exact MCRT amount, creation block/time and expiry on the server. Ignore browser-submitted prices when deciding what is owed.
• Bind the payer: a public transaction hash is not proof of ownership. Require a nonce-bound wallet signature and match the verified transfer sender, or use a unique deposit address per invoice. Merely being first to paste a public hash is not enough.
• Verify on-chain: use the expected invoice recipient and amount, canonical token, successful receipt, transaction hash and sufficient confirmations. Reject receipts predating the invoice. Choose confirmations appropriate to the value and reorg risk.
• Prevent reuse: enforce a unique normalized tx hash, scoped to chain, in persistent storage. Claim the receipt and mark the owned invoice paid in one atomic database transaction. Recheck expiry and invoice state under that transaction.
• Deliver exactly once: make fulfillment idempotent, including worker retries and restarts. For external delivery, use a durable outbox and only claim committed fulfillment once the promised action is complete.
• Handle exceptions: define late, wrong-network, partial and excess payments; provide merchant support and refund rules. Never imply a failed browser verification reverses an on-chain transfer.

API reference

Verification request

{
  "txHash": "0x...64 hexadecimal characters...",
  "network": "bep20",
  "currency": "MCRT",
  "expectedAmount": "25000.000000001",
  "planId": "merchant-invoice-id"
}

Send JSON. Amounts are positive decimal MCRT values with at most 9 decimals. Requests are rate limited. Invalid input returns 400, pending confirmations return 202, request limits return 429 with a Retry-After header, unsupported request encodings return 415, and service failures return 503. A verified hosted response still returns success: false. Its verification object includes the normalized transaction hash, sender, recipient, token contract, chain ID, log index, amount, block number and confirmations. Sender evidence is not proof that the person submitting the hash controls that wallet.

Do not configure the public endpoint as a production fulfillment backend or treat client-supplied expectedAmount as an invoice price. The historical /api/jpay/verify and /verify-payment aliases have the same evidence-only boundary.

Key widget options

Canonical token reference

Network: BNB Chain mainnet, chain ID 56.
Decimals: 9.
Token contract, not a receiving wallet:

0x4b8285aB433D8f69CB48d5Ad62b415ed1a221e4f

Network gas is paid separately in BNB. Quote sources and public RPC providers can fail or disagree. Confirmation counts reduce risk but do not guarantee finality. Review the security and risk notice before accepting funds.

Validate the complete integration

Test wrong recipient, token and chain; underpayment; expired quotes; a reused hash; a different user’s transfer; simultaneous claims; service restart; failed RPC; and failed delivery. A funded acceptance test requires an authorized payment and a real merchant invoice. This website’s demo does not perform one.

Open widget builder →