E-commerce bot: catalog, cart, payment via Telegram Mini App

E-commerce bot: catalog, cart, payment via Telegram Mini App

We encountered a situation where a standard Telegram bot with inline buttons could no longer handle a catalog of 300 SKUs. The 64-byte limit on callback_data made it impossible to pass product parameters, and the Redis-based state machine got confused when a user opened the bot in two windows simultaneously. Our solution: Telegram Mini App. This is a WebView that launches inside the bot and removes all Bot API limitations. Our experience shows this approach reduces catalog development time by 30% and gives users a familiar mobile interface. For small stores, the gain can be even higher.

Why Mini App is better than inline buttons

A classic bot with InlineKeyboardMarkup and callback_data hits the 64-byte limit — with product variants (size, color, quantity), this field overflows. Developers are forced to store state in Redis by chat_id, leading to state machines that break when the bot is opened in multiple windows. Mini App provides a radical solution: state lives in a React/Vue component inside WebView, and the bot only launches the Mini App via the web_app button.

Architecture of Mini App for e-commerce

// Initialize Telegram WebApp
const tg = window.Telegram.WebApp;
tg.ready();
tg.expand(); // full screen

// Get user data (no separate auth)
const initData = tg.initData; // string for server verification
const user = tg.initDataUnsafe.user;

// Send order data to bot
function submitOrder(cart, total) {
    tg.sendData(JSON.stringify({
        action: 'order',
        items: cart,
        total: total
    }));
    // Telegram closes Mini App and sends data to bot via onWebAppData
}

On the server, we verify initData via HMAC-SHA256 with the bot token — this protects against request forgery. Without verification, anyone can send a POST with an arbitrary user_id.

import hmac, hashlib

def verify_init_data(init_data: str, bot_token: str) -> bool:
    parsed = dict(chunk.split('=', 1) for chunk in init_data.split('&'))
    hash_received = parsed.pop('hash', '')
    data_check = '\n'.join(f'{k}={v}' for k, v in sorted(parsed.items()))
    secret = hmac.new(b'WebAppData', bot_token.encode(), hashlib.sha256).digest()
    expected = hmac.new(secret, data_check.encode(), hashlib.sha256).hexdigest()
    return hmac.compare_digest(hash_received, expected)

How to implement payments in Telegram Mini App?

Telegram Payments 2.0 supports YooKassa, Stripe, PayMaster, and about 10 other providers. The bot calls sendInvoice with provider_token, the user pays with Telegram's native UI — simple and fast. However, there is a commission from the provider and no cryptocurrency support. If you need crypto payments or your own acquiring scheme, the payment is initiated inside Mini App, opens the provider's page (or a deep link to the wallet), and after success we return via tg.close() with notification via webhook. We guarantee compliance with Telegram security policies and PCI DSS standards.

How to set up cart and checkout?

Cart state is stored locally in a React or Vue component. We use tg.MainButton as a sticky "Checkout" button at the bottom. On click, we call submitOrder — data goes to the bot, which processes the order and sends a confirmation. A multi-step form with address selection, delivery method, and comment can be implemented.

Catalog and filtering

For a catalog with photos and filters, Mini App is far better than a bot. We use React with react-query for API requests, images via CDN with lazy loading. tg.MainButton is used as the "Checkout" button — it sticks to the bottom of the screen natively.

tg.MainButton.setText(`Checkout — ${total} ₽`);
tg.MainButton.show();
tg.MainButton.onClick(() => submitOrder(cart, total));

What's included in the work?

Typical integration mistakes

• Using var instead of let/const — global state breaks Mini App on reload.
• Missing initData verification — vulnerability to user data forgery.
• Improper handling of tg.close() — must explicitly close Mini App after payment.

Work stages

We determine whether a pure bot or Mini App is needed. Then set up the bot via BotFather, develop the catalog API, implement the Mini App (React/Vue), integrate payment, write webhook handlers. Test in a real Telegram client. Deploy to your server or cloud.

Timelines: 1-2 weeks for a simple bot with inline buttons and sendInvoice. 3-4 weeks for a full Mini App with catalog, cart, and custom payment flow. Cost is calculated individually after requirements analysis. Budget savings compared to native app development can reach 40%.

For over 5 years we have specialized in Telegram bots and completed more than 30 e-commerce projects. Our experience is backed by successful cases and certificates. Contact us for a project assessment — get a free consultation. We will evaluate your project and propose an optimal turnkey solution.

Payments in Mobile Apps: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat

In every monetization project, we balance App Store and Google Play policies, PCI DSS requirements, and purchase verification logic on the backend. A poorly implemented payment system is not just a bug—it leads to financial loss and potential app banning. Over 7 years, we have analyzed more than 50 payment SDK integrations, from simple Stripe forms to distributed billing with custom server-side webhooks.

In-App Purchase: Two Platforms, Two Different APIs

If your app sells digital content or subscriptions, Apple and Google require you to use their payment systems. This is non-negotiable: violating App Store rule 3.1.1 or Google Play Developer Policy results in app removal. Physical goods and offline services are a different story.

StoreKit 2 (iOS 15+)

StoreKit 2 is a complete overhaul of the original StoreKit with async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements—more readable and predictable compared to the transaction queue via SKPaymentTransactionObserver.

