How Long Does a USDT Payment Take, and Where Does the Money Go?

by PayFi · 5 October 2026 · Getting paid

About 20 seconds after a buyer pays, the seller has 99 percent in their wallet and the buyer has the product. Every step of those 20 seconds leaves a record that both of them can check, without asking anyone.

Twenty seconds that nobody explains

Let's follow one small sale. The people in it are made up, but every step is real.

Lina makes photo presets, the little filters that give pictures a certain look. She sells a pack of twelve for 19 dollars through a payment link in her bio. Dev, who lives on the other side of the world, has been looking at her photos for weeks. One evening he taps the link, sees the pack and the price, and decides to buy.

He sends 19 USDT from his wallet. Then he waits, looking at the screen.

At that moment, both of them are asking the same quiet question from opposite sides. Dev is asking: did it work? Did my money go somewhere real, and will I get what I paid for? Lina, if she happens to be watching, is asking: did I get paid? Is this money mine, or could it still disappear?

Most payment systems never explain what happens in the gap between "pay" and "done". You click, a spinner turns, and something somewhere decides. This essay opens that gap up. We will walk through those twenty seconds one step at a time, from Dev's side and from Lina's. Then we will look at what happens in the hours after, when the sale becomes part of a record that nobody, including the payment service itself, can quietly change.

The point is not to make you an expert in blockchains. The point is that when you know what happens after you click, you stop having to trust it blindly. You can check it.

The old belief: "paid" means paid

Before we start the clock, it helps to look at a belief most of us carry from card payments.

When you pay by card in a shop or online, the screen says "approved" in a second or two. It feels like the money moved. For the buyer, that is mostly true: the purchase is done. For the seller, it is not.

What actually happened in that second is a promise. The card network said the money will come. The seller then waits for it to be settled and paid out. Stripe, for example, says a new seller's first payout typically arrives within 7 to 14 days (Stripe Docs). And even after the money arrives, it is not fully the seller's yet. Stripe explains that card networks typically allow cardholders to dispute a payment within 120 days, and sometimes longer. If a buyer disputes, the money is taken back from the seller's balance along with a dispute fee, and the whole process can take two to three months to finish (Stripe Docs). For payment methods like PayPal, Stripe notes the window can be up to 180 days (Stripe Docs).

So for a card seller, "paid" really means "probably paid, unless something happens in the next four months". That is a design choice. It protects buyers, and it has real value. But it means the seller is never quite sure when a sale is finished.

A stablecoin payment on a fast network works differently. When the payment is confirmed, it is settled. There is no later step where the money arrives, and no window in which a bank can pull it back. Let's see what that looks like, second by second.

Second 0: Dev sends the payment

When Dev started his order, the payment page showed him three things: the amount, 19 USDT; the network, Solana; and an address made only for his order.

That last part matters more than it looks. Many older crypto checkouts show the same address to everyone. Then, because the page cannot tell which payment belongs to which buyer, they ask the buyer to paste a long transaction code to prove that the payment was theirs. That is confusing, and it is easy to get wrong.

An address made for one order solves this. Any payment that arrives at that address belongs to Dev's order, and nothing else. Dev does not have to prove anything. He just sends.

So Dev opens his wallet, chooses send, picks USDT on Solana, pastes the address with the copy button, types 19, and confirms. His wallet signs the payment and passes it to the Solana network.

From Dev's side, the work is done. Everything that happens next is the system's job, not his.

Seconds 1 to 2: the network writes it down

The Solana network is a large group of computers around the world that keep a shared record of payments. They add new entries to that record in short steps called slots. According to Solana, a slot now lasts about 300 milliseconds, down from 400 milliseconds before, with a plan to go lower (Solana). That means the network writes a new page of its record roughly three times every second.

Dev's payment lands on one of those pages within a moment of being sent. Other computers in the network then confirm that page. After a short time, the payment is final: it is part of the shared record, and it cannot be removed.

Notice what did not happen here. No bank looked at the payment. No payment company approved it. Nobody checked who Dev is or who Lina is. The network only checked that Dev's wallet had 19 USDT and that he signed the payment. That is all a payment needs.

Seconds 2 to 10: the page notices

Now the payment page has a job. It needs to see that Dev's order address received the money, and check that it is the right amount.

It does that by watching the address it created for this order. When the 19 USDT appears, the page checks a few things. Is it the right token, USDT or USDC? Is it on Solana? Is the amount at least what the order asked for?

If everything matches, the order moves forward.

