How payment verification works
You can inspect the simulated checkout and developer reference without an account. The demo shows the payment steps using a timer. It does not connect a wallet, send funds or verify a transaction.
What counts as paid
For ordinary checkout payments, MMO Pay looks up the transaction using the payment's unique Solana Pay reference. The verifier checks the RPC network's genesis hash, requests finalized data and requires a successful transaction containing that reference. It checks the saved recipient, token mint and amount in base units. SPL token decimals must match checkout configuration. If a referral split applies, the recipient and referrer must each receive their required share.
Only a successful settlement write records the payment as SETTLED and creates its receipt. A unique transaction signature prevents the same signature from settling another payment. API-created sessions use this checkout and settlement flow too. A submitted signature, redirect or wallet approval alone is not proof of payment.
Read the payment state
- PENDING / DETECTED / CONFIRMED
- The payment is not recorded as settled. Detection or confirmation alone does not authorize fulfillment.
- SETTLED
- The payment passed validation and settlement was saved. This does not prove delivery of an order or private credit from a receiving provider.
- UNDERPAID
- The required recipient amounts were not received. The checkout is not paid.
- EXPIRED / FAILED
- The checkout is not paid. A failed chain transaction cannot produce a settlement; it may leave checkout pending until expiry.
Assets, networks and costs
Checkout supports SOL with 9 decimals and USDC, USDT and MMO with 6 decimals. Each payment link offers a subset of the assets configured for its Solana cluster. Devnet uses test assets; it does not establish mainnet activity. Check the network shown in the actual checkout and your wallet before paying.
MMO Pay takes no platform cut. Buyers pay Solana transaction fees and any required token-account rent. An optional referral split comes from merchant proceeds. When MMO-to-USDC swaps are available, the quote includes swap costs and checkout shows slippage and price impact. The demo does not quote live fees or exchange rates.
Privacy and optional USDC receiving
Aliases reduce address exposure in MMO Pay's interface. They do not hide public Solana transactions, amounts or receiving addresses. Receipt links are private access links; share one only with its intended recipient.
The optional receiving pilot supports canonical USDC on Solana mainnet through an approved provider deposit address. It depends on feature switches and merchant setup. Its implementation does not establish that a provider is enabled for any live merchant. SOL, USDT and MMO stay on the regular payout route; subscriptions stay direct. MMO Pay verifies the incoming transfer. The provider handles screening, fees and private credit. A settled payment does not prove that the provider credited a private balance.
Public settlement evidence
This page currently has no opt-in mainnet receipt evidence to show. The demo and this explanation do not establish completed production payments, revenue or provider credit.
Ordinary receipts and merchant records are not a public evidence feed. Any future example needs explicit permission and a separate reviewed record limited to network, asset mint, amount, finalized transaction signature, settlement time and verification result. Buyer aliases, order details, contact information, payment access tokens and linked identities must stay out of that record.