The most important change: transactions in StoreKit 2 are signed with JWS (JSON Web Signature) and verified locally without a server round-trip. Transaction.verificationResult returns .verified(Transaction) or .unverified(Transaction, VerificationError). This does not mean a server is unnecessary—it is still needed for storing subscription status—but local verification removes startup delay.

StoreKit.AppTransaction verifies the actual app download from the App Store. Required for paid downloads or non-renewing purchases.

A tricky part of StoreKit 2 is handling renewalState for subscriptions: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. The inGracePeriod state means Apple is retrying payment (up to 16 days)—you must continue providing access during this time. Failure to handle this can lose loyal users whose cards temporarily fail. Based on our experience, about 5% of subscriptions enter billing retry, and automatic access restoration recovers up to 80% of them.

Google Play Billing Library (v6+)

Google Billing is more complex than StoreKit in terms of scenario handling. BillingClient with PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync—must be called at every app launch; do not rely solely on PurchasesUpdatedListener as the single source of truth.

Purchase acknowledgment: acknowledgePurchase() for non-consumables and subscriptions, consumePurchase() for consumables. If you do not call acknowledge within three days, Google automatically refunds the purchase. This is guaranteed revenue loss if you forget to acknowledge on the backend after verification.

ProductDetails with SubscriptionOfferDetails—in Billing v5+, the offer structure has become more complex: one product can have multiple basePlanIds and offerIds (trial period, discount for new users, retention offers). BillingFlowParams.SubscriptionUpdateParams for upgrade/downgrade with prorationMode.

Why Is Server-Side Verification Mandatory?

Never trust only client-side code when unlocking paid content. Client-side verification can be bypassed by modifying the app.

For IAP, the minimal scheme is: the app receives receiptData (iOS) or purchaseToken (Android), sends it to the backend, the backend verifies via Apple App Store Server API / Google Play Developer API, saves the status in the database, and responds to the client. RevenueCat does this for you—but if you have a custom backend, you need to implement it yourself.

Webhooks are more important than they seem. Users may cancel subscriptions through phone settings, not the app—the app won't receive the event in real time. Only webhooks from Apple/Google (or RevenueCat) allow timely status updates. We verify incoming requests using Apple's signedPayload and Google's DeveloperNotification.

How Does RevenueCat Simplify Integration?

Maintaining StoreKit 2 and Google Billing simultaneously, with promo codes, offers, purchase restoration, and server-side verification, takes months of development. RevenueCat handles most of this layer.

RevenueCat is not just a payment SDK. It offers:

• A unified API for iOS and Android (and Stripe for web)
• Server-side verification and subscription status storage
• Webhooks for events (purchase, renewal, cancellation, billing issue)
• Analytics for cohorts, MRR, churn
• A/B testing of offers via Experiments

Purchases.configure(withAPIKey:) at startup, Purchases.shared.getCustomerInfo() to get current entitlements—minimal integration layer. Purchases.shared.purchase(package:) instead of directly calling StoreKit/Billing.

RevenueCat documentation states: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»

Limitations of RevenueCat: it is paid (free up to $2.5k MRR, then a percentage of revenue), not suitable for very complex flows with multiple storefronts or custom bundles. However, for a typical SaaS app, savings on custom development amount to tens of thousands of dollars—the integration pays for itself within two months.

Stripe in Mobile Apps

Stripe is used for physical goods, services, and B2B payments where IAP is not required by platform policy.

Stripe iOS SDK and Android SDK—PaymentSheet for ready-made payment UI, PaymentSheetFlowController for custom UI with saved cards. Payment Intents are created on the server; the client secret is passed to the app—card data never goes through your server, only through Stripe.

Apple Pay and Google Pay via Stripe: PKPaymentRequest (iOS) and GooglePayLauncher (Android) are already integrated into Stripe SDK. Apple Pay conversion rates are 1.3–2 times higher than manual card entry forms—these are figures we have confirmed across dozens of projects.

Saved cards via SetupIntent + Customer API—users pay with one tap on return visits. Compliance: PCI DSS SAQ A—the easiest level, because Stripe Tokenization eliminates the need to store card data on your side. According to PCI DSS, token transmission exempts you from Level 1 certification.

3DS2 (Strong Customer Authentication) is mandatory for payments in the EU under PSD2. Stripe handles it automatically via PaymentIntent.confirmPayment, but you need to correctly handle the .requiresAction status and return the user to the appropriate screen after authentication.

What Is Included in the Work (Deliverables)

Process and Timeline

We start by clarifying the business model: subscriptions, one-time purchases, consumables, freemium. The architecture depends on this. Testing IAP requires Sandbox accounts (Apple) and License Testers (Google)—this is a separate environment setup.

Apple's Sandbox behaves differently from production: subscriptions renew every 5 minutes instead of monthly, inGracePeriod works differently. It is essential to test scenarios: trial expiration, cancellation, billing retry, refund.

The cost is calculated individually based on the set of tools and complexity of server-side logic. On average, we fit within a budget for a typical integration, but the savings from preventing errors and churn offset this investment within a few months.

Get a consultation for your project—contact us. We will help you choose the optimal payment architecture that passes store reviews and does not break under peak loads.