If Dev had sent a little less, say 18 instead of 19 because his exchange took a fee out of the amount, the page would not fail or freeze. It would tell him that 1 USDT is still missing and ask him to send it to the same address. When the rest arrives, the order continues as normal.

This is a small detail, but it shows a way of thinking. The system is built for real people who make small mistakes. It does not punish them for those mistakes, and it does not need a support person to fix them.

Seconds 10 to 20: the split

This is the step that matters most to Lina.

Dev's 19 USDT is sitting at the order address. Now it has to go where it belongs. A payment link that pays sellers directly does this in one single transaction on the blockchain. That one transaction sends 99 percent, 18.81 USDT, to Lina's wallet, and 1 percent, 0.19 USDT, to the payment service as its fee.

Why does "one single transaction" matter? Because a blockchain transaction either happens completely or does not happen at all. There is no state where Lina got paid but the fee did not, or the fee was taken but Lina's share is stuck. The money moves together, in one step, or it does not move. People call this "atomic", which is just a technical way of saying "all at once, or not at all".

The split usually happens within about 20 seconds of the payment arriving. When the network is very busy, it can take a few minutes.

There is something honest to say here. During those few seconds, between Dev's payment arriving and the split, the order address is controlled by the payment service. That is a short moment of custody. It is needed because the money has to be checked and split before it can be sent on. A system where the buyer signs the split directly from their own wallet would avoid it, but most buyers who pay from an exchange cannot do that. So a service that wants to work for everyone has to accept this short moment, and the right thing to do is to say so clearly.

What matters for Lina is what happens next. Her share does not go into a balance on someone else's website. It does not wait for a payout schedule. It goes to her own wallet, in the same transaction, and it is hers. There is no running pile of her money anywhere for anyone to hold back.

The product opens

While the money is being split, Dev is still watching his screen. And now it changes. The page says the payment is confirmed, and a button appears.

What the button does depends on what Lina sells.

• If she sells a file, like her preset pack stored in Google Drive or Dropbox, the button opens the download link.
• If she sells access to something private, like a members-only page or a private group, the page sends Dev there.
• If she sells a service, like a design job or a consultation, Dev gets a receipt: an image with the amount, the time in UTC, a note from Lina describing what was paid for, and the transaction record.
• If she sells something that needs instructions, like a license key with setup steps, the page opens a note she prepared with everything Dev needs.

This is the moment that matters most to Dev. Not the money moving, but the thing he paid for appearing on his screen, right away, without an email he has to wait for and without Lina having to wake up and send it.

For Lina, this is also the moment where one small setting matters. If her Drive file is not set to "anyone with the link can view", Dev will see a "request access" page instead of the presets. The money part works perfectly, and the delivery fails because of one checkbox. That is why it is worth testing your own link before you share it.

What Lina sees

Lina was asleep when Dev bought. When she wakes up, how does she know?

The simplest way is her wallet. Her wallet app shows that 18.81 USDT arrived, at a specific time, from a specific transaction. She can tap it and see the record on the blockchain.

If she wants a list of all her sales, she can open the seller page of the payment service and sign in with her wallet. Signing in this way does not create an account with a password or an email. Her wallet signs a short message that proves she owns the receiving address. It does not send money and costs nothing. The page then shows the sales that paid into that address.

If Lina wants to see all of this before a real buyer ever does, she can buy her own pack once, from her own link, at the lowest price the page allows. She will watch the same twenty seconds from both sides at the same time: the payment leaving, the presets opening, and 99 percent landing back in her wallet.

There is no step where Lina has to request her money, verify her identity to unlock it, or wait for a payout. The sale and the payment are the same event. When one happened, the other happened.

When things do not go perfectly

So far, Dev did everything right. Real life is messier, so let's look at what happens when he does not.

He sends too little. As we saw, the page tells him exactly how much is missing. He sends the rest to the same address, and the order completes.

He sends too much. The order completes, and the extra is not lost. Dev can ask for it back from his own private order page, minus a small refund fee. He does not have to contact Lina or anyone else.

He pays too late. Each order stays open for a fixed window, usually one hour. If Dev starts an order, gets distracted, and pays the next morning, the order has expired. His money still arrived at the order address. He can get it back from his private order page in the same way, and then start a new order if he still wants to buy.

He sends on the wrong network. This is the one mistake that cannot be fixed. If Dev sends USDT on Ethereum or Tron instead of Solana, the money travels on a different network and never reaches the order address at all. Nobody on the Solana side can see it or send it back. That is why a good checkout repeats the word "Solana" right next to the amount, before Dev pays.

The network is busy. Sometimes the network is slow for a few minutes. The payment still arrives, and the split still happens, just later than usual. Dev's order page keeps waiting and updates when it is done.

