How Do Offline Payment Codes Work? Inside the Tech Behind WeChat & Alipay

Mobile payments via WeChat and Alipay have become ubiquitous, yet many users are unaware of how a payment can succeed when the phone has no network connection. This article explores the offline payment‑code mechanism that enables such transactions.

Payment Method Overview

There are two typical QR‑based payment flows:

Merchant‑scans (主扫) : the user scans a QR code displayed by the merchant. This requires the app to be online to request a payment code from the server.

User‑scans (被扫) : the user shows a payment code generated by the app, and the merchant scans it. This flow can work without the phone being connected to the internet.

Both flows ultimately invoke the Alipay barcode‑payment API on the merchant side.

Online Code Scheme

When the client is online, the app requests a payment code from the backend. The server creates a code, stores the association with the user in a database, and returns the code to the client. The code remains valid for a limited period; if it expires, a new request is needed. This approach is secure because the server controls code generation and can enforce idempotency.

"The drawback is obvious: the client must be online to obtain a code. If there is no network, the scheme fails."

Offline Code Scheme

In scenarios where the device cannot connect to the internet (e.g., wearables without network modules), an offline solution is needed. The offline scheme is based on time‑based one‑time passwords (OTP) similar to Google Authenticator.

Dynamic OTP Principle

To use an OTP, the user first enables two‑factor authentication on the service. A shared secret (Base32‑encoded) is generated and stored both on the client and the server. The client computes a code using the secret and the current time, typically divided into 30‑second intervals.

<code>otpauth://totp/Google%[email protected]?secret=xxxx&amp;issuer=Google</code>

The secret is decoded from Base32 before use:

<code>original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))</code>

The OTP generation uses an HMAC‑SHA1 function:

<code>hmac = SHA1(secret + SHA1(secret + input))
input = CURRENT_UNIX_TIME() / 30</code>

The resulting 40‑byte HMAC is truncated to obtain a 6‑digit numeric code:

<code>four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac)+4]
large_integer = INT(four_bytes)
small_integer = large_integer % 1,000,000</code>

Both client and server perform the same calculation; the server verifies the submitted code against its own result.

Offline Payment‑Code Implementation

For payments, the offline code embeds user identification and a timestamp, allowing the server to validate the code without requiring the client to be online. The server must still be connected to the payment gateway to complete the transaction.

Advantages and Disadvantages

Flexibility : Online codes can be updated instantly on the server; offline codes require periodic secret rotation.

Security : Offline codes rely on a shared secret stored on the device. If the device is rooted or jail‑broken, an attacker could extract the secret and generate fraudulent codes.

Collision Risk : Although unlikely, two users could generate the same 6‑digit code, potentially causing an incorrect charge.

Conclusion

When a phone has no network, the merchant’s backend must still be online to process the payment. The client can either request a fresh code (online scheme) or generate an offline code using a shared secret and time‑based OTP algorithm. The online scheme offers better security and flexibility, while the offline scheme provides a fallback for weak‑network environments at the cost of increased complexity and slightly lower security.

Understanding these mechanisms helps users appreciate why their payment still succeeds even when their device appears offline.