---
title: "What happens when a stablecoin payin fails, arrives late, or does not match?"
seoTitle: "Failed or late stablecoin payin: what happens next"
description: "Failed stablecoin deposit refund: why payins fail, late or mismatched deposits, and the support runbook, using BlindPay's real payin statuses."
date: "2026-10-28"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "What happens to my money if a stablecoin payin fails?"
    a: "It depends on how far the payment got. If the bank transfer never arrived, nothing moved and nothing needs returning. If the deposit arrived but could not settle, BlindPay can mark the payin refunded, which means the deposit was returned to the sender. A failed payin is final but is not the same as refunded, so check the status before telling the customer."
  - q: "How long does BlindPay wait for a payin deposit to arrive?"
    a: "It depends on the rail. ACH and wire payins can take up to 5 business days, TED up to 7 days. Pix, SPEI, Transfers, and PSE payins wait up to 30 minutes before BlindPay marks them failed. An OTC Pix payin waits until the 23:59 BRT cutoff instead. Always read the live status rather than assuming a window."
  - q: "Can a failed payin come back to life?"
    a: "In one documented case, yes. If the funding for a Transfers payin in Argentina arrives after it was marked failed, and no stablecoins were sent yet, BlindPay revives it to processing and completes it once the sender's tax id and amount match. The docs do not describe automatic revival for other rails, so treat those as support cases."
  - q: "What if the payer sends the wrong amount or the wrong reference?"
    a: "The deposit may not match its quote, so it can sit unmatched, fail, or be returned. Prevent it by showing the exact amount and the memo code, and by giving recurring payers a virtual account so the reference is not needed. If it happens anyway, collect the bank receipt and escalate to BlindPay with the payin id."
  - q: "Can I get stablecoins back if they were delivered to the wrong wallet?"
    a: "Usually not. Confirmed blockchain transactions cannot be reversed, and the payin delivers to the wallet you registered. Only the wallet's owner can send the funds back. That is why the address and network need checking when the wallet is added, before the first payin, and why the payer never picks the network on BlindPay."
  - q: "Does a compliance hold mean the payin failed?"
    a: "No. On hold means the payin is paused for a manual review and can still complete. BlindPay may send a Request for Information about the sender, the purpose, and the expected outcome. If that request is not answered within 24 hours, the transaction may be refunded to the sender, so answer it quickly."
---

A stablecoin payin fails for a short list of predictable reasons: the deposit never arrives, it arrives late, it does not match the quote, or a compliance review stops it. With BlindPay, a payin ends in one of three final statuses: `completed`, `failed`, or `refunded`. `refunded` means the deposit was returned to the sender. Your runbook should treat each one differently.

This page is the support guide for those cases. It builds on [why crypto on-ramp deposits fail](/resources/more/why-crypto-on-ramp-deposits-fail) and goes deeper on the payin side.

## Key takeaways

- Most payins fail on the fiat side (a missing reference, the wrong payer, a late bank transfer), not on the blockchain.
- `failed` and `refunded` are different outcomes. Only `refunded` means money is on its way back to the sender.
- Each rail has its own waiting window: about 30 minutes for Pix, SPEI, Transfers, and PSE, up to 5 business days for ACH and wire.
- A payin cannot be canceled once created, and a stablecoin delivered to the wrong wallet cannot be recalled.
- Write the customer messages before launch, not during the first incident.

## Why do payins fail?

Payins fail because the money that arrives does not match what the payin expected, or because it does not arrive in time. Six causes cover most tickets.

| Cause | What it looks like | Where to prevent it |
| --- | --- | --- |
| Deposit never arrives | The payin stays `processing`, then ends `failed` after the window | Show the deadline next to the payment instructions |
| Late deposit | Money lands after the waiting window closed | Request a new quote instead of reusing old instructions |
| Wrong payer | A Pix or Transfers payment from a tax id that is not on the allowlist | Set `payer_rules` on the payin quote |
| Wrong amount or missing reference | The deposit cannot be tied to one quote | Show the exact amount and the `memo_code`, or use a virtual account |
| Compliance hold | Status `on_hold`, then possibly `refunded` | Answer information requests quickly |
| Funding pull fails | An ACH pull that cannot start fails at once with `PAYINS_FUNDING_PULL_FAILED` | Check the connected bank account before the quote |

On Pix, BlindPay's `payer_rules` field takes `pix_allowed_tax_ids`, an array of CPF or CNPJ numbers allowed to send the payment. For Argentine Transfers it takes `transfers_allowed_tax_id`. BlindPay uses these to match and screen the incoming deposit, as the [payin quotes docs](/docs/payin-quotes) explain.

