---
title: "Why did my recipient get less? A support playbook for payout amount tickets"
seoTitle: "Why did my recipient get less? Payout support playbook"
description: "Six reasons a cross-border payout arrives short, what a support agent should look up for each, and reply templates that close the ticket."
date: "2026-10-08"
updated: "2026-10-08"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "Why did my recipient receive less than I sent?"
    a: "Usually one of six things: the rate moved before the quote was created, fees were deducted from the recipient side, the recipient's own bank charged a fee, a SWIFT correspondent took a deduction in transit, minor-unit rounding, or the payout fixed the sending amount instead of the receiving amount. The quote and payout records tell you which one in a few minutes."
  - q: "How do I prove what amount was sent?"
    a: "Start from the quote. It records the market rate, the rate applied, the amount sent, the amount the bank account should receive, and each fee line. Match it to the payout by id and check the final status. For SPEI, the recipient can also download Banco de México's CEP proof of payment, and for SWIFT the UETR lets every bank in the chain trace the same payment."
  - q: "Can a payout's rate change after I confirm it?"
    a: "Not on a locked quote. A BlindPay payout quote locks the exchange rate and fees, expires 5 minutes after creation, and backs exactly one payout. If the payout executes against that quote, the recipient amount on the quote is the amount sent to the bank. A rate that differs from a screen rate earlier in the day is a different question, usually about timing."
  - q: "How do I make sure the recipient gets an exact amount?"
    a: "Fix the receiving side and move the fees to the sender. On BlindPay that means currency_type receiver, so request_amount is the local currency the bank account gets, and cover_fees true, so fees are added on top of the stablecoin sent instead of deducted from the payout. Payroll and invoice payments usually want both settings."
  - q: "Who handles a recipient's complaint about a missing amount?"
    a: "Whoever owns the customer relationship answers first, using the quote and payout records. Escalate to the payout provider only when the records and the bank credit disagree, with the quote id, payout id, and rail reference attached. If you offer consumer remittance transfers in the US, Regulation E sets formal error resolution rules, including a 180-day window for senders to report errors."
---

A recipient gets less than expected for six reasons: the rate moved before the quote, fees came off the recipient side, their own bank charged a fee, a SWIFT correspondent deducted in transit, rounding, or the payout fixed the wrong side. The quote and payout records show which. This playbook maps each case to a lookup and a reply.

Amount tickets are the most common cross-border support question, and most of them are not errors. They are a gap between what someone expected and what the quote said. The fix is a routine, not a hunt.

**Key takeaways**

- Pull the quote before anything else. It shows the rate, both amounts, and every fee line.
- A locked quote doesn't change after confirmation. If the recipient amount matches the quote, the payout did its job.
- Fees deducted on the recipient side are the top cause. `cover_fees` decides who pays.
- Bank-side deductions and SWIFT correspondent fees happen after the payout leaves. Trace them with the rail reference.
- Most repeat tickets disappear once the confirm screen shows "they receive" before payment.

## What are the six reasons a recipient gets less?

Each has a different lookup and a different owner. Use this as the triage table.

| Ticket type | What the customer says | What to look up | Owner |
| --- | --- | --- | --- |
| Rate moved before the quote | "The rate was better this morning" | Quote `expires_at` vs the time of the rate they saw; `commercial_quotation` | You, with an explanation |
| Fees on the recipient side | "They got less than the amount I typed" | `cover_fees` and `currency_type` on the quote; `flat_fee` and partner fee lines | You, with a settings fix |
| Recipient bank charges | "My bank shows a lower credit" | Quote `receiver_amount` vs the bank statement; the rail | Recipient's bank |
| SWIFT correspondent deduction | "The wire arrived short" | `provider_uetr` and the rail; who paid intermediary charges | Correspondent chain |
| Rounding | "It's a few cents off" | Minor units on both amounts | You, usually closed as expected |
| Wrong side fixed | "I wanted them to get exactly R$ 5,000" | `currency_type` sender vs receiver | You, with a settings fix |

The first two account for most tickets in a stablecoin payout flow, because they live inside your own product. [How on/off-ramp providers make money](/resources/more/how-onramp-offramp-providers-make-money) explains why a fee can sit in the rate and in a flat line at the same time.

## What should an agent look up first?