Notice the pattern. For every common mistake except one, there is a way back that Dev can use himself. The system does not need a support desk for small slips, because it was designed for them from the start.

Who pays what along the way

Money moving always costs something. It is worth knowing exactly where the costs fall, because surprises here are what make people distrust a payment.

Dev pays the cost of sending. When he sends 19 USDT from a wallet, the Solana network charges a small fee to record the payment. Solana's base fee is 5,000 lamports per signature (Solana Docs). A lamport is a tiny unit of Solana's own coin, so this is a very small fraction of a cent. If Dev sends from an exchange instead of a wallet, the exchange may charge its own withdrawal fee. That fee varies a lot between exchanges, so it is worth checking once.

Lina pays 1 percent. That is the 0.19 USDT that goes to the payment service in the split. There is no monthly plan, no fixed fee per sale, and no extra charge for buyers from other countries.

The service pays the cost of the split. The split itself is a blockchain transaction, and it also has a network fee. That fee is paid by the service, out of its own funds, not taken from Lina's share. Her 18.81 arrives as 18.81.

Compare this with a standard card sale. Stripe's standard US price is 2.9 percent plus 30 cents for a domestic card, with extra percentages for international cards and currency conversion (Stripe Pricing). On a 19 dollar sale, that is about 85 cents before any extras, compared with 19 cents. The difference per sale is small. Over hundreds of sales, it is not.

What the service knows about you

When people hear that a payment service does not ask for names or ID, a natural follow-up is: then what does it know?

For a service built this way, the answer is short. To deliver the product and pay the seller, it needs to keep a few things about each order: whether it is waiting, paid or finished; the amounts; the addresses involved; and the blockchain transactions that paid it. It does not need Dev's name, his email, his phone number or his country. It does not need Lina's either. It only needs her wallet address, because that is where her money goes.

This is not just a policy that could change on a quiet Tuesday. It follows from the design. A system that never asks for a name cannot leak one. A system that holds no running balance for sellers has no pile of money to freeze. Less data held means less that can go wrong.

To be complete and honest: the blockchain itself is public. Anyone who knows Lina's wallet address can see the payments it received, including Dev's. The service does not tie that address to her name. But if Lina posts her wallet address next to her real name somewhere, people can connect the two. Privacy here is about not handing your identity to the payment system. It is not about making your payments invisible.

How to check a payment yourself

Everything above says "you can check". Here is what that means in practice, for both sides.

If you are Dev, the buyer, open your wallet's history and tap the payment. Most wallets show a link to a block explorer, a public website that shows any Solana transaction. There you can see the time, the amount, the address you paid, and that the payment is confirmed. That page is your proof. It does not depend on the seller or on the payment service.

If you are Lina, the seller, do the same with the payment you received. You will see the split transaction: money coming from the order address, 18.81 going to you and 0.19 going to the service, all in one step. If the numbers in that transaction ever disagreed with what the service promised, you would see it there.

If you want to go further, open the service's public book. On the PayFi ledger page, for example, you can look up your own payment by your order link or your wallet address, and see the line that records it. You can download the whole book and run a free checker that compares every line with the blockchain. You do not need to do this every day. It is enough that you can, and that anyone else can too.

The hours after: the sale goes into the book

Here is where the story usually ends. Dev has his presets. Lina has her money. But there is one more thing that can happen after the sale, and it answers a question that both of them might have later: how do I know the payment service is honest?

It is a fair question. A payment service could, in theory, take a bigger fee than it says, quietly skip paying some sellers, or change its records afterward to hide a mistake. With most payment companies, you have to trust that they do not. You see what they show you on their website, and that is all.

A different approach is to keep a public book.

Every payment the service settles is written as a line in that book: the order, the amount received, the seller's share, the fee, and the blockchain transaction that paid it. Each new line includes a fingerprint of the line before it. A fingerprint here means a short code computed from the exact contents of the previous line. If anyone changed an old line, even by one digit, its fingerprint would change, and every line after it would stop matching. So the book can be added to, but it cannot be quietly rewritten.

The book is published, so anyone can download it and read it. And because the payments themselves are on the blockchain, anyone can compare each line in the book with the real payment it describes. Did the seller really get 99 percent? Was the fee really 1 percent? Is there any payment in the blockchain that is missing from the book? These are questions you can answer yourself, with a free checker, instead of asking the service to answer them for you.

Then the book is sealed into Bitcoin

There is one weakness left. A service could, in theory, rewrite the whole book from the beginning and publish the new version, with all the fingerprints recomputed. To prevent that, the book is sealed.

Sealing works like this. Every so often, the fingerprint of the latest line is sent to OpenTimestamps, a free public service whose job is, in its own words, to prove "that some data existed prior to some point in time" (OpenTimestamps). OpenTimestamps collects many fingerprints like this from many people and records them in the Bitcoin blockchain. Bitcoin adds a new block about every 10 minutes on average (Bitcoin Wiki), so within some hours the fingerprint is part of a Bitcoin block.

Once that happens, the book up to that line is fixed in time. If the service later published a different version of those lines, the fingerprints would no longer match what Bitcoin recorded, and anyone checking would see it.

This is not theory. PayFi's own public book was sealed into Bitcoin block 969,936 on October 5, 2026, and anyone can check the line it covers on the PayFi ledger page.

For Dev and Lina, this means something simple. Their sale is now a line in a book that the service cannot quietly change, and the proof of that sits inside Bitcoin, which nobody controls. If either of them ever wonders whether the payment happened the way the service says it did, they do not have to ask. They can check.

What "final" means for each of them

Let's come back to the question both of them were asking at the start, and answer it plainly.

For Lina, "paid" means paid. The 18.81 USDT in her wallet is hers. There is no payout to wait for and no 120-day window in which a bank can take it back. That is a big change from card payments, and it is one of the main reasons sellers choose this approach.

For Dev, "paid" also means final, and that cuts both ways. He cannot call his bank to reverse the payment if he changes his mind. So the protection he gets is different. He gets the product immediately, on his screen, before he has a chance to doubt it. He gets a public record that the payment happened. And for the cases where something did not complete, too much, too late, an expired order, he gets a refund option he can use himself.

What he does not get is a bank in the middle that will take his side in a dispute months later. That means the trust he places in Lina matters. A seller who describes the product honestly, whose file opens, and who answers messages is a seller worth buying from. The payment system can make the money honest. It cannot make the product good. That part stays between two adults who chose to trade.

A side-by-side look

To put the two models next to each other, here is what "after you click pay" usually means in each.

With a card payment:

1. The buyer sees "approved" in a second or two.
2. The seller sees a pending sale.
3. The money is settled later, and a new seller's first payout typically arrives in 7 to 14 days.
4. For about 120 days, sometimes longer, the buyer can dispute the payment through their bank.
5. If they do, the money and a dispute fee are taken from the seller, and the process can take two to three months.

With a stablecoin payment link on Solana:

1. The buyer sends the payment. The network records it within seconds.
2. The page sees it and checks the amount.
3. Usually within about 20 seconds, one transaction sends 99 percent to the seller's wallet and 1 percent to the service.
4. The product opens on the buyer's screen.
5. In the following hours, the sale is written into a public book and the book is sealed into Bitcoin.

Neither list is better for everyone. The first protects buyers through a bank and asks sellers to wait and to accept risk for months. The second gives both sides speed and proof, and asks buyers to trust the seller they choose. Knowing which one you are using is the first step to using it well.

Back to the twenty seconds

Let's return to Dev, looking at his screen, and Lina, asleep on the other side of the world.

In the first two seconds, Dev's payment was written into the Solana network's shared record by computers that do not know or care who he is. In the next few seconds, the payment page saw it at his order's own address and checked the amount. Within about twenty seconds, one transaction sent 18.81 USDT to Lina's wallet and 0.19 USDT to the service, all at once or not at all. The presets opened on Dev's screen. And in the hours after, the sale became a line in a public book whose fingerprint now sits inside Bitcoin.

Nothing in those twenty seconds asked for permission. Nothing held Lina's money. Nothing asked Dev for his name. And nothing in that chain requires either of them to take the service's word for it.

That is the shift this essay is about. The old belief says that what happens after you click pay is a black box, run by companies you have to trust. With a payment like this, it is not a black box. It is a short list of steps, each of which leaves a record. You do not have to understand all of them. It is enough to know that they are there, and that if you ever want to look, you can.

Sources

• Stripe Docs, "Receive payouts": docs.stripe.com/payouts
• Stripe Docs, "How disputes work": docs.stripe.com/disputes/how-disputes-work
• Solana, "Reduced slot times": solana.com/upgrades/reduced-slot-times
• Solana Docs, "Fees": solana.com/docs/core/fees
• Stripe, "Pricing": stripe.com/pricing
• OpenTimestamps: opentimestamps.org
• Bitcoin Wiki, "Block intervals": en.bitcoin.it/wiki/Block_intervals
• PayFi ledger: payfi.cx/ledger