Building a Crypto Checkout on a Serverless Stack

You do not need a payment processor or a dedicated server to accept stablecoin payments. A few serverless functions, a small database and public blockchain data are enough for a reliable checkout. This architecture suits side projects, digital products and services that want low costs and direct payment to their own wallet.

The components

A minimal system has five parts:

Component	Role
Static frontend	Product pages, checkout form and order status page
API function	Creates orders and returns payment details
Database	Stores orders, amounts and payment records
Detection logic	Reads chain data and matches payments
Scheduled job	Checks pending orders in the background

Everything can run on a single serverless platform with a built-in SQL database and cron triggers.

Creating an order

When a customer checks out, the API:

1. Validates the input, such as product, network and token
2. Calculates the price in dollars
3. Picks a unique amount by adding random cents not used by other open orders on the same network and token
4. Fetches the current block number on the chosen network
5. Stores the order with its amount, token contract, start block and expiry
6. Returns the amount, receiving address and order ID

Recording the start block matters. The detector only needs to scan blocks after the order existed, which keeps queries small and prevents matching older payments.

Detecting payments

The detection logic runs whenever the order status page polls the API and whenever the scheduled job runs:

• Fetch the latest block number
• Subtract the confirmation count for that network
• Query Transfer logs for the token contract, filtered by your receiving address, from the last scanned block to the safe block
• Look for a log whose amount exactly matches the order
• If found, mark the order paid and store the transaction hash and log index
• Otherwise, save the last scanned block

Store a unique payment reference combining network, transaction hash and log index. A unique database constraint on that value makes it impossible to use one payment for two orders.

Polling and scheduling

Customers usually keep the order page open while paying. Polling every ten seconds gives quick feedback. To avoid hammering the RPC provider when several tabs poll, record when each order was last checked and skip checks that happened a few seconds ago.

A scheduled job every minute or two catches payments from customers who closed the page. Limit how many orders the job checks per run to stay within function limits.

Fallback by transaction hash

Offer a field where customers can paste a transaction hash. The API fetches the receipt, verifies success, checks the token contract and recipient, and compares the amount. Exact matches complete the order. Mismatches go to manual review.

Handling edge cases

Plan for:

• Late payments. Keep scanning for a grace period after the reservation expires.
• Conflicts. If a scarce item was sold to someone else, flag the order for refund or reassignment.
• Wrong amounts. Route to review with the transaction details.
• RPC failures. Retry with a second provider and scan in chunks within range limits.

An admin view listing orders by status, with actions to mark paid, cancel or refund, keeps these cases manageable.

Security checklist

• Validate every input server-side, including URLs and uploaded images
• Rate limit order creation per IP hash
• Never ask customers for approvals or signatures, since plain transfers are enough
• Keep the admin token as a secret, never in frontend code
• Escape any user-supplied text you display
• Use a receiving wallet with strong key security

Costs

On most serverless platforms, a small shop can run this architecture within free tiers. Public RPC endpoints handle modest query volumes, and database usage stays low because each order is a single row.

Proud Globe runs on this pattern: static pages, one worker, one small database and scheduled checks. You can try the full flow by picking a tile and watching the order page detect the payment.