Payments - Introduction / Learning brief
Thunes and quote-then-pay cross-border networks
Your notes
In simple terms / 01
What this means in plain language
How modern application programming interface based cross-border networks use a quote-then-pay model — locking an exchange rate for a short window, then submitting a payment order against that quote and tracking payout status through callbacks, illustrated with Thunes.
A modern cross-border network lets a business send money abroad by making two ordered calls to an API (application programming interface). First it asks for a quotation: it names the send and receive currencies and amount, and the network replies with an exchange rate and fees that hold for a short window — often up to 24 hours. Because the rate is locked, the sender knows the exact amount the recipient will get before committing. Second, the application submits a payment order that references that quotation, and the network pays out the funds over a local rail in the destination country, such as a domestic bank transfer or a mobile wallet credit. As the payout progresses, the network sends status callbacks — automatic messages reporting whether the payment is pending, completed, or has failed — so the sender's system stays updated without repeatedly asking. Thunes is one network that works this way; specifics here are kept conceptual and simplified.
Complete lesson / 02
Understand the full idea, step by step
A price you cannot know in advance is a hard thing to put on an invoice. Exchange rates move minute to minute, and under a classic correspondent chain the amount finally delivered can shrink along the way. The quote-then-pay model exists to remove exactly that uncertainty: fix the price first, in writing, and only then move the money.
Quote-then-pay
A two-step pattern exposed through an API (application programming interface). Step one is a quotation request: the application names the source currency, the destination currency, and either the amount to send or the amount the recipient must receive. The network answers with a quotation — a specific exchange rate and fee, producing an exact figure on both sides — locked for a defined validity window. Step two is a payment order that references that quotation by its identifier. Only in step two does money move. Thunes is one network built around this pattern; the description here stays conceptual rather than tied to exact field names.
| Recipient must receive | MYR 40,755.00 |
|---|---|
| Quoted rate | 1 EUR = 4.9400 MYR |
| Send amount | EUR 8,250.00 |
| Network fee | EUR 12.00 |
| Total debit to Asha Traders | EUR 8,262.00 |
Everything on this ticket is known before Asha Traders commits a single cent. The quotation fixes the rate and fee for its validity window, so the recipient amount, the send amount, and the total cost are all exact at decision time — which is precisely what a finance team needs for pricing, receipts, and reconciliation. Figures are illustrative.
One payment through a quote-then-pay network
- INSTRUCTION
The application sends a quotation request: source currency EUR, destination currency MYR, receive amount MYR 40,755.00.
The network returns a quotation with an identifier, the rate, the fee, and a validity window during which those terms are locked.
- INSTRUCTION
The application submits a payment order referencing the quotation identifier, carrying delivery details: the recipient's account or wallet, the payer's details for compliance, a purpose, and a reconciliation reference.
- VALIDATION
The network validates the order against the still-valid quotation and runs its checks — including sanctions and fraud screening on the parties. A match holds the payment for review: the control working as intended.
- SETTLEMENT
The network pays out over a local rail in Malaysia — a domestic bank credit, a real-time scheme, or a wallet top-up — funded from balances the network and its partners already hold there.
- NOTIFICATION
Status callbacks arrive at a URL the application registered in advance: accepted, pending at the local rail, completed, or failed — each carrying the transaction identifier.
Why split one payment into two API calls at all?
Because the two steps answer different questions. The quotation answers what will this cost — and locking it gives the sender certainty while a customer confirms or a batch is approved. The payment order answers deliver it to whom — it carries delivery and compliance detail rather than pricing, because the price is already fixed by the quote it references. The split also gives the network a clean, referenceable object to price against, and gives controls a natural moment to screen before value moves. It mirrors how a person expects a transfer to work: see the exact cost first, then commit.
Balance requests: knowing what you can spend
Payouts through such a network are typically prefunded: the sender holds a balance with the network, and payment orders draw it down. That makes one more API call essential — the balance request, which asks how much funding is currently available, per currency. A treasury or operations system checks the balance before releasing a batch of payment orders, so orders are not refused for lack of funds, and tops the balance up when it runs low. Prefunding is also part of why payouts can be fast: the money is already on the right side of the border before the order arrives.
WHAT IF — The application submits a payment order after the quotation's validity window has passed
What happens: The network refuses the order. No value moves, and the expired quotation cannot be revived — the rate it locked no longer reflects the market.
How it is handled: The application requests a fresh quotation and, if the new terms are acceptable, submits a new payment order against it. This is not a failure of the system but its core promise kept: the sender is never charged a rate it did not see and accept.
COMMON CONFUSION
“Once the quotation is locked, the money has effectively started moving — the payment order is just a formality.”
A quotation moves nothing. It is a price, held open for a window, and it costs the sender nothing to let it lapse. Value moves only when the payment order is accepted and the payout executes on the local rail — and even then, the outcome is confirmed by callbacks, not assumed. Quote, order, and callback are three separate events tied together by identifiers.
REMEMBER IT
Remember the chain of identifiers: quotation id → payment order → callback. One thread ties the price agreed, the money sent, and the final outcome into a single record — that thread is also the backbone of reconciliation. Good practice treats callbacks as the source of truth for status, with a direct status lookup as the fallback in case a callback is missed.
STRICTLY SPEAKING
Strictly speaking, the exact length of a quotation's validity window, the field names, the retry rules for callbacks, and the behaviour of individual corridors are set by each network's current documentation and vary between networks and versions — check the provider's live specification rather than quoting numbers. Thunes is named here factually as a public example of the pattern, not described from its proprietary specification.
FOR NOW, REMEMBER
- A quotation request locks a rate, fee, and exact amounts on both sides for a defined validity window — before any money moves.
- A payment order references the quotation's identifier and carries delivery and compliance detail; the network screens it before payout.
- Payouts are prefunded, so balance requests are part of normal operations: check available funds before releasing orders.
- Callbacks push each status change to the sender's registered URL; the shared identifier ties quote, order, and outcome into one reconcilable record.
- An expired quotation means a fresh quote, not a lost payment — nothing moves against a price the sender never accepted.
TRY IT YOURSELF
Asha Traders' finance team approved a payment on Friday, but the payment order reaches the network on Monday — after the quotation's validity window has passed. The euro has weakened over the weekend. What happens?
Quote-then-pay is one API shape. A card scheme's cross-border service shows another: a bank-to-network vocabulary of payment requests, balance requests, and structured responses — with Mastercard Cross-Border Services as the named example.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
The quote-then-pay model splits a transfer into a rate-locking quotation and a payment order that references it.
- 02
A locked quotation gives the sender an exact receive amount before any money moves.
- 03
Status callbacks report payout progress automatically so the sender's system stays current.
Practical use cases / 04
Where you would use this
A remittance app showing a customer the exact receive amount before they confirm a transfer.
A marketplace paying overseas sellers into local bank accounts or mobile wallets.
A payroll platform disbursing wages across several countries through one API integration.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional remittance app, SendBridge, wants to pay 100,000.00 in a destination currency to a recipient's mobile wallet. It requests a quotation and the network returns a rate that fixes the cost at USD 1,180.00 including fees, valid for 24 hours. SendBridge shows the customer the exact 100,000.00 receive figure, then submits a payment order referencing that quotation. The network pays out over a local wallet rail and sends callbacks: first status pending, then status completed within minutes. Because the quote was locked, the USD 1,180.00 cost did not change between the estimate and the payment.
Evidence & review / 07
Evidence & review
Quote-then-pay API cross-border networks generally; not tied to any provider's specification version.
What this brief simplifies: Field names, validity-window lengths, callback retry rules, and corridor behaviour are deliberately omitted — they vary by provider and version. Amounts and the FX rate in the calculation are illustrative.
Sources for this brief1
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Conceptual quote-then-pay teaching model; Thunes named factually as a public example
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.