Asynchronous Payment

An asynchronous payment is a payment for which the party that starts it does not receive a final answer straight away. The request is accepted, the payment is recorded as pending, and the success or failure is reported later, anywhere from a few seconds to several days afterwards. The term is used mainly by developers and payment providers to describe how a payment method behaves at the level of the interface.

It contrasts with a synchronous payment, where the reply to the request itself says whether the payment was approved, as with a standard card authorization. Whether a method is synchronous or asynchronous shapes how a checkout is built, when goods are released and how records are reconciled. Many alternative payment methods are asynchronous.

A payment is asynchronous when something has to happen outside the original request before the result is known. There are three common reasons.

• The customer must act elsewhere. With a bank redirect the buyer leaves the shop's site to approve the payment in a banking app. With a cash voucher such as Boleto in Brazil or OXXO in Mexico, the buyer receives a reference and pays it later at a bank or shop.
• The rail settles in batches. A direct debit or an ACH debit is submitted in a file, and the payer's bank may reject it one or more business days later for lack of funds or a closed account.
• A check takes time. A fraud review, a compliance screen or a manual approval may hold a payment before it is released.

The provider accepts the request and returns a payment identifier with a pending status. The merchant then learns the outcome in one of two ways. In the first, the provider sends a webhook notification to a callback URL on the merchant's server when the status changes. In the second, known as status polling, the merchant's system asks the provider at intervals what the current status is. Robust integrations use both: webhooks for speed and polling as a safety net in case a notification is lost.

The page the customer sees after returning from a bank or wallet is not reliable evidence of payment. The customer may close the browser before the redirect completes, or the redirect may arrive before the payment has been confirmed. Merchants are therefore advised to release goods only on the server-to-server confirmation.

Order systems must be able to hold an order in an intermediate state, reserve stock for a limited time, and cancel automatically if payment never arrives. Many providers model this as a payment state machine with defined transitions such as created, pending, succeeded, failed and expired.

Notifications can arrive late, twice or out of order, so the handler that processes them must be safe to run repeatedly. This property is idempotency: the second copy of a success message must not ship the goods again. Providers resend failed notifications under a webhook retry schedule, and merchants verify that each message is genuine by checking its signature.

Customer communication changes too. The confirmation page says that the order has been received and payment is awaited, and a second message is sent when funds are confirmed. For voucher methods, reminders before the reference expires raise the share of orders that are actually paid.

With some asynchronous methods a payment can appear successful and fail afterwards. A SEPA Direct Debit can be returned by the payer's bank after collection, and the payer can claim a refund of an authorized collection for a period of weeks under the scheme's rules. Merchants selling digital goods or services that are consumed immediately bear this risk if they deliver before the return window closes, and many restrict such methods to recurring customers or lower amounts.

Card payments are usually treated as synchronous, since the authorization response comes back within seconds. Later stages are asynchronous, however. Capture, clearing, settlement, refunds and chargebacks all occur after the fact and are reported through files and notifications. Authentication can also break the single request and response: a 3-D Secure challenge sends the cardholder to the issuer, and the merchant waits for the result before continuing. A complete card integration therefore still needs the same machinery for handling events and for payment reconciliation as any asynchronous method.