The quote, joined to the payout. A BlindPay payout quote returns `id`, `expires_at`, `commercial_quotation` (the raw market rate), `blindpay_quotation` (the rate net of BlindPay's fee), `sender_amount`, `receiver_amount`, `flat_fee`, `partner_fee_amount`, and `billing_fee_amount` ([payout quotes docs](/docs/payout-quotes)). Amounts are integers in minor units.

Then check the payout: its `status` (`processing`, `on_hold`, `completed`, `failed`, `refunded`) and its tracking objects ([payouts docs](/docs/payouts)). A payout still `on_hold` hasn't paid anyone yet, so a "short" complaint may really be a "partly arrived" or "not arrived" complaint. [How to track an off-ramp payout](/resources/more/how-to-track-a-crypto-off-ramp-payout) covers the status reading.

Four questions, in order:

1. Does the bank credit equal `receiver_amount`? If yes, the payout paid what it promised.
2. Was `cover_fees` false? Then fees came out of the recipient's amount, by design.
3. Was `currency_type` sender? Then the stablecoin amount was fixed and the local amount floated with the rate.
4. Is the rail SWIFT? Then look for deductions after the payout left.

## How do you tell "the rate moved" from "the fees"?

Do the arithmetic on the quote. Illustrative example, with invented numbers:

A customer pays a contractor 1,000 USDC to BRL. They saw 5.40 on a rate site at 9:00. The payout quote was created at 14:00.

- `commercial_quotation`: 5.35. The market itself moved 0.05 since the morning. On 1,000 USDC that is R$ 50 of the gap.
- `blindpay_quotation`: 5.33. The conversion cost is 0.02 per USDC, or R$ 20.
- `cover_fees: false`, `flat_fee` equivalent to R$ 10, taken from the payout.
- Expected by the customer: 1,000 × 5.40 = R$ 5,400. Received: R$ 5,320.

So the R$ 80 gap splits into R$ 50 market movement, R$ 20 rate margin, and R$ 10 flat fee. Each part has a different answer. Only the last two are fees, and both were on the quote before the customer confirmed. [Why the Google rate differs from your quote](/resources/more/why-google-rate-differs-from-quote) is a good link to send with the reply.

## Which cases are the recipient's bank, not the payout?

Anything after the bank credit. If `receiver_amount` matches what left the rail but the recipient's statement is lower, the deduction happened at their bank or in the correspondent chain. [Fees to receive a local payout](/resources/more/recipient-fees-to-receive-local-payouts) lists what each rail's receiving banks tend to charge.

Give the recipient a way to check for themselves:

- **SPEI.** Banco de México's CEP tool issues a proof of payment for any SPEI transfer. The recipient enters the payment date, the clave de rastreo, which Banxico describes as an identifier of up to 30 alphanumeric characters, the sending and receiving banks, the CLABE, and the amount ([Banxico CEP](https://www.banxico.org.mx/cep/)).
- **SWIFT.** Every bank in the chain refers to the payment by the same UETR. BlindPay populates `provider_uetr` once the wire is confirmed, and the first 30 characters of the quote `description` reach the beneficiary as MT103 field 70 ([POBO and COBO](/docs/kb/pobo-cobo)). Send SWIFT (POBO/COBO) payouts with the invoice number first so the recipient can find the credit.
- **Pix, ACH, SEPA.** Ask for the statement line and compare it to `receiver_amount` in minor units.

## What reply templates work?

Short, numeric, and with one action. Fill the brackets from the quote.

**Rate moved:** "The payout used the rate locked at [time]: [blindpay_quotation] per USDC, and [recipient] received [receiver_amount], exactly what the quote showed. The rate you saw at [earlier time] was a market reference, not a quote. To lock a rate, confirm within 5 minutes of the quote."

**Fees on the recipient side:** "This payout was set so fees came out of the amount received: [fee lines]. If you'd like [recipient] to get the full amount, switch to sender-paid fees and we'll add them on top of what you send."

**Bank deduction:** "We sent [receiver_amount] over [rail], reference [rail reference]. The difference on [recipient]'s statement was charged by their bank after the credit. They can confirm the incoming amount with that reference."

**Wrong side fixed:** "The payout fixed the sending amount at [sender_amount] USDC, so the local amount followed the rate. For exact local amounts, set the receiving amount instead and we'll calculate what to send."

If you offer consumer remittance transfers in the US, check these replies against Regulation E. Its error definitions include the failure to make available to a designated recipient the amount of currency disclosed, and senders get 180 days after the disclosed date of availability to report one ([12 CFR 1005.33](https://www.law.cornell.edu/cfr/text/12/1005.33)).

## How do you stop the same ticket coming back?

Move the answer to the screen before payment. The quote already holds every number a recipient asks about later.

- Show "you send", "they receive", the rate, and each fee before the confirm button. [Quote screen fee disclosure](/resources/more/cross-border-quote-screen-fee-disclosure) has a layout.
- Default payroll and invoice flows to `currency_type: receiver` and `cover_fees: true`.
- Store the quote id with every payout so agents never rebuild the math by hand.
- Tag tickets with the six types above and review the counts monthly. A spike in one type is a product fix, not a support fix.

## What to do next

Pull the last 20 amount tickets, label each with one of the six types, and fix the setting behind the biggest group first. The [payout quotes docs](/docs/payout-quotes) explain `currency_type` and `cover_fees`.