Synchronous or asynchronous: why a payment or SMS confirmation arrives later

Automation & n8n·· 29 views· 4 min read

The short answer: with a synchronous request, your site asks and waits until it has the final answer, as when it reads the status of an order. With an asynchronous request, the API answers straight away with “received, processing” and the result arrives later, by another route. Mobile payments, payments by reference or bank transfer, and SMS delivery are asynchronous by nature: they depend on a person confirming on a phone, a bank or a mobile network, and no server should sit waiting for that. This is for anyone wiring payments, SMS or other APIs into a site.

What is usually synchronous, and what is not

Situation Type Why
Looking up an order, a customer, a balance Synchronous The answer already exists on the other side: it just has to be read.
A payment the customer confirms on the phone (with a PIN or a code) Asynchronous The API accepts the request, but the outcome depends on the customer accepting, declining or letting it time out.
A payment by reference or bank transfer Asynchronous The customer pays when they pay, sometimes long after leaving the site.
A card payment on the operator’s page Looks synchronous The customer sees the outcome at once, but the confirmation you can trust is the notice the operator sends to your server. See callback URL or return URL.
Sending an SMS Asynchronous The API accepts the message and returns an identifier. Whether it was delivered or failed is only known later, from the delivery report that comes back from the network.
An export, a large report, a video conversion Asynchronous It takes time. The API returns a job identifier and tells you (or lets you ask) when it is done.

Handling an asynchronous response

1 Recognise the response. A 202 Accepted code, or a status such as “pending”, “processing” or “queued” in the JSON, means “got it, not done yet”. It is neither a success nor an error.
2 Store the identifier the API returns (for the transaction, the message, the job) with your order, before showing the customer anything. Without it, when the confirmation arrives you cannot tell which order it belongs to.
3 Mark the order as pending, not as paid or sent. On the thank-you page, tell the truth: “We have your order; as soon as the payment is confirmed, we will e-mail you.”
4 Collect the result one of two ways: the API calls an address of yours when it has the result (a callback or webhook), or your system asks for the status with the identifier every so often (polling). See webhook or polling.
5 Change the status only on a verified final answer: paid, declined, expired, delivered, failed. If the result comes by callback, make sure it really came from the service: receiving a webhook in PHP and checking its signature.
6 Deal with what never arrives. A scheduled task that looks for orders pending too long, asks the API for their status and decides (confirm, cancel, warn) catches the notices that got lost: running a PHP script from a cron job.
Do not make PHP wait for the confirmation inside the visitor’s request (a loop with sleep() that keeps asking the API). Every waiting visitor ties up a process, the request runs into the maximum execution time, and the customer ends up on an error page. See PHP limits and entry processes.
The page that “updates by itself” is a little JavaScript that asks your server for the order status every so often (never the API directly, which would expose the key). Your server answers with what it already knows, which is whatever the callback or the scheduled task left there.

Payments stay pending on your site while the operator says they are paid? Open a ticket with the time of one payment and the callback address you configured, and we will check whether the operator’s request reached the hosting.

Open a support ticket

SEE ALSO

Webhook or polling: how one system learns that something changed in another

Callback URL or return URL: why a customer coming back is not proof of payment

Timeouts, retries and idempotency: how not to charge a customer twice

Receiving a webhook in PHP and checking its signature

Running a PHP script from a cron job

How online payments work: gateway, processor and merchant account in plain words

RECOMMENDED PRODUCT

Web hosting with cPanel

Domain and SSL included, daily backups and the panel you already know. from 321,75 MT/mo (3-year plan, with coupon)

See plans
Was this answer helpful? Your answer helps us improve this article.

Related Articles

Automation & n8n 212 Cron jobs: what they are for and how to create one A scheduled task, or cron job, is an instruction the server runs at set times, whether you are there or not, whether the...
Automation & n8n 182 Swapping WP-Cron for a real server cron job WordPress has a scheduler of its own, WP-Cron, which handles scheduled posts, update checks, emptying the bin and the e-...
Automation & n8n 159 cPanel API tokens: automating without handing over your password Sooner or later somebody asks you for your cPanel password: the developer building an integration, the offsite backup se...
Automation & n8n 78 What n8n is, and what you can automate with it n8n is a program that connects applications to one another through workflows: when something happens in one application,...
Automation & n8n 65 Do you need a VPS for n8n? What shared hosting cannot do Yes: to run n8n on a server of your own you need a VPS (or a dedicated server) with root access. It cannot be done on a...
Automation & n8n 34 An API key or token has leaked: what to do, in the right order The short answer: if an API key, a token or a webhook secret has turned up somewhere it should not (a public repository,...