TL;DR
Not all payments confirm at the same speed, and the gap matters more than it looks. Some methods tell you instantly whether the payment went through. Others leave a window where the payment is pending and the outcome is unknown. Whether a method is synchronous or asynchronous decides how the checkout behaves, when an order can ship, and how finance reconciles what actually landed.
Here's the difference, why it matters operationally, and why a cross-border business has to support both.
Synchronous: real-time confirmation
A synchronous method returns a definitive result at the moment of payment. The buyer pays, and within seconds you know it succeeded or failed. Cards are the familiar example, along with real-time bank rails and most wallets, where an authorisation or instant transfer confirms on the spot.
The advantage is operational simplicity. Because the outcome is immediate, you can release digital goods, confirm an order, or grant access right away, with no pending state to manage. Pay, confirm, done. For businesses selling instant or digital products, synchronous methods are the natural fit because they match the expectation of immediate delivery.
Asynchronous: confirmation on a delay
An asynchronous method doesn't return a final result at checkout. Instead, the buyer gets instructions to complete payment through a separate channel, a bank transfer from their banking app, or a cash voucher paid at a store or agent, and confirmation arrives later, when the funds actually move. The gap can be seconds for an instant transfer that completes out of band, or a day or more for a voucher paid the next morning.
The defining feature is the pending state. Between checkout and confirmation, the order exists but the payment isn't yet certain, and you have to decide how to handle that window: hold the order until funds confirm, or release on trust and risk non-payment. For physical goods that's usually a simple hold. Asynchronous methods trade the simplicity of instant confirmation for reach, because they include the methods that dominate cash-heavy and bank-transfer-first markets.
Why the distinction matters operationally
The nature of a method ripples through three parts of the business.
At checkout, the flows differ. A synchronous method ends in a confirmation screen. An asynchronous one ends in instructions and a pending status, and the buyer needs a clear message that payment isn't complete yet. Get that messaging right and a buyer won't assume they've paid when they only hold a voucher.
At fulfilment, the pending window forces a policy. For asynchronous payments you generally hold the order until funds confirm, so the fulfilment system has to understand pending states rather than treating every checkout as a completed sale.
At reconciliation, asynchronous methods separate the order from the money in time. A payment started today may settle tomorrow, so finance has to match funds to orders across that gap, far easier when each payment is attributable from the moment it's initiated, and when a day's orders and a day's confirmations rarely line up on the same clock.
Handling the pending state well
For asynchronous methods, the pending window is where conversions are won or lost, so it deserves deliberate design. The buyer needs an unambiguous message that payment isn't complete, clear instructions on how and where to pay, and a visible deadline before it expires. A buyer who leaves thinking they've paid won't go and pay, and that confusion, not the delay, is what loses the sale.
On your side, the pending state needs reliable signalling. Webhooks that fire the moment funds confirm let the order move from pending to paid without manual checking, and clean expiry handling releases held inventory when a transfer is never completed. Done this way, an asynchronous method behaves predictably.
Why cross-border businesses need both
A business selling only into card-dominant markets could live on synchronous methods alone. A cross-border business can't, because in much of the world the dominant local methods are asynchronous: bank transfers in many economies, cash vouchers across Latin America and parts of Asia. Refusing them means refusing how those markets pay, as covered in our guide to local payment methods in international payments.
A capable payment gateway handles both cleanly: instant confirmation where the method supports it, clear pending-state handling, webhooks, and reconciliation where it doesn't. The goal isn't to prefer one, it's to support each on its own terms, so you can accept the fast methods and the delayed ones without the delayed ones creating chaos.
Synchronous and asynchronous isn't a ranking. It's a description of how a method confirms. The businesses that sell widely built for both, because the world pays in both.
Sources
[1] Bank for International Settlements. "Fast payments." 2026.
.png)
