How Moneva intends to fund every QR payment at confirmation, per transaction, on-chain. Prepared for the Plus Billetera SA team.
Scan, quote, confirm, execute, notify. Clause 2.2 of the agreement, exactly as the APIs expose it.
The end user scans the merchant's interoperable QR inside the Moneva App or an app built on the Moneva Platform.
scanReturns the quote and a lock code. Amounts are fixed for the validity window.
quoteThe user approves the exact amount and rate before anything moves.
confirmExecutes the locked payment against the lock code.
executeThe merchant receives the payment on interoperable rails.
payoutThe webhook reports the final status back to Moneva.
eventB2C at the counter, all of the machinery underneath. A worked example, amounts illustrative.
Dinner in Palermo. The user scans the restaurant's interoperable QR, the same code every wallet in Argentina scans.
The app shows ARS 14,250.00 and exactly USDC 10.05 to be debited. Every fee is already inside; the number on screen is the number that moves.
Face or fingerprint approves it. Nothing has moved until this moment, and nothing else can move after it.
The merchant sees the payment approved on their own terminal, like any QR payment they take all day. The user keeps a receipt with the same reference we all reconcile by.
One reference from the user's receipt to your ledger to the chain.
The lock code ties the three legs together: quote, on-chain transfer, execution. Manteca is covered at every step.
The payment lock fixes the ARS amount and the stablecoin amount for its validity window. The quote the end user confirms already carries every fee.
On confirmation the stablecoin moves from the end user's wallet to your settlement address, referenced to the lock code, with your fee as its own leg.
We call POST /synthetics/qr-payment only once the transfer is confirmed on-chain, seconds on the settlement network, and you verify receipt at your own address before paying out.
Instantly, from your principal account; the payment's funds arrive to you carrying the same lock code.
// lock response { "ars_amount": 14250.00, "asset": "USDC", "asset_amount": 10.05, "lock_code": "LK-83F2-71", "expires_in": 120 } // on-chain transfer · every fee settled in the same transaction { "reference": "LK-83F2-71", "legs": [ { "to": "0xA1b2…M4nt", "amount": 10.05 }, // payment { "to": "0xA1b2…M4nt", "amount": 0.02 }, // your 0.20% { "to": "0x9Fc4…M0nv", "amount": 0.05 } // platform fee ], "status": "CONFIRMED" } // webhook SYNTHETIC_STATUS_UPDATE · SUCCESS
Values illustrative. The lock's quote is the source of truth for both amounts.
Both sides read the same on-chain event independently. Nothing in the flow settles on trust.
The app builds the transfer from the lock itself: exact amount, your address, the lock code. The user confirms biometrically and our infrastructure broadcasts. There is nothing to alter, replace, or underpay.
One lock code means one quote, one transfer, one execution, one refund at most. Idempotency keys guard every hop, so double taps, retries and replays cannot create a second payment.
Execution waits for on-chain confirmation, and you verify receipt at your own address before paying the merchant. Money you already hold is the only trigger.
No confirmation inside the lock window means no execution. A failed execution after funds land returns them on-chain to the user, referenced to the same lock code.
Your capital comes back the moment each payment happens, fees included, and the commercial terms do not move.
Each row is an operational default we propose; confirm or amend and it becomes the annex.
Nothing here is speculative. This is the settlement standard we already operate with our other payment partners across the network, applied to QR.
The rest of the agreement reads well from our side; two small legal notes follow separately. We settle fee legs inside transfers in production today; this annex applies the same mechanism to QR.