---
title: "How a stablecoin payin works step by step (ACH, wire, SWIFT, and Pix to USDC)"
seoTitle: "How a stablecoin payin works: ACH, wire, Pix to USDC"
description: "How does a stablecoin payin work? Follow eight steps from bank transfer to USDC in a wallet, with timing by rail, checks, webhooks, and failure cases."
date: "2026-10-19"
category: "payments"
author: "BlindPay Team"
howto:
  name: "How a stablecoin payin works from bank transfer to wallet"
  steps:
    - name: "Verify the customer"
      text: "Have the customer accept the provider's terms and complete KYC or KYB. Wait for an approved status before you ask for deposit details."
    - name: "Create the deposit destination"
      text: "Create a virtual account for repeat deposits, or request a payin quote for a single payment, and link the wallet that will receive the stablecoin."
    - name: "Share the deposit details"
      text: "Show the payer the account number, memo code, Pix code, or other instructions returned by the API for their rail."
    - name: "Let the payer send the transfer"
      text: "The payer sends a normal bank transfer or Pix payment. Nothing crypto-related happens on their side."
    - name: "Wait for detection and checks"
      text: "The provider detects the deposit, runs transaction monitoring, and may hold it for review. Track the payin status and tracking steps."
    - name: "Convert and deliver the stablecoin"
      text: "The provider converts the deposit to USDC or USDT and sends it to the wallet you chose."
    - name: "Handle webhooks and reconcile"
      text: "Verify each webhook signature, dedupe by message ID, update your ledger on the status field, and compare payins with your records daily."
faq:
  - q: "How does a stablecoin payin work in simple terms?"
    a: "A customer sends a normal bank transfer to details you give them. The provider detects the deposit, checks it, converts the money to a stablecoin such as USDC, and sends it to the wallet you chose. Your system gets webhooks as each step changes, so you do not have to poll."
  - q: "How does ACH to USDC work?"
    a: "The payer sends an ACH transfer to a virtual account or to the instructions on a payin. When the ACH funds arrive, the provider converts the dollars to USDC and delivers them on-chain. ACH itself can take days, so the delay is usually the bank rail, not the blockchain."
  - q: "How long does a stablecoin payin take?"
    a: "It depends on the rail. BlindPay's docs show an arrival window of up to 5 business days for ACH and wire, and typically minutes for Pix, SPEI, Transfers, and PSE. Standard ACH is 1 to 3 business days in general. On development instances, payins complete in about 30 seconds."
  - q: "What checks happen before the money is converted?"
    a: "The customer passes KYC or KYB first. For virtual accounts, a compliance and bank review comes before the account is active. After that, transaction monitoring can flag a deposit and put it on hold for review. A held payin can ask for more information, and may be refunded."
  - q: "Can a stablecoin payin fail or be refunded?"
    a: "Yes. BlindPay payins end as completed, failed, or refunded. A deposit that never arrives can end as failed. A deposit held for review can end as refunded to the sender. Use the sandbox amounts of 666.00 and 777.00 USD to test both outcomes before launch."
  - q: "What does my system receive at each step?"
    a: "Webhooks: payin.new when a payin is created, payin.update when it moves through a step like an arrival check or review, and payin.complete when it finishes. Each payload has a status field and tracking objects. Read the status, not just the event name, because completion events can cover failed and refunded."
---

A customer sends a bank transfer to a virtual account, the provider screens and converts the deposit to a stablecoin, and the stablecoin arrives in the wallet you choose, with a webhook telling your system at each step. BlindPay runs this flow for ACH, wire, SWIFT, Pix, and other rails.

## Key takeaways

- The payer does a normal bank transfer. The provider handles the conversion and the on-chain delivery.
- The slow part is usually the bank rail, not the blockchain.
- Checks happen at onboarding, at account review, and during transaction monitoring.
- Webhooks report each step. Read the `status` field to know the real outcome.
- Test failed and refunded payins in the sandbox before you go live.

