Stablecoin payins for PSPs, remittance and payroll platforms: 3 use cases

PSPs use stablecoin payins to collect from customers abroad. Remittance companies use them to fund transfers from the sender side. Payroll platforms use them to fund contractor payouts from an employer's USD deposit. In all three, a payin turns a bank deposit into USDC or USDT, and a payout turns that balance into local money.

A payin is fiat coming in and stablecoins going out to a wallet. A stablecoin is a token pegged to a currency such as the US dollar. For the basic model, read what a stablecoin payin API is.

Key takeaways

• The payin is the same primitive in all three cases: a verified customer, a deposit, and stablecoins in a wallet.
• What differs is who the customer is and what happens next: settle to a merchant, pay a recipient, or pay a contractor.
• Each end party must be a verified customer in your instance. Moving money for parties BlindPay has not onboarded is a nested structure and is prohibited.
• Measure completion rate, time to funds available, hold rate and reconciliation match rate for each flow.
• The scenarios below are illustrative, not customer stories.

How does a PSP use stablecoin payins?

A PSP uses payins to collect from its clients' overseas payers without opening local bank accounts in every country. Each client gets its own virtual USD account. Payers send ACH, wire or SWIFT. Each deposit creates a payin and settles as stablecoins in the client's wallet.

On BlindPay, a US virtual account has its own routing and account number, belongs to one customer and settles to one blockchain wallet. A customer can hold more than one. Virtual accounts issued to an end user can send payouts under the end user's name (named payouts). Accounts cost $1.50 per month each, per the virtual accounts docs, and deposit fees depend on the size of the deposit. For the full model, see virtual accounts for stablecoin payins.

Illustrative scenario: a PSP collects invoice payments for a software client abroad.

Two controls matter for PSPs. First, each client must be its own customer. A virtual account that holds money for a party BlindPay has not onboarded is nested, and BlindPay's guidance is that such a business needs its own instance. Second, set your own fee. A partner fee is a markup you add on transactions, collected during each transaction and released to you monthly. See the partner fees docs.

How does a remittance company use them?

A remittance company uses a payin to take the sender's money in dollars, then pays the recipient in local currency. The payin is the funding leg. The sender pays by bank transfer, BlindPay detects the deposit, converts it, and credits the stablecoins. A payout then pays the recipient's bank account.

A payin quote locks the payment method, amount, fees and destination for 5 minutes, then the payin is created from it. ACH and wire payins can take up to 5 business days to arrive on production. Payers who connect a bank account through Plaid can fund by ACH pull, which adds a flat $1.00 fee and requires the Plaid feature on the instance (per the payins docs). Payout speed depends on the rail: Pix, SPEI and Argentine transfers are listed as instant, and ACH and wire in the US as about 2 and 1 business days. See collecting payments in Latin America for local rails, and building a remittance app for the app architecture and US disclosure rules.

Illustrative scenario: a sender in the US pays a family member in Brazil.

The app owns the sender relationship, the consumer disclosures and its money transmitter status. The payin API does not take those over.

How does a payroll platform use them?

A payroll platform uses a payin to receive the employer's dollars, then pays each contractor in local currency from that balance. The employer deposits USD by ACH or wire into a virtual account. The deposit settles as USDC or USDT in a wallet, and the platform runs payouts to each contractor's bank account.

Each contractor can be a customer with a bank account added once. Payouts need a funding source, a wallet the settlement stablecoins are pulled from. A BlindPay-managed wallet (beta, BlindPay-custodied) avoids client-side signing. An external wallet the customer controls needs an on-chain authorization first. Nothing needs to be pre-positioned in destination countries, but the funding wallet must hold the stablecoins when each payout executes. For sizing that balance, see the stablecoin payroll guide for LATAM contractors.

Illustrative scenario: a platform pays 50 contractors across Brazil and Mexico on the 1st.

Tax reporting and employment classification stay with the platform and the employer. Ask your tax adviser.

What should each team measure?

Each team should track a few metrics from the payin record, not from manual exports. Payin statuses are processing, on_hold, completed, failed and refunded, and each payin carries tracking_* steps, so most of these come straight from the API and webhooks.

Per-team focus: PSPs watch settlement time and hold rate by client. Remittance teams watch quote to payin conversion and delivery time to the recipient. Payroll teams watch deposit-to-payout time before a pay date, because a late deposit means a late payday.

What do all three need from a provider?

All three need the same things: per-customer bank details, verification in onboarding, clear states, local payout rails and visible fees. Use this checklist.

1. Per-customer deposit details. One virtual account per client, sender or employer, so each deposit is attributed without guesswork.
2. Verification in the flow. KYC and KYB with documented timelines and statuses. See KYC and KYB for stablecoin payins.
3. Webhooks and statuses. Events for payin.new, payin.update and payin.complete, plus payout.complete.
4. Local payout rails. Pix, SPEI, ACH, wire, SEPA and others for the corridors you serve.
5. Fees you can show. A quote that breaks down fees before execution.
6. Hold and refund behavior in writing. A payin on hold can wait up to 30 days. A deposit that fails review can be refunded.
7. A clear compliance split. Who runs the checks, who answers requests for information, and what your own program must cover.

A side-by-side look at providers is in best stablecoin payin APIs in 2026.

Where does BlindPay fit?

BlindPay is built for fintech, PSP, remittance and payroll teams that collect in dollars and pay out locally. The docs describe the pieces used above:

• Virtual accounts per customer, with ACH, wire and SWIFT payins for US accounts, settling to USDC or USDT.
• Payin methods including ACH, wire, RTP, SWIFT, Pix, SPEI, Transfers (Argentina), PSE (Colombia) and card.
• Payout rails including Pix, SPEI, ACH, wire, RTP, SEPA, Faster Payments, SWIFT, and Colombian and Argentine transfers.
• KYC and KYB in the same API, with a documented 60-second automated path for standard individuals.
• Pricing as a monthly plan plus per-transaction fees that vary by rail and network. The live quote shows the fee breakdown before you execute. See pricing.

BlindPay offers payins to an external blockchain wallet the customer controls, or to an optional BlindPay-managed wallet (beta). It does not replace your licensing, your disclosures or your tax work.

Sources

• BlindPay docs, Payins: /docs/payins
• BlindPay docs, Virtual accounts: /docs/virtual-accounts
• BlindPay docs, Partner fees: /docs/learn/partner-fees
• BlindPay docs, Pay out to bank (rails and estimated arrival): /docs/bank-accounts
• BlindPay docs, Nested payments: /docs/kb/nested-payments

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