## What does the payer see?

The payer sees whatever instructions the quote produced, and nothing about a failure unless you tell them. BlindPay returns payment instructions that depend on the method: a memo code plus bank details for ACH and wire, a Pix code, a CLABE for SPEI, a CBU for Transfers, or a payment link for PSE. Your product has to show them, track the status, and message the payer when it changes.

Two details shape the experience:

1. A payin quote expires 5 minutes after creation, so a payer who waits too long needs a fresh quote.
2. A payin cannot be canceled. If the payer never sends the money, it stays `processing` until it is cleaned up on BlindPay's side.

Build your payer screen on the status, not on a timer. The [checkout payment instructions guide](/resources/more/checkout-payment-instructions-ux) covers how to show Pix codes, CLABEs, and memos.

## How are failed payins returned?

A failed payin usually has nothing to return, and a refunded payin returns the deposit to the sender. The statuses mean:

| Status | Meaning | Final? |
| --- | --- | --- |
| `processing` | Waiting for the deposit, or converting and sending stablecoins | No |
| `on_hold` | Held for manual risk or compliance review | No |
| `completed` | Stablecoins delivered to the destination wallet | Yes |
| `failed` | The payin did not go through | Yes |
| `refunded` | The deposit was returned to the sender | Yes |

Each payin also has `tracking_transaction`, `tracking_payment`, and `tracking_complete` objects with a finer `step`, such as `pending_review` or `pending_refund_review`. A step of `pending_refund_review` means a refund on that stage waits for manual review. Fiat refunds depend on the sender's bank network, so a refunded payin is not instant money.

BlindPay's docs do not state a fixed refund timeline or a refund fee for payins, so do not promise one to customers. Say the money is returning and that bank timing applies. The [payout statuses guide](/resources/more/stablecoin-payout-statuses-explained) covers the mirror case on the payout side.

