No payment, transfer, custody, deposit, balance or financial service is provided here.
Merchant Acceptance Layer
Mpay Merchant Acceptance
Identity→Acceptance→Settlement→Evidence
Mpay enables governed payments, service receipts, and accountable settlement across the Meridian Special District ecosystem.
It is the public counter layer of MSD: after MID / MCID identity recognition and before settlement evidence, keeping everyday payment legible while preserving merchant status, price, approval and receipt finality for review.
01Attested merchants
02Local-currency pricing
03Controlled approval
04Verifiable receipts
Concept mockup
Confirm acceptance
Zhang's Grocery
✓ Attested · registry name
XCD 12.00
≈ 4.44 USDM · published rate
✓
Settled · final
Product concept · not a product screenshot
Private transfersPolicy commitment · not a promo
SettlementFinal state · receipt-backed
PricingOne price, in local currency
BoundaryNo public account or market interface
Publication record
Concept file, not a service launch
This page is structured as a public-facing concept record for review. It explains the acceptance layer, the operating boundary and the evidence path before any service, download or market surface exists.
Any pilot opening, merchant access or verification service must follow a named public notice.
The page separates concept diagrams, receipt logic and gateway evidence from operating claims.
The acceptance layer avoids public trading, public balances and speculative interface patterns.
Role in MSD
The trusted payment and receipt layer of MSD
Everyday acceptance is fast, but proof is often weak after the counter moment.
Mpay keeps the merchant, price, approval and receipt inside one governed acceptance flow.
Identity, registry name, rate, settlement and receipt can be reviewed without turning the page into a market interface.
Small merchants gain a simple counter tool; institutions gain a record that can be supervised.
Operating framework
Five controls turn a counter moment into an accountable record
Mpay is not a wallet, market or account surface. It turns a simple counter action into a governed record by connecting verified identity, local-currency pricing, controlled approval, receipt proof and gateway evidence.
MID and the merchant registry establish who is accepting.
The counter presents one understandable local-currency price.
Device biometrics and account signing control the acceptance.
The final state is expressed through a verifiable receipt.
M Gateway publishes rate and reserve evidence outside the counter.
Public value
Formal records without making the counter heavy
The merchant still needs a simple placard, a phone confirmation and a receipt. The institution needs the record behind it to be explainable, reviewable and bounded.
Architecture / Acceptance surface
Three confirmations, one receipt-backed outcome
Mpay keeps the counter experience simple while the system underneath remains explicit: the merchant is known, the price is local, the approval is controlled, and the final state is evidenced by a receipt.
Scan an attested counter
The code opens the registered merchant surface. The payer sees the merchant name from the system registry before approving the amount.
Static code → registry lookup → attested name
Confirm one local price
The counter shows one local-currency price. Where conversion is required, the published rate is disclosed on the receipt and statement.
Local price → published rate → clear statement
Settlement closes the loop
Finality is expressed through a receipt state, not a speculative market signal. The acceptance record remains available for later review.
Approve → final state → verifiable receipt
01 · MerchantRegistry name firstThe payer sees the attested merchant before approving.
02 · PriceOne counter priceLocal-currency presentation stays clear at the point of sale.
03 · ReceiptEvidence followsThe final state can be checked after the counter moment is over.
This section describes mechanisms; it is not an offer of services. Each experience opens with the pilot, per formal announcements.
How it works
Four steps, each one leaving evidence
Every phone screen below is a concept mockup — fictional merchant, fictional amount, not a screenshot of an existing product.
01
Scan
The merchant hangs a static code; the instant you scan it, the app looks up who that code is registered to.
02
Confirm
The name on the confirmation page comes only from the system registry — a code can be swapped, a name cannot be faked. The amount is exactly what the merchant priced.
03
Co-sign
Your biometrics and your MID account sign together. A stolen phone, on its own, cannot authorise account movement.
04
Receipt
Settlement is final the moment it lands, and a receipt follows — independently verifiable, even fully offline.
Mockup notice: every phone interface in this section is a concept mockup with fictional merchants and amounts — not a screenshot of an existing product. Final product form subject to release.
Settlement evidence
Two balances, one price
USDM + local M-currency · dual balance
The acceptance flow can reference two permitted balances: USDM, the ecosystem settlement asset, and a jurisdictional local digital currency (such as XCDM). Merchants price in local currency; any conversion is made at the published rate, and the conversion line is printed on the receipt and statement.
Ecosystem settlementUSDMReferenced to 1 USD · ecosystem-wide
Jurisdiction localLocal-Me.g. XCDM · circulates in-ring only
How rates are set and reserves are reconciled — that evidence hangs on the gateway's wall: mex.ms →
Security design
Safe by structure, not by caution
None of these protections ask the user to memorise a safety rulebook — they are built into the shape of every acceptance approval.
Co-signed, every approval
Each approval needs biometrics and MID account signing together — a device alone cannot authorise account movement.
Attested names beat swapped codes
The merchant name always comes from the system registry. A swapped sticker cannot fake a registered name.
Limits and risk checks, per approval
Each approval passes limit and risk checks; anomalies go to review instead of becoming a vague interface failure.
Receipts that prove themselves
Each accepted transaction issues an independently verifiable receipt, so the evidence survives after the counter moment.
Operating standards
Constrained before it becomes a service
Mpay is described as an acceptance layer because the operating rules matter as much as the interface. Launch status, merchant access, receipt proof, review paths and public evidence remain bounded until formal notice.
No pilot, merchant access or verification surface opens without a named public announcement.
Receipts, statements, rates and reserve evidence are designed to survive the counter moment.
The page avoids public balances, custody, trading and speculative controls.
Identity and merchant registry names remain part of the acceptance record.
Risk exceptions, disputes and recovery paths route to logged review rather than silent interface failure.
Merchant controls
One printed code, one attested name Illustrative
The merchant side is designed around registration, limits, statements and receipt evidence. Simple at the counter, controlled in the records behind it.
Open in minutes
A phone and basic ID, fully online, with defined operating limits and a clear upgrade path as the business grows.
Licence + basic checks
Registered operators submit a business licence; limits widen, and staff sub-accounts mean you never hand over your own phone at the till.
Chains & institutions
Full KYB, reconciliation files and batch operations — built for chains, hotels and institutional acquiring.
Static QR · T+0 settlement
Print one code and place it at the counter. The receipt records the final state and the payer sees your attested registry name. The code is static; the registered name remains controlled.
| Tier | Listed | Note |
|---|---|---|
| Private transfers | 0 | Policy capability, where enabled |
| T0 stallholder | 0.3% | Launch waivers apply |
| Standard | 0.8% | Listed standard price |
Listed standard − launch waiver = amount charged, itemised on every statement. Figures are illustrative.
A real backstop
Refunds always return along the original route; disputes go to human arbitration, raised within 30 days, fully logged.
Merchant partnerships · hello@mpay.msThis section describes mechanisms with illustrative figures; it is not an offer. Final fees, limits and onboarding conditions follow formal announcements.
Ecosystem map
Identity is the door, the gateway guards the funds —
Mpay is the hand that reaches for the phone
MID establishes the verified person or business. Meridian One is the service gateway. M Gateway controls entry, exit, rates and reserve evidence. Mpay is the acceptance surface where the merchant, payer, price and receipt meet.
MID accountIdentifies youA verified person or business under every account — no anonymous money.
MpayCompletes acceptanceScan, confirm, co-sign — finality is expressed as receipt evidence.
SignProves the receiptEach accepted transaction is anchored to the ledger for independent review.
M GatewayPublishes the evidenceRates on the wall, reserves reconciled — a controlled gateway, not a market venue.
One sentence that fixes the system: MID identifies the party · Mpay completes acceptance · Sign proves the receipt · M Gateway publishes rate and reserve evidence.
Public surfaces registry
One ecosystem, separate public roles
Mpay does not carry the whole public infrastructure story alone. Each surface has a defined role, so identity, services, gateway evidence, acceptance and verification can be reviewed without collapsing into one product claim.
MSDInstitutional context and identity framework
Meridian OneService gateway and user-facing entry point
M GatewayRate, reserve and gateway evidence
MpayMerchant acceptance and settlement evidence
M WalletCustody, keys and controlled authorisation
M PhonePhysical terminal for identity, payment and service access
M ChainTrusted memory and permissioned records
VerifyIndependent proof and receipt review surface
FAQ
The eight questions we hear most
Public assurance
Boundaries first; services only by formal announcement
The page is intentionally strict about what Mpay is and is not. Before any pilot opens, the public should understand the operating boundary, the evidence path and the reviewable record.
No download, sign-up or service opening without formal announcement.
No public balance, custody, trading, deposit or speculative interface.
Merchant identity and registry names remain part of the acceptance record.
Receipts, statements, rates and reserve evidence are designed to survive the counter moment.
Can I download Mpay now?
Not yet. The system is at concept stage, with legal and regulatory arrangements being structured with the relevant partners and authorities. Services open progressively with the pilot, per formal announcements — and this site deliberately has no download or sign-up of any kind.
What settlement balance is used?
The acceptance surface may reference USDM, the ecosystem settlement asset, and a jurisdictional local digital currency. Merchants show one local-currency price; any conversion line is disclosed at the published rate.
What are the merchant charges?
Merchant charges, waivers and limits are illustrative until formal announcement. The design principle is statement-level clarity: listed standard price − approved waiver = amount charged, itemised on every statement.
How long does settlement take?
T+0 finality is the design target in the permissioned settlement environment — typically seconds. The user sees a final receipt state, not a public market or public balance surface.
If I lose my phone, does the account remain protected?
Yes. Each approval needs biometrics and MID account signing together — a phone alone cannot authorise account movement. A new device goes through identity recovery, with a protection window after restore.
What if the QR code was swapped?
The name on the confirmation page comes from the system registry, never from the sticker. A swapped code shows an unfamiliar registered name, which means the payer should not approve. That is structural protection, not sharp eyesight.
How do I prove an acceptance happened?
Each accepted transaction issues a receipt anchored to the ledger and designed for independent verification, including offline verification. The verification service lives on its own domain and opens with the pilot.
I run a shop — how do I sign up?
Three tiers: T0 stallholder opens in minutes fully online; T1 registered adds a licence and basic checks; T2 full serves chains and institutions. See the merchants section above and write to us.
Simple at the counter, structured underneath
Mpay is designed to feel light at the moment of acceptance and serious in the record afterwards: attested merchant, controlled approval, final receipt, and evidence that can be reviewed beyond the counter.
