Backend-Free Crypto Payments: Verifying USDT Receipts in the Browser

Backend-Free Architecture: Static Sites Can Accept Crypto Too

Most e-commerce checkout systems rely on databases, server-side logic, and blockchain event listeners. But can a purely static site complete USDT payment verification? The open-source project crypto-store proves the answer is yes. It abandons the traditional backend and adopts a "balance-delta" approach, letting the visitor's browser directly verify BEP-20 USDT payments through public RPC nodes. This idea offers individual developers and small service providers an extremely low-cost payment collection solution, and also reveals another possibility for decentralized payment verification.

Core Mechanism: How Client-Side Balance Polling Works

The entire verification flow revolves around three eth_call invocations, with no server involvement. When a user places an order, the app first reads the store wallet's current USDT balance as a baseline; then the browser starts a polling loop, calling the balanceOf selector (0x70a08231) every 20 seconds to get the latest balance; when the difference between the new balance and the baseline is greater than or equal to the quoted amount (with a 0.1% tolerance to handle precision issues), the payment status is marked as "paid". To prevent infinite waiting, the entire check automatically expires after 60 minutes. This logic runs entirely in the browser and can be supported by static hosting alone, eliminating the operational burden of databases and event indexers.

eth_call is a read-only method in the Ethereum JSON-RPC interface that allows executing smart contract functions and returning results without consuming Gas or generating on-chain transactions. Unlike eth_sendRawTransaction, eth_call does not change blockchain state, so it can be processed for free by any public RPC node. In this scheme, the browser calls the balanceOf function of the USDT contract via eth_call, precisely leveraging its read-only nature—no user wallet signature is required, nor any fee paid, to query the store wallet's balance in real time. Public RPC nodes (such as the free endpoint provided by BscScan or the public gateways of Ankr and QuickNode) handle the actual query work, and the static site only needs to send an HTTP request. This also means the reliability of verification depends on the availability and data consistency of the chosen RPC node; node failures or delays may cause brief polling failures.

balanceOf is a read-only function defined in the ERC-20/BEP-20 standard, used to query the token balance of a specified address. Its function selector is 0x70a08231, obtained by taking the first 4 bytes of the Keccak-256 hash of the function signature balanceOf(address). When calling, the browser encodes the store wallet address as a parameter into the calldata, sends it to the USDT contract address, and the contract returns a 32-byte uint256 value, which is then converted to a human-readable amount according to token precision (USDT typically has 6 decimals). It's important to understand this: the balance-delta method does not rely on any event logs or transaction receipts, but directly reads contract state, making the implementation extremely simple—but it also cannot distinguish "who" deposited the funds.

An Honest Declaration: The Inherent Limitations of the Balance-Delta Method

This method is highly efficient, but not perfect. Because it only focuses on the increment of the wallet's total balance rather than a specific transaction hash, there are two known issues. The first is the concurrent buyer risk: if two people pay simultaneously, the app may misattribute a single large jump, causing order confusion. The second is the necessity of manual review: the "paid" status in the browser is only a convenience indicator and does not constitute a final legal contract. The shop owner still needs to manually verify each transaction on BscScan before starting service. This "human-in-the-loop" design sacrifices some automation in exchange for fund security.

BscScan is the block explorer for BNB Smart Chain, providing a public query interface for addresses, transactions, token transfers, and contract calls. In the balance-delta method, BscScan plays the role of "final arbiter": the shop owner can filter BEP-20 USDT transfer records by store wallet address and verify the amount, time, and payer of each transaction, thereby confirming whether a given order has actually been received. Compared with browser polling, BscScan displays on-chain facts confirmed by blocks and can distinguish concurrent transfers. The cost of manual review is that the operator needs basic on-chain query skills, but for low-frequency service transactions, this cost is far lower than maintaining a backend listening service.

Delivery and Refunds: Operational Details of a Service-Based Store

crypto-store sells services (such as AI code review or landing page building), so the process is not instantaneous. After payment confirmation, the service will be delivered via email or Telegram within 24-48 hours. All sales are final, with no refunds. The article specifically warns: only BEP-20 USDT on BNB Smart Chain is supported; if USDT from Ethereum or Polygon networks is mistakenly transferred in, the funds will be permanently lost. This warning highlights the risks of user operations in a multi-chain environment and also shows that static payment solutions require clear network identification and user education.

Applicable Scenarios and Insights

This backend-free approach is suitable for low-frequency, low-concurrency service transactions with clear unit prices, such as freelancers taking orders, digital goods sales, or monetizing small tool sites. It greatly lowers the technical barrier, but at the cost of sacrificing accuracy under high concurrency. For merchants seeking full automation, it is still advisable to introduce a lightweight backend or a third-party payment processor. The value of crypto-store lies in demonstrating a minimalist verification approach: given the publicly verifiable nature of blockchain, the browser itself can become a trusted verification terminal, while the ultimate anchor of "trust" still lies in manual review and the transparency of on-chain data.

One-line Summary

The open-source project crypto-store verifies USDT payments on a purely static site using the browser balance-delta method, with no backend required.

Paragraph Summary

crypto-store demonstrates a feasible path for backend-free crypto payment verification: a static site uses the browser to call public RPC nodes, reading the store wallet's BEP-20 USDT balance via three eth_call invocations and using the "balance delta" to determine whether payment has arrived. The process includes baseline reading, polling every 20 seconds, 0.1% tolerance comparison, and a 60-minute expiry. This method eliminates databases and event indexers at extremely low cost, but carries the risk of misattributing concurrent buyers, so the "paid" status shown in the browser is only a convenience indicator, and the shop owner still needs to manually verify on BscScan. The scheme suits low-frequency, low-concurrency service transactions, with a 24-48 hour delivery period and no refunds; only USDT on BNB Smart Chain is supported, and funds sent on other networks will be permanently lost.