For the concepts first, see [what a stablecoin payin API is](/resources/more/what-is-a-stablecoin-payin-api) and [virtual accounts for stablecoin payins](/resources/more/virtual-accounts-for-stablecoin-payins).

## What are the steps from bank transfer to stablecoin in a wallet?

There are eight steps from a verified customer to a delivered stablecoin. A stablecoin is a digital token built to hold a steady value, like one US dollar. A wallet is an address on a blockchain that holds tokens.

1. **Customer verified.** The customer accepts the provider's terms and completes KYC (know your customer) or KYB (know your business).
2. **Virtual account created.** You create a virtual account for repeat deposits, or request a payin quote for one payment. You link the wallet that will receive the stablecoin.
3. **Deposit details shared.** You show the payer the account number, memo code, Pix code, or other instructions.
4. **Customer sends the transfer.** The payer uses their own bank app. They do not need a crypto wallet.
5. **Deposit detected.** The provider sees the funds arrive and creates or updates the payin.
6. **Compliance screening.** Transaction monitoring checks the deposit. A flagged deposit goes on hold for review.
7. **Conversion to USDC or USDT.** The provider converts the fiat to the stablecoin at the quoted rate.
8. **Delivery and webhook.** The stablecoin is sent to the chosen blockchain wallet, and a webhook tells your system.

In BlindPay's quote-based flow, the quote locks the amount, fee split, and destination for 5 minutes, and you create the payin before it expires. Once created, a payin cannot be canceled. See [Payins](/docs/payins). A virtual account skips the quote: each deposit creates a payin automatically.

## How long does each rail take (ACH, same-day ACH, wire, SWIFT, Pix)?

Each rail has its own clock. The table shows typical timing for the rail in general. It is typical for the rail, not a BlindPay commitment. Settlement windows and cut-offs come from BlindPay's [cut-off times](/docs/kb/cut-off-times) reference, which describes the networks, not BlindPay's end-to-end time.

| Rail | Typical timing for the rail | Cut-off (ET) | BlindPay arrival window |
| --- | --- | --- | --- |
| ACH | 1 to 3 business days | 9:00 PM | Up to 5 business days |
| Same-day ACH | Same business day | 3:00 PM | Not listed separately |
| Domestic wire | Same business day | 3:00 PM | Up to 5 business days |
| International SWIFT | Up to 5 business days | 10:30 AM | Requires an approved virtual account |
| Pix (Brazil) | Typically minutes | Not applicable | BlindPay waits up to 30 minutes before marking a non-OTC payin `failed` |
| SPEI (Mexico) | Typically minutes | Not applicable | Waits up to 30 minutes before marking `failed` |

Requests after a cut-off are processed the next business day. Business days exclude weekends and holidays. Bre-B deposits in Colombia are final in seconds. On a development instance, every payin completes about 30 seconds after creation. For a longer guide by rail, read [how long a stablecoin on-ramp takes](/resources/more/how-long-does-a-stablecoin-onramp-take).

## What checks happen before funds are converted?

Three layers of checks happen before a stablecoin reaches the wallet. The first is customer verification. The second is account review for virtual accounts. The third is transaction monitoring on the deposit itself.

- **Customer verification.** KYC Standard for individuals is automated and typically completes in about 60 seconds. Higher-risk countries need KYC Enhanced with manual review. Businesses complete KYB.
- **Virtual account review.** In production, a virtual account starts in `pending_review` for a compliance review, then moves to `verifying` for the bank. Either stage can reject.
- **Transaction monitoring.** BlindPay's monitoring system can flag a payin as suspicious and hold it. The payin shows `on_hold`. Compliance may send a Request for Information, and if it is not answered within 24 hours the transaction may be refunded to the sender. See [on-hold transactions](/docs/kb/on-hold-transactions).

For SWIFT, BlindPay requires an approved virtual account. There is no memo-code fallback.

