MNEE Pay: Stablecoin Payments Platform
RockWallet's stablecoin payments platform — merchant portal, consumer QR flows, and the payment-session contract that every surface compiles to.
A new settlement rail, not a crypto payment processor
MNEE Pay is RockWallet's stablecoin payments platform — a merchant-facing product that lets businesses accept any major stablecoin on any major chain and settle in a single normalized asset: MNEE, our own USD-backed stablecoin. The thesis is simple to state and hard to build: legacy card networks (Visa, Mastercard, the interchange tax, the chargeback regime, the PCI overhead) are an aging settlement rail, and stablecoins are the next one.
MNEE Pay positions us not as a "crypto payment processor" sitting on the side of the real payments stack, but as a new settlement rail that intends to coexist with — and over time replace — that stack. The MNEE token itself has been live since July 2024 (ERC-20 + 1Sat Ordinals, 1:1 backed by US Treasuries and cash, Delaware money-transmitter licensed, GENIUS Act compliant, attested monthly by Wolfe & Co., ~$100M in circulation by late 2025). I joined this work when the question changed from "is the stablecoin real?" to "what does the merchant actually see, click, and trust?"
Three users, three interfaces, one contract
A stablecoin payments platform has three completely different users and three completely different interfaces:
- The merchant — needs to integrate MNEE Pay into an existing tech stack (Stripe gateway, Clover POS, online checkout, retail QR) with as little engineering work as possible. The High-Level Requirements doc says it plainly: "for MNEE Pay to be successful, it needs to be easy for merchants to integrate MNEE Pay into their existing technology stack with no coding required."
- The consumer — needs to pay with any stablecoin (USDC, USDT, PYUSD, DAI…) on any chain (Solana, Optimism, Tron, Base, Arbitrum, 1Sat Ordinals…) and not have to think about any of that.
- The operator — needs to monitor a payment-session state machine across thousands of merchants and millions of sessions, with refunds, partial refunds, settlement webhooks, OFAC screening, and an attribution ledger that survives a primary-DB outage.
Layered on top: the Merchant Portal had to be a real product surface (not a developer dashboard), and the consumer surface had to live across QR codes, POS terminals, gateway redirects, and the RockWallet retail app itself.
I started from the payment session as the canonical object — same as the architecture team. Every design decision had to be representable as a state of that object, from an agreed set: awaiting payment → on-chain pending → confirmed → settled → completed, plus failed, expired, and refunded. If a screen couldn't be mapped to a session state, it didn't ship.
That contract is what lets the merchant portal, the consumer QR flow, the RockWallet retail app, and the operator's session list all show the same truth without any of them owning it. The session is the source; the surfaces are projections.
Refunds (full and partial, up to 3 per transaction, always to the original wallet/token/network, refund fee covers our gas) became their own first-class flow rather than a button buried in transaction detail. That's the contract paying off: a refund is just one more state of the session, not a parallel system.
For the Merchant Portal I structured the IA around four jobs:
- Get paid — modules (checkout configurations) + the payment session list
- Move money — settlement, withdraw to MNEE wallet, optional off-ramp to Cross River Bank (US) or Borderless (international)
- Manage — refunds, disputes, receipts, API keys, webhooks
- Understand — analytics, reporting, exports
That framing replaced what was originally a much more developer-y "API docs and a transactions list" layout. The result reads as a product a CFO can navigate, not a console an engineer logs into.
For the consumer side I leaned into the simplest possible surface: a QR code or a checkout button that resolves to a payment session, and a wallet-side confirmation step. Phase 1 of QR Payments is static (one address per merchant module) — pilotable without any real-time backend round-trip. Phase 2 is dynamic (a unique session per scan) — hardened only after the session infra was proven.
For the cross-product handoff I designed the merchant receipt surface as a doubling: a record of purchase for the consumer who paid with a non-RockWallet wallet, and a gentle marketing surface that points them toward the RockWallet app. Receipts as a growth driver, not just a record.
Key decisions
- Payment Session as the design contract. If it isn't a state, it isn't a screen.
- Static QR before dynamic QR. Ship a pilotable surface first; harden the session-per-scan model second.
- Refunds are first-class. Up to 3 partials per transaction, always to the original wallet/token/network, refund fee covers gas. Don't bury them.
- Settlement asset is always MNEE. Merchants accept many stablecoins, receive one. Don't make merchants think about chains.
- Receipts as a growth surface. Cross-product, not just a record of purchase.
- Passkeys for outbound, not inbound. Receiving doesn't need biometrics; sending/refunding/withdrawing does. Every outbound payout = a passkey prompt.
- Merchant Portal IA = four jobs. Get paid / Move money / Manage / Understand. Replaces dev-dashboard mental model.
- Merchant Account Level Gamification reuses the retail Levels framework. Same Octalysis frame, different milestones (volume, refund rate, KYB completion). One pattern across two products.
Platform shape at MVP
Surfaces across the platform
Reflection — the receipt took more design than the homepage
The biggest tension across this work has been resisting feature-creep into "let's also be a card network." We're not. The discipline of saying "MNEE Pay is settlement infrastructure plus a thin merchant surface, not a vertically integrated payments company" has shaped almost every design call I've made — especially around what not to put in the Merchant Portal at MVP (no advanced analytics dashboards, no marketing campaign tooling, no POS device management). Every one of those is a real future product; none of them is MVP.
The thing I underestimated: how much design work the receipt would take. A receipt is the only surface that touches every payment, every consumer, every merchant — RockWallet user or not. Treating it as a marketing/growth/compliance/UX object simultaneously meant it ended up with more careful thinking than the Merchant Portal homepage.
The thing I'm proud of: a merchant integrating MNEE Pay through Stripe doesn't need to know that any of this stablecoin infrastructure exists. They get a 0.99% fee, no chargebacks, money in their MNEE wallet, optional off-ramp to USD. That's the whole pitch, and the UX honors it.