Payments - Introduction / Learning brief
Mastercard Cross-Border Services
Your notes
In simple terms / 01
What this means in plain language
How a card-scheme cross-border service exposes a request and response API — payment requests with pre-agreed or one-shot quotes, balance requests, retrievable payment responses, and requests for information — illustrated conceptually with Mastercard Cross-Border Services.
A card scheme's cross-border service lets a bank or business send international payments through a request-and-response API (application programming interface). The application sends a structured request and receives a structured response. A payment request moves money: it can reference a quote the parties agreed earlier, or it can be a one-shot payment that carries the quote details inside the single request. The service replies with a payment response giving a status and an identifier, and that payment can later be retrieved by its identifier or by a reference the sender chose. A balance request asks how much funding is available and returns a balance response. The service also supports requests for information, or RFIs — structured questions the receiving side may raise, for example to clarify a beneficiary detail before completing a payment. This request-and-response shape keeps each interaction explicit and traceable. Mastercard Cross-Border Services is one such service; the description here stays conceptual and simplified.
Complete lesson / 02
Understand the full idea, step by step
Not every cross-border network asks you to fetch a quote before every payment. A card scheme's cross-border service offers a different shape: the bank's application speaks to the network in a small, fixed vocabulary of requests, and the service answers each one with a structured response. Learn the vocabulary and you have learned the service.
A bank-to-network, request-and-response model
The service is exposed as a request-and-response API (application programming interface): the application submits a well-defined request, and the service returns a well-defined response. This shape is deliberate. Each interaction is a discrete, self-describing exchange — a request goes in, a response comes back — which makes behaviour predictable and every step auditable. Because responses are structured and carry identifiers, the bank's systems can record outcomes and act on them automatically instead of interpreting free text. Note who talks to whom: the application talks to the network, and the network handles delivery in the destination country. The bank never sees the local rails on the far side.
The service's vocabulary
- Payment request → payment response
- Instructs the service to move money to a beneficiary; the response returns a status and an identifier
- Balance request → balance response
- Asks how much funding is currently available to the sender before committing payments
- Retrieval
- A payment can be fetched again later by the service's identifier or by the sender's own reference
- Request for information (RFI)
- A structured question, typically from the receiving side, that must be answered before processing continues
One payout through the service
- VALIDATION
Bank Alfa's application sends a balance request; the balance response confirms there is enough funding available to cover the payment before it is released.
- INSTRUCTION
The application sends a payment request for USD 7,300.00 — either referencing a quote agreed in advance, or as a one-shot payment carrying the quote details inside the single request.
- VALIDATION
The service validates the request and runs its checks; a problem surfaces as a structured status or an RFI, not a silent failure.
- MESSAGE
The payment response comes back with a status and an identifier. The status may not yet be final — a cross-border payout's outcome is not always known at the instant of submission.
- SETTLEMENT
The service delivers the money in the destination country — to a bank account, a wallet, or a card — and settles with its participants under scheme rules.
- NOTIFICATION
The application retrieves the payment later by identifier or reference, sees the status advance to completed, and closes its record — or investigates a failure with the same identifier in hand.
| Pre-agreed quote | One-shot payment | |
|---|---|---|
| How it works | A quote is agreed first; the payment request references it | Quote details travel inside the single payment request |
| Number of interactions | Two — quote, then payment | One — quoting and paying happen together |
| Best fit | A fixed price to show a customer or commit against later | The sender is ready to pay immediately |
Why would an application check its balance before every batch rather than just sending the payments?
Because a refused or held payment costs more to handle than a query costs to send. The balance request is a normal control step: a treasury or operations system confirms the available funding covers the batch before releasing it. It turns "send and hope" into "confirm, then send" — the same instinct behind quote-then-pay, applied to funding instead of price.
WHAT IF — The receiving side needs something more — a beneficiary detail is incomplete, or local requirements demand additional information before payout
What happens: The service raises a request for information (RFI): a structured question attached to the payment, which pauses rather than kills it.
How it is handled: Bank Alfa answers through the service's structured channel, and once the answer is provided the payment proceeds. Treating the question as a first-class message keeps the exchange orderly and traceable — an RFI is the process working correctly, not an error to be worked around.
COMMON CONFUSION
“Because a card scheme runs the service, the beneficiary must have a card to receive the money.”
The scheme is acting here as a network operator, not as a card product. Its cross-border service can deliver to bank accounts and wallets as well as cards, depending on the destination. What the scheme brings is its network, its participants, and central settlement under scheme rules — not a requirement that plastic be involved.
STRICTLY SPEAKING
Strictly speaking, this lesson teaches the pattern, not the product. Exact message fields, available options, corridors, and behaviours of Mastercard Cross-Border Services are defined by Mastercard's current documentation and change over time; nothing here is drawn from proprietary specification detail. The request-and-response vocabulary — payment request, balance request, retrievable responses, RFI — is the durable shape worth remembering.
FOR NOW, REMEMBER
- The model is bank-to-network: the application sends structured requests, the service returns structured responses, and the network handles delivery abroad.
- A payment request either references a pre-agreed quote or carries quote details as a one-shot; either way the payment response returns a status and an identifier.
- Balance requests are a funding control: confirm available funds before releasing payments.
- The identifier and the sender's reference make a payment retrievable — essential because the final outcome may arrive after submission.
- An RFI pauses a payment with a structured question; answering it lets the payment proceed.
TRY IT YOURSELF
Bank Alfa's application submits Asha Traders' USD 7,300.00 payment and receives a payment response whose status is not yet final. What should the application do?
You have now seen the landscape, the quote-then-pay pattern, and the bank-to-network model. The topic behind all three adds depth: how these networks fund themselves, where controls sit, and how they compare corridor by corridor.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
The service works as request and response: an application sends a request and gets back a structured reply.
- 02
A payment request can use a pre-agreed quote or carry quote details inline as a one-shot payment.
- 03
Payments are retrievable by identifier or reference, and requests for information handle clarifications.
Practical use cases / 04
Where you would use this
A bank sending outbound international payments on behalf of its corporate customers.
A treasury system checking available funding with a balance request before releasing payments.
An operations team answering a request for information to clarify a beneficiary detail.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Cedar Point Bank, sends a payment request for USD 8,750.00 to a beneficiary abroad, referencing a quote agreed earlier that morning. The service returns a payment response with status accepted and an identifier. Later, Cedar Point retrieves the payment by that identifier and sees status completed. Before releasing a second batch, its system sends a balance request and receives a balance response showing USD 250,000.00 available. When one payment needs a clarified beneficiary address, the service raises a request for information, and Cedar Point answers it to let the payment proceed.
Evidence & review / 07
Evidence & review
Card-scheme cross-border payout services generally; not tied to any Mastercard specification version.
What this brief simplifies: Exact field names, option sets, corridor coverage, and settlement mechanics are omitted — they are defined by the provider's current documentation. The six-step walkthrough compresses validation and delivery into single steps.
Sources for this brief1
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Conceptual model; Mastercard Cross-Border Services named factually as a public example, no proprietary specification detail
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.