How Offline Payment Codes Enable Alipay & WeChat Payments Without Network

Overview of Mobile Payment Methods

Mobile payments with Alipay and WeChat rely on two main modes: user‑initiated scanning ("main‑scan") where the customer scans a merchant’s QR code, and merchant‑initiated scanning ("be‑scan") where the customer shows a payment code that the merchant scans.

In the "be‑scan" scenario the merchant’s backend calls Alipay’s barcode‑payment API to complete the transaction.

Payment‑Code Transaction Flow

The overall flow involves the merchant’s system requesting a payment‑code from the payment provider, the provider generating a code linked to the user, and the merchant presenting that code to the user for scanning. The merchant’s backend must be online to communicate with the provider; the client (phone) may be online or offline.

Online Code Scheme

When the client is online, it requests a payment code from the backend, which generates a code, stores the mapping in a database, and returns the code to the client. The code is valid only while the client displays it, and the backend can adjust the format or length without updating the client.

Limitation: the client must have a network connection to obtain the code, which is unsuitable for weak‑network environments or devices without connectivity.

Offline Code Scheme

Offline payment codes are generated entirely on the client using a shared secret and a time‑based one‑time‑password (OTP) algorithm, similar to Google Authenticator. The server validates the code by reproducing the same OTP using the stored secret.

OTP Generation Basics

To use Google Authenticator, a user enables two‑factor authentication on a website, scans a QR code containing an otpauth://totp/... URI, and the app stores a secret (Base32‑encoded).

otpauth://totp/Google%[email protected]?secret=XXXX&issuer=Google

The secret is decoded from Base32, then the OTP is computed as:

input = CURRENT_UNIX_TIME() / 30
hmac = SHA1(secret + SHA1(secret + input))
four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac)+4]
large_integer = INT(four_bytes)
otp = large_integer % 1,000,000

The resulting six‑digit number is displayed to the user.

Applying OTP to Offline Payment Codes

For payment, the client generates a code using the same secret‑based algorithm. The server, knowing the user’s secret, reproduces the OTP and verifies it, then proceeds with the charge.

Key points:

The secret is shared between client and server.

Time‑based intervals (30 seconds) provide a balance between security and usability.

Server‑side validation ensures the code belongs to the correct user.

Drawbacks of the Offline Scheme

Algorithm rigidity: Any change requires a client update and backward‑compatible server handling.

Security risk: If an attacker extracts the secret (e.g., via a rooted device), they can forge valid payment codes.

Collision possibility: Different users might generate the same OTP, potentially causing mis‑charges.

Conclusion

In practice, the merchant’s backend must stay online to call the payment provider, while the client can operate either online (receiving a server‑generated code) or offline (generating a code locally with a shared secret). Online codes are more secure and flexible; offline codes enable payments in weak‑network scenarios but introduce additional security considerations.

References

https://www.zhihu.com/question/49811134/answer/135886638

https://garbagecollected.org/2014/09/14/how-google-authenticator-works/