## What does my system receive at each step?

Your system receives webhooks and can also poll the API. BlindPay's payin events are `payin.new`, `payin.update`, and `payin.complete`.

| Step | Event or object | What it tells you |
| --- | --- | --- |
| Payin created | `payin.new` | A payin exists. Also fires for a deposit into a virtual account |
| Arrival check or review | `payin.update` | The payin moved through an intermediate step |
| Finished | `payin.complete` | The payin ended. Check `status` for completed, refunded, or failed |
| Any time | `GET` payin | Current status and `tracking_*` steps |

The payin `status` is `processing`, `on_hold`, `completed`, `failed`, or `refunded`. Three tracking objects, `tracking_transaction`, `tracking_payment`, and `tracking_complete`, show a finer step for each stage. The final transaction hash appears in `tracking_complete`. Treat `status` as the source of truth, because the hash can change if the on-chain transaction is replaced.

To handle events safely, verify the signature on the raw body, dedupe by message ID, and never move a payment backward from a final status. See [webhook handling and reconciliation](/resources/more/stablecoin-api-webhooks-reconciliation).

## What can go wrong?

Most problems are late funds, missing references, holds, and refunds. Use this list to plan for them.

1. **Deposit never arrives.** The payin stays `processing` until the monitoring window ends, then can become `failed`.
2. **Missing or wrong reference.** On the memo-code path, a deposit without the right code is harder to match. A virtual account avoids this.
3. **Funds arrive late.** For Transfers (Argentina) payins, BlindPay revives a failed payin to `processing` if matching funds arrive before any stablecoins were sent.
4. **Held for review.** The payin shows `on_hold` until compliance releases or refunds it.
5. **Refund.** The deposit is returned to the sender and the payin shows `refunded`.
6. **Fees consume the amount.** If fees leave a receiver amount of 0, the payin completes without an on-chain transfer.

Test these cases before launch. On a development instance, a payin quote with a request amount of $666.00 forces `failed`, and $777.00 forces `refunded`. The [guide to failed on-ramp deposits](/resources/more/why-crypto-on-ramp-deposits-fail) covers each cause in detail. If you are comparing ACH options, read [ACH pull vs ACH push](/resources/more/ach-pull-vs-ach-push-onramp).

## Where does BlindPay fit?

BlindPay converts funds that arrive by bank transfer into USDC or USDT and delivers them to a wallet you choose. These facts come from the BlindPay docs.

- Payin methods include ACH, wire, RTP, international SWIFT, Pix, TED, SPEI, Transfers, PSE, Bre-B, card, and ACH pull.
- The destination is a customer-controlled external blockchain wallet (`bw_...`) or a BlindPay-managed wallet (`bl_...`), which is BlindPay-custodied and in beta.
- Fees depend on the rail and network, and the quote shows them before you execute. See [pricing](/pricing).
- US virtual accounts cost $1.50 per month per account. See the [virtual accounts page](/virtual-accounts).
- The [quickstart](/docs/quickstart-payin) walks a payin through on a development instance, and the [`integrate-payins` prompt](/prompts/integrate-payins) helps an AI agent build it.

## Sources

- BlindPay docs, [Payins](/docs/payins), [Cut-off times](/docs/kb/cut-off-times), and [On-hold transactions](/docs/kb/on-hold-transactions)
- BlindPay docs, [Webhook events](/docs/learn/webhooks-events) and [KYC basics](/docs/kb/kyc-basics)
- Nacha, [Same Day ACH and ACH network overview](https://www.nacha.org/)
- Federal Reserve Financial Services, [FedACH](https://www.frbservices.org/financial-services/ach) and [Fedwire](https://www.frbservices.org/financial-services/wires)
- Swift, [cross-border payments overview](https://www.swift.com/)
- Banco Central do Brasil, [Pix](https://www.bcb.gov.br/estabilidadefinanceira/pix)

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