DEV Community: member_fb93637b

I run a Telegram Stars payment bot for $0/month forever — on GitHub Actions, not a server

member_fb93637b — Sat, 17 Oct 2026 23:58:02 +0000

Telegram Stars (currency XTR) let you sell digital goods inside Telegram with no bank, no card network, no Stripe/PayPal, and no KYC on the selling side. The catch most tutorials skip: Telegram requires answerPreCheckoutQuery within 10 seconds of every payment attempt — there's no auto-approve fallback. That means you need something always-on, listening. Normally that's a $5-20/month VPS or a serverless function with its own billing.

I didn't want a second hosting bill for a side project, so I run the responder entirely inside a public GitHub repo's Actions minutes, which are unlimited for public repos.

The trick

A single GitHub Actions job can run up to 6 hours. So:

Long-poll Telegram's getUpdates for ~5h50m inside one job.
Commit the updated offset + a dedup list of already-fulfilled payment IDs back to the repo as the last step.
A cron schedule re-triggers the next run every 6 hours — it queues right behind the previous job (same concurrency group), so the gap between one run ending and the next starting is seconds, not minutes.

Net result: near-continuous coverage, $0/month, no separate hosting account to manage or lose access to.

on:
  schedule:
    - cron: "0 */6 * * *"
concurrency:
  group: telegram-stars-bot
  cancel-in-progress: false
jobs:
  respond:
    timeout-minutes: 355   # just under the 6h hard cap

The bug this trick hides until your first real sale

The last step commits state.json (the getUpdates offset) and fulfilled.json (processed payment IDs) back to main. A plain git push there is a trap: if anything else pushes to main during that ~5h50m window — even an unrelated commit to a different file — the push fails with a plain ! [rejected] (fetch first). The job itself still shows green in the Actions tab (the failure is buried in one sub-step), so nothing alerts you.

What actually breaks: the whole run's progress — offset and the fulfilled-payment dedup list — gets silently discarded. The next run starts from the old offset, Telegram happily replays the same updates (it doesn't drop them without a confirmed offset), and because the dedup record also reverted, a real purchase could get double-processed — not a double charge to the buyer, but a duplicate delivery message, which looks broken to a paying customer on their first interaction with your bot.

Fix: retry the push with a rebase instead of giving up after one attempt.

for i in 1 2 3 4 5; do
  git push && exit 0
  git fetch origin main
  git rebase origin/main || { git rebase --abort; exit 1; }
  sleep 3
done

I found this by noticing a run failure buried in email notifications, not from a customer complaint — it hadn't sold anything yet when I caught it, but it was a live landmine for the first real sale.

Where it stands

Live since Oct 17: dedicated bot (@freelancerkitbot), pre_checkout_query answered automatically, successful_payment triggers an automatic delivery message, replayed updates can't double-deliver (charge IDs are deduped). Zero sales so far — I'm not going to pretend otherwise — but the plumbing is solid and tested (unit tests mock the Telegram API, no token needed to run them).

Code (MIT): https://github.com/kleogeos/telegram-stars-checkout

If you want to see it live: one of the checkout pages has a "Pay with Telegram Stars" button wired to this exact repo.

6 Clauses Your Freelance Contract Needs (Or You Risk Not Getting Paid)

member_fb93637b — Sat, 17 Oct 2026 22:44:08 +0000

I built a free contract checklist tool that scans a pasted contract for missing clauses. Writing the checks made it obvious which 6 clauses actually matter — the rest is boilerplate.

1. Scope and acceptance criteria

"Build a website" is a conversation topic, not a scope. Name the exact deliverable, format, and how the client verifies it is done. Without this, every revision request becomes an unwinnable argument about what you actually promised.

2. Acceptance deadline with an auto-accept clause

Give the client a fixed number of days (3-5 business days is typical) to approve the work or send written feedback. State that silence past the deadline counts as acceptance. Without this clause, a client who goes quiet can block you from ever formally closing the project -- and from invoicing with a clean paper trail.

3. Payment terms with a real late fee

Net 15 or Net 30 from invoice date, not "on completion." Add a concrete late fee (commonly 1.5%/month on the overdue balance) and the right to pause work once payment is overdue. A deadline with no penalty attached is a suggestion, not a term.

4. IP assignment, tied to a specific moment

"Client may use the work" is not an assignment. State explicitly whether full rights transfer -- and from what moment, usually full payment, not delivery -- or whether it is a license. Skip this and default copyright law applies, which can mean the client is not the sole legal owner even after paying in full.

5. Confidentiality / NDA

If the work touches client data, system access, or business information, a confidentiality clause (or separate NDA) protects both sides and makes clients more comfortable sharing what you actually need to do the job well.

6. A plan for when the client disappears

A kill fee for mid-project cancellation, combined with clauses 2 and 3 above, gives you a concrete written basis to invoice and collect -- instead of an unenforceable verbal understanding.

Full write-up: How to Write a Freelance Contract. The checklist tool above runs entirely in your browser -- nothing you paste is uploaded anywhere.

I also build small zero-dependency CLIs for freelance admin (invoicing, NDAs, time tracking) -- repo list here if that is useful to anyone.

I built a suite of zero-dependency CLIs for freelancer admin (invoicing, contracts, NDAs, time tracking)

member_fb93637b — Sat, 17 Oct 2026 21:35:56 +0000

I kept rebuilding the same client paperwork for every project — proposal, NDA before the discovery call, services agreement, invoice, time tracking, and eventually a late-payment reminder — so I turned them into a set of small, zero-dependency Python CLIs. Each one takes a JSON file and outputs a clean, print-ready HTML file. No accounts, no cloud, no telemetry.

The suite now covers the whole client lifecycle:

freelance-proposal-cli — scope/pricing/timeline quote
freelance-nda-cli — mutual NDA for the discovery call before scoping
freelance-contract-cli — plain-language services agreement
contract-checklist-cli — scans a contract for commonly-missing clauses
freelance-time-cli — time tracking
freelance-timesheet-to-invoice-cli — converts tracked hours straight into an invoice
freelance-invoice-cli — HTML invoice generator
freelance-late-fee-cli — computes late fees and which reminder email to send
freelance-rate-cli / freelance-expense-cli / freelance-tax-cli — hourly rate math, expenses, US self-employment tax
crypto-pay-cli / usdt-rub-cli / freelance-currency-cli — for clients who pay in stablecoins instead of wire transfer

Each one is MIT-licensed, has a test suite, and runs in CI. They're designed to chain together — timesheet hours flow into the invoice generator, the invoice generator's output matches what the late-fee calculator expects, and so on — so you're not retyping numbers between tools.

Hub repo with the full list: https://github.com/kleogeos/awesome-freelance-tools

If you'd rather not install anything, there are free browser versions (just forms, nothing uploaded) at https://kleogeos.github.io/freelancer-tools/?src=devto1

Standard disclaimer: the contract/NDA generators are deliberately simple templates (not legal advice), and that's stated right on the generated document.

Happy to answer questions about any of them, or hear what's still missing from the workflow.