If a payin lands on hold, [BlindPay's compliance team](/docs/kb/on-hold-transactions) reviews it and may send a Request for Information about the relationship between the sender and your customer, the purpose, and the expected outcome. If the request is not answered within 24 hours, the transaction may be refunded to the sender.

## How do I handle late or partial deposits?

Check the rail's waiting window first, then the status. A deposit is late only relative to the window for its payment method.

| `payment_method` | Waiting window on production |
| --- | --- |
| `ach`, `wire` | Up to 5 business days |
| `ted` | Up to 7 days |
| `pix` | Typically minutes. BlindPay waits up to 30 minutes before marking a non-OTC payin `failed`, after a reconciliation check |
| `pix` (OTC) | Until the 23:59 BRT cutoff |
| `spei`, `transfers`, `pse` | Typically minutes. BlindPay waits up to 30 minutes before marking the payin `failed` |
| `bre_b` | The payin is created when the deposit lands, which is final in seconds |

Two documented behaviors matter for late money:

- **Transfers revival.** If the funding for an Argentine `transfers` payin arrives after it was marked `failed`, and no stablecoins were sent yet, BlindPay revives it to `processing` and completes it once the sender's tax id and amount match.
- **OTC Pix penalty.** If an OTC `pix` payin fails because the deposit never arrives, a flat $100.00 penalty is added to the quote's billing fee. Warn large payers before they request an OTC quote. OTC quotes expire in 10 seconds and start at $5,000 USD equivalent, per the [payin quote docs](/docs/payin-quotes). See also [OTC quotes vs standard quotes](/resources/more/otc-quote-vs-standard-quote).

For other rails, the docs describe no automatic revival of a failed payin. Treat a deposit that arrives after the window as a support case: collect the payin id, the bank receipt, and the sender's name, then contact BlindPay.

Partial and mismatched amounts have no documented automatic rule either. The safe design is prevention. Show the exact `sender_amount` from the quote, show the memo code, and for recurring payers use a [virtual account](/resources/more/virtual-account-deposit-not-received), where each deposit belongs to a customer without a code. Virtual account deposits also create payins, and small ones have fee behavior described in the [virtual accounts docs](/docs/virtual-accounts).

## How do I handle a customer who sent to the wrong network?

On a BlindPay payin the payer sends bank money, not crypto, so the payer never picks a network. BlindPay detects the destination network from the wallet record you set on the payin quote. The wrong-network risk therefore sits at one moment: when your customer registers a wallet.

Blockchain transfers are final once confirmed. Ethereum's own [transaction documentation](https://ethereum.org/en/developers/docs/transactions/) (checked on 2026-10-28) describes a transaction as irreversible once included in a finalized block. A provider that does not hold the destination wallet's keys cannot pull the funds back. That is the case for a wallet the customer controls (`blockchain_wallet_id`, prefix `bw_`).

Reduce the risk before the first payin:

1. Show the network and token next to the address when the wallet is added.
2. Check the [supported chains matrix](/docs/kb/supported-chains) because USDC and USDT are not available on every chain.
3. Send a small test payin first for new wallets.
4. Never edit a wallet address silently. Make the customer re-confirm it.

If funds already went to a wrong or unreachable address, tell the customer plainly that only the address owner can return them. The [incident playbook](/resources/more/blockchain-payment-incident-playbook) has a six-step response.

## What should my support runbook say?

It should say what to look up, what each status means, who acts, and what to tell the customer. Use this scenario table.

| Scenario | What happens | Who acts | Typical resolution | Customer message |
| --- | --- | --- | --- | --- |
| Payer has not paid yet | Payin stays `processing` | Payer | Pay within the window, or start over | Template A |
| Deposit arrived after the window | Payin `failed`, money may sit at the provider | Support, BlindPay | Escalate with the payin id (auto-revival only on Transfers) | Template B |
| Compliance hold | Payin `on_hold` | You, BlindPay compliance | Answer the Request for Information within 24 hours | Template C |
| Refund after review | Payin `refunded` | BlindPay, sender's bank | Wait for the bank network | Template B |
| Stablecoins at the wrong wallet | Payin `completed` | Wallet owner | Only the owner can send them back | Template D |

Four ready-to-use messages (adapt the bracketed parts):

**Template A, not paid yet.** "We have not received your transfer for [amount]. Your payment details expire at [time]. If they expire, we will send you a new set. Please do not reuse the old details."

**Template B, failed or refunded.** "Your transfer did not complete. If it reached us, it is being returned to the account it came from. The time depends on your bank, so please allow [bank timing]. Your reference is [payin id]. Reply to this message if you do not see it."

**Template C, on hold.** "Your payment is in a routine review. We need to know who sent it, why, and what you expect to happen next. Please reply within 24 hours, because an unanswered review can end in a refund."

**Template D, wrong wallet.** "Your stablecoins were delivered to the wallet address on file, [address] on [network]. A confirmed blockchain transfer cannot be reversed by us. If you control that address, you can send the funds on. If someone else does, only they can return them."

Wire your alerts to the `payin.update` event and read the status in the payload. The [webhooks and reconciliation guide](/resources/more/stablecoin-api-webhooks-reconciliation) shows how to verify and deduplicate. In development, set `request_amount` to 66600 ($666.00) to force `failed` or 77700 ($777.00) to force `refunded`, so you can rehearse each message.

## Where does BlindPay fit?

BlindPay is a stablecoin API that collects fiat over ACH, wire, RTP, SWIFT, Pix, SPEI, Transfers, PSE, and card, then delivers USDC or USDT to a wallet. Facts that matter for failures:

- Final payin statuses are `completed`, `failed`, and `refunded`, with `on_hold` for manual review.
- Payins can deliver to a customer-controlled external wallet (`bw_`) or an optional BlindPay-managed wallet (`bl_`, custodied by BlindPay, beta).
- Webhooks fire on `payin.new`, `payin.update`, and `payin.complete`.
- Pricing is a monthly plan plus per-transaction fees disclosed in the live quote. See [pricing](/pricing) and the [payin API pricing guide](/resources/more/stablecoin-api-pricing-explained).
- Payin reference docs: [payins](/docs/payins).

Start with the hub, [what is a stablecoin payin API](/resources/more/what-is-a-stablecoin-payin-api), if you are new to the flow.

## Sources

- BlindPay docs, [Payins](/docs/payins), monitoring window and status lifecycle (checked on 2026-10-28)
- BlindPay docs, [Payin quotes](/docs/payin-quotes), `payer_rules` and OTC rules (checked on 2026-10-28)
- BlindPay docs, [On-hold transactions](/docs/kb/on-hold-transactions) (checked on 2026-10-28)
- BlindPay docs, [Cut-off times](/docs/kb/cut-off-times) (checked on 2026-10-28)
- Ethereum.org, [Transactions](https://ethereum.org/en/developers/docs/transactions/) (checked on 2026-10-28)

*This article is for general information only and is not legal, tax, or financial advice.*