Telegram Bot Payments in Poland: BLIK, Przelewy24, Stripe and Telegram Stars

Which payment methods can work

Native Telegram Payments and an external payment page are different integrations. Connecting Stripe through BotFather alone does not establish BLIK support in the native window.

For BLIK, consider Stripe Checkout or Payment Links, subject to account eligibility and settings. Przelewy24 in Stripe is a separate payment method, not a guarantee of every feature available through a direct P24 integration.

Digital goods and services sold inside Telegram require Telegram Stars. An external link is not a universal workaround for this requirement.

The estimate should therefore name the buyer journey: a native invoice, the provider's checkout or Stars. A promise to connect every payment method is not a sufficient specification.

An order with external checkout

Example for a physical goods shop: the buyer selects a product in the bot, receives a checkout link, pays and returns to the conversation. This is an example of a proposed flow, not a working integration demo.

Reaching a thank-you page does not prove payment. The server must verify the provider notification and match it to the correct order. A repeated notification must not trigger duplicate fulfilment.

Before development, agree where orders are stored, which statuses buyers see and how you learn about problems. A payment still awaiting confirmation should not be displayed as paid.

What to prepare for an estimate

Describe the product or service, seller country, currency and required payment methods. Mention an existing bot, website, CRM and provider account. If there is no bot yet, its development and payment integration can be estimated separately.

Send a public bot or website link and an example buyer journey. The first enquiry does not need BotFather tokens, API keys, passwords or bank details.

After review, agree access, responsibility for account configuration and test mode. Provider verification of the seller is a separate project dependency, not something a developer can guarantee on your behalf.

How projects differ

A physical goods shop may need inventory, shipping and CRM order delivery. An in-person appointment requires availability checks and cancellation rules. These should not be treated as identical integrations.

A digital subscription, private channel or mini app needs its own platform-policy and access-delivery assessment. An online consultation is not automatically a physical service just because the call takes place in another app.

Decide whether you need a new bot or an extension to an existing one. Preserving current logic, migrating data and connecting accounting software should be separate scope items.

Fees, refunds and scope boundaries

Development, provider fees, hosting and ongoing support are separate costs. An offer should distinguish them and check the selected service's current pricing.

Agree how unpaid orders, cancellations, repeated notifications and refunds are handled. Refunding money and reversing delivery or access may be different operations.

Sales terms, buyer documents, taxes and personal-data processing should be reviewed with the appropriate specialists. Configuring a bot does not replace legal or accounting review of the business.

Checks before launch

• The order has the correct amount and currency.
• Successful payment updates the correct order.
• Cancellation and failure are not shown as successful purchases.
• Repeated notifications do not create another order.
• Refunds and support requests follow a clear process.

Cost depends on the existing bot, number of flows and integrations. Scope, price and timeline can be agreed after reviewing the task. Development and payment-provider charges are separate.