Accepting Crypto Payments for Real Services with Zero Dependencies: Inside Crypto Service Bots

Most "accept crypto" tutorials end the same way: sign up for a payment processor, get an API key, pay a percentage on every transaction, and hope the provider doesn't freeze your account. Crypto Service Bots takes a different route. It is an open-source companion to the Crypto Service Store, and it lets a developer sell real services, get paid in USDT, and verify payment by reading the blockchain directly. No processor. No exchange account. No private keys on the server.

This article walks through what the project does, how the payment flow works, and what trade-offs you accept when you run it.

What it actually sells

The store is not a trading bot and makes no investment promises. It takes orders for ordinary knowledge work and routes them to a human-assisted AI swarm for delivery. The live store at https://renvt89.github.io/crypto-store/ currently lists four services:

Service	Price (USD)
Professional resume rebuild (PDF + DOCX)	$35
One-page product landing page	$60
AI code review (repo up to 5k lines)	$25
Agent prompt library pack	$12 (instant digital delivery)

Delivery is manual. The swarm does the work and sends it by email or Telegram within 24 to 48 hours. The prompt pack can be delivered instantly by script, but the project still counts it as manual oversight. Payments are final.

That framing matters. The project is honest about being a storefront with a crypto checkout, not a DeFi product. The only chain interaction is reading public data to confirm that money arrived in the owner's own wallet.

The stack

The backend is a Node.js server with zero npm dependencies. It uses only the built-in http, fs, and crypto modules. The frontend is a single HTML file with vanilla JavaScript, no CDN links, and it works offline-safe.

There are two ways the store runs:

• Static mirror on GitHub Pages. The HTML file is served as-is. This is the public storefront linked above.
• Node store variant. The server at apps/crypto-pay/server.mjs runs locally or on Render. This is the variant that creates orders, polls the chain, and hands work off to the swarm.

Zero dependencies is not a vanity metric here. The entire codebase is small enough to read in one sitting, which is exactly what you want for something that touches payment verification. There is no node_modules folder to audit and nothing to break on a routine npm update.

The payment flow, step by step

Here is what happens when a customer buys something.

1. Pick a service and leave contact details. The customer selects a service and provides an email address or Telegram handle. That contact is the delivery channel later.

2. Quote the USDT amount. USDT is a stablecoin, but it does not always trade at exactly one dollar. The store fetches the live rate from CoinGecko:

https://api.coingecko.com/api/v3/simple/price?ids=tether&vs_currencies=usd

It divides the USD price by that rate to get the exact USDT amount to send.

3. Customer pays. The customer sends exactly the quoted amount of USDT on BNB Smart Chain (BEP-20) to the owner's wallet:

0x59688BB311653840efb1A2e4fd5960570F7Fe137

They have 60 minutes. The address is public by design. Anyone can look up its history on BscScan.

4. The store watches the chain. When the order is created, the server records a baseline balance of the wallet. It then polls a public RPC endpoint:

https://bsc-rpc.publicnode.com

Each poll is a read-only eth_call against the USDT contract, asking for the wallet's current balance. The received amount is simply current balance minus baseline.

5. Mark paid and hand off. When the received amount is greater than or equal to the quoted amount, allowing a 0.1% tolerance for rate drift, the order flips to paid. The server appends a line to state/handoff.md:

[crypto-pay] ORDER <id> PAID — deliver '<title>' to '<contact>'

The swarm reads that file and picks up the real work.

6. No keys, ever. The server never signs a transaction. It never holds a private key or seed phrase. Verification is read-only from start to finish. If the server is compromised, an attacker learns which orders exist and sees a public wallet address. They cannot move funds.

Why the baseline approach works, and where it does not

Comparing a balance against a baseline is a deliberately simple verification method. It avoids parsing transaction logs, decoding transfer events, or indexing the chain. One eth_call tells you everything.

The simplicity has limits worth knowing before you deploy:

• Concurrent orders can collide. If two customers pay during overlapping windows, a single balance check cannot tell whose money arrived. For a low-volume services store this is rarely a problem. For higher volume, you would want per-order deposit addresses or transfer-event parsing.
• Public RPC endpoints have rate limits. The polling interval needs to respect them. A paid RPC provider is a drop-in replacement if you outgrow the free one.
• USDT only, BSC only. The store does not try to be multi-chain. That keeps the code small and the fee story clear. BSC gas for a USDT transfer is typically a few cents.
• Price feed dependency. CoinGecko going down means no new quotes. The tolerance band absorbs normal drift, but the quote step itself has a single external dependency.

None of these are hidden. They fall out naturally from reading the code, which is the point of keeping it dependency-free.

Why a developer might want this

If you sell services to a global audience, the traditional payment stack has real friction. Processors reject certain countries, charge roughly 3% plus fixed fees, and can hold funds for weeks. Exchange accounts add KYC and another party that can lock you out.

Crypto Service Bots removes those intermediaries:

• Funds land in your own wallet. No settlement delay, no holding period, no account to be frozen.
• Fees are tiny. USDT on BSC costs cents per transfer, and the store charges nothing on top.
• Verification is transparent. Your customer can independently confirm payment on a block explorer. So can you.
• Self-hosted. Run it on a laptop, a VPS, or Render. The static frontend can sit on any file host.
• Auditable in an afternoon. Zero dependencies and a single HTML file mean the attack surface is whatever you can read in the repo.

The obvious counterpoint is that your customers need a wallet with USDT on BSC. For a developer-facing or crypto-native audience, that is a reasonable ask. For a general consumer audience, it is a filter.

Running your own

To adapt the project, you change three things: the wallet address, the service catalog, and the delivery mechanism behind the handoff file. The handoff is intentionally just a text append. You could replace the swarm with a Telegram bot notification, a webhook to your task tracker, or a human reading the file once a day.

The static mirror is useful as a demo or a landing page, but the Node variant is where orders actually get created and verified. Start there if you want the full flow.

Crypto Service Bots is not trying to replace Stripe for everyone. It is a small, readable answer to a specific question: how does one person take crypto payments for real work without trusting a middleman or putting keys on a server? The answer is about as short as it can be while still working.