Telegram Payment Gateway

The opportunity

Telegram opened payments to bots and exposed a short list of official payment providers. Being on that list early meant every bot merchant on Telegram could pick us — a rare, time-boxed distribution advantage. There was no “problem” to fix; the goal was to move first and land among the first gateways in the world.

Why it was hard

A brand-new, thinly-documented and still-moving API. Real money from day one, so “move fast” could not mean “ship broken”. It had to slot cleanly into an existing provider-orchestration model, cover Telegram's invoice → checkout → callback flow, and stay correct through refunds, retries and edge cases — all under time pressure while the spec was still changing.

The approach

A production-grade provider integration implementing Telegram's payment protocol end-to-end: invoice creation, the checkout and confirmation flow, webhook / callback handling, and mapping it onto the platform's rails and reconciliation. Built to absorb changes in a spec that was still evolving.

The call that mattered

The tension was speed vs. correctness on an unstable spec. We chose to ship early but build defensively — treating the API as a moving target, isolating every Telegram-specific quirk behind the provider adapter so spec changes stayed contained, and keeping money movement idempotent so nothing could double-charge. First-mover advantage without the corners you can't cut with real payments.

Architecture

The integration lived as one provider adapter inside the orchestration platform — Telegram's flow normalized to the same contract as every other provider, callbacks verified and reconciled, failures retried safely. The diagram shows the bot → Telegram → platform → settlement path.

Outcome

Shipped to production as one of the first ten Telegram Payment Gateway integrations in the world — establishing the platform as an early Telegram payments provider and putting it in front of every bot merchant choosing a gateway. (Business figures under NDA.)

What I'd do differently

Building against a spec that's still moving is a bet: you trade some rework for being first. I'd invest even earlier in a thin abstraction to isolate the provider's churn — the parts we hard-coded under time pressure were exactly the parts that later changed.

Architecture diagram

Stack

• PHP
• Symfony
• Redis
• Telegram Bot Payments
• Webhooks
• PostgreSQL