Designing a payment quote users can trust

Quote design is where a cross-border payment product earns or loses trust, and it happens before any money moves. The failure is rarely that fees are high. It is that the landed amount does not match what the user expected, and nothing in the original quote explains why. Fixing that is a presentation problem with a small number of concrete rules.

Rule 1: lead with the landed amount

The recipient's amount, in the recipient's currency, is the headline. Not the send amount, not the fee, not the rate. Everything else is supporting detail that explains how that figure was produced. When a product leads with "low fees" instead, users correctly infer that the landed amount is the less flattering number.

Rule 2: itemise every cost

A crypto-to-local-currency transfer has at least four costs, and a single "total fee" line hides which one is large. Show them separately:

• Network fee — what the blockchain charges to include the deposit.
• Conversion cost — the spread between the mid-market rate and the executed rate on the crypto leg, including slippage.
• Platform fee — your own charge, as a percentage and as an amount.
• Payout fee and FX margin — the institution's charge for delivering local currency, and any margin applied to the fiat rate.

Itemising invites comparison, which is the point. A user who can see each component and still proceeds has genuinely accepted the price.

Rule 3: name the rate and its source

"Rate: 1 USDC = X" is incomplete. State whether it is indicative or executable, when it was retrieved, and how it relates to the mid-market rate. If the rate is indicative — which it is in any demo or pre-partner state — say so in the same visual element as the number, not in a footnote.

Rule 4: make expiry visible and honest

Crypto legs are priced against moving markets. A quote must therefore have a lifetime, and the interface must show it — a countdown, a refresh action, and a clear statement of what happens when it lapses. Two anti-patterns to avoid: a quote that silently updates while the user reads it, and one that never expires and is then not honoured. Both teach the user that the number is decorative.

Rule 5: separate what is charged from what is estimated

Some components are known exactly at quote time; others are not. Network fees and platform fees are typically knowable. Final slippage and the payout partner's FX rate at execution may not be. Group them visually — "fixed" versus "estimated, final amount confirmed at execution" — and state the worst-case landed amount under your slippage tolerance. A guaranteed floor is far more reassuring than a precise-looking estimate.

Rule 6: show timing per leg, not one number

"Arrives in minutes" is usually wrong, because the on-chain leg takes seconds while the fiat payout leg follows banking hours and clearing cycles. Give a per-leg expectation: conversion in seconds, settlement to the payout institution the same day, local payout within the destination rail's window. Users tolerate a slower honest estimate; they do not tolerate an optimistic one that slips.

Rule 7: the receipt must match the quote, field for field

The receipt is where trust is settled. It should carry the same line items as the quote, with actuals beside estimates, plus the transaction signature so the on-chain leg is independently verifiable. Any difference between quoted and actual should be visible and explained, not quietly absorbed into a new total.

A checklist for the quote screen

1. 1Landed amount in the recipient's currency, largest element on screen.
2. 2Send amount and asset, clearly the input.
3. 3Rate used, with source and indicative-or-executable status.
4. 4Four itemised cost lines, each with an amount.
5. 5Fixed versus estimated grouping, with a worst-case floor.
6. 6Expiry countdown and a refresh action.
7. 7Per-leg timing expectations.
8. 8Capability labels wherever a step is simulated, disabled or planned.
9. 9One-line statement of who holds the funds at each stage.

LamportPay's transfer demo follows this structure. Rates shown are indicative and labelled, fees are itemised, and each step carries its capability status — the SOL-to-USDC conversion runs live against Solana under strict limits with output returning to the user's own wallet, while identity checks, fiat conversion and local payout are simulated pending a regulated payout infrastructure partner.