Why did my recipient get less? A support playbook for payout amount tickets

Six reasons a cross-border payout arrives short, what a support agent should look up for each, and reply templates that close the ticket.

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 typeWhat the customer saysWhat to look upOwner
Rate moved before the quote"The rate was better this morning"Quote expires_at vs the time of the rate they saw; commercial_quotationYou, 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 linesYou, with a settings fix
Recipient bank charges"My bank shows a lower credit"Quote receiver_amount vs the bank statement; the railRecipient's bank
SWIFT correspondent deduction"The wire arrived short"provider_uetr and the rail; who paid intermediary chargesCorrespondent chain
Rounding"It's a few cents off"Minor units on both amountsYou, usually closed as expected
Wrong side fixed"I wanted them to get exactly R$ 5,000"currency_type sender vs receiverYou, 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 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). Amounts are integers in minor units.

Then check the payout: its status (processing, on_hold, completed, failed, refunded) and its tracking objects (payouts docs). 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 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 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 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).
  • 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). 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).

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 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 explain currency_type and cover_fees.

FAQ