Payments and balance — Baza wiedzy GetMyBot

Na tej stronie

GetMyBot has two different payment circuits, and it is important not to confuse them.

Accepting payments with your bot: the bot issues invoices to its subscribers, and the money goes straight to you. Almost the whole article is about this.
The platform's request balance: what you pay for GetMyBot's own operation. Covered in the last section.

What a kassa is

A kassa is your own account with a payment provider, connected to the bot. You get credentials in the provider's dashboard, enter them into GetMyBot, and the bot issues invoices under your own keys.

The money goes straight to you, into your own merchant account. GetMyBot is not a payment agent: it does not accept or hold your money, does not participate in settlement, and does not take a cut of turnover. The platform does two things: it asks the provider to create an invoice, and it listens for the payment notification so it can fire the right reaction.

A few consequences follow from this:

the contract, fees, payouts, checks and limits are your relationship with the payment provider, not with GetMyBot;
secret keys are stored encrypted and are never shown back to you. Reopening the settings later shows an empty secret field, and an empty value means "keep the existing one";
a refund is your operation too: the platform only calls the provider's API with your own keys.

A bot can have several kassy, for example one in rubles and one in a foreign currency. One of them can be marked as the default kassa: it is used for invoices where no kassa was chosen explicitly.

Accepting payments is a plan feature. If the current plan does not include it, the Kassy screen shows a hint about that, and the Issue an invoice action will not create an invoice.

How to connect a kassa

Open the Kassy section. From the payments journal, the Kassy button in the top-right corner leads there.
Click Connect a kassa and choose a provider. The form adapts to it: each payment system has its own set of fields.
Fill in the kassa's title and credentials. The title is visible only to you: it is there to tell kassy apart in lists.
Turn on Default kassa if the bot will mostly issue invoices through it.
Save. The kassa card will show a Callback URL: the address the provider sends payment notifications to.
Click Copy and paste that address into the provider's dashboard as the notification address. Different systems call it differently: webhook, Result URL, notification URL.
Click Test connection. The check verifies that the credentials are filled in and that the provider accepts them. A "Connection works" response means you can start issuing invoices.

The Callback URL is the key step. Without it, the provider will charge the money, but GetMyBot will never find out: the invoice stays in the "Awaiting payment" status, and the payment reaction never fires.

The toggle on the kassa card temporarily disables it without removing the credentials. Deleting a kassa does not delete its payments: they stay in the journal.

Providers

Below is what you will need to grab from each system's dashboard. The exact set of fields is what you will see in the connect form: it is built from the provider's own schema.

The Tax system field shows up for several providers and is needed for the 54-FZ receipt. Options: OSN, USN income, USN income minus expenses, UTII, ESHN, patent (these are Russian tax regimes: 54-FZ fiscalization applies to Russian-registered sellers).

MIXPLAT

Project ID: MIXPLAT dashboard, "Projects" section.
API key: inside the project, "API settings". A secret field.
Payment method: card, mobile payment, e-wallet or bank. Card by default.
Test mode: a toggle to try the scenario without real money.

Currencies: RUB, EUR, BYN, KZT, UAH. Receipts, full and partial refunds are supported.

YooKassa

Shop ID: YooKassa dashboard, "Settings -> Shop".
Secret key: "Settings -> API". A secret field.

Currency: RUB. Receipts, full and partial refunds are supported.

Telegram Payments

This kassa works differently from the rest. The invoice reaches the subscriber not as a link but as a native Telegram invoice right inside the chat, and Telegram delivers the payment confirmation as a regular bot update rather than a request to a Callback URL. So there is no notification address to paste anywhere for this kassa, and the {payment:url} substitution is empty for it.

Payment provider token: in BotFather: /mybots -> your bot -> Payments -> connect a provider (YooKassa, Sberbank and others) and copy the issued token. No token is needed if the bot only accepts Telegram Stars.
Default currency: RUB, USD, EUR or XTR (Telegram Stars). Used when the invoice does not set a currency explicitly.

Refunds for this kassa are not issued from the GetMyBot panel: for regular payments they are done in the connected provider's own dashboard. Receipt line items are not shown in the builder for this kassa: the receipt is produced by whichever provider is connected to the bot for payments.

Robokassa

Shop identifier (MerchantLogin): Robokassa dashboard, shop settings.
Password1 and Password2. These are different passwords with different roles: the first signs the payment link, the second verifies the incoming notification. Mixing them up is a classic integration mistake.
A separate pair of test passwords, if Test mode is on.
Tax system and the Test mode toggle.

Currency: RUB. Receipts are supported; refunds from the GetMyBot panel are not: they are done in the Robokassa dashboard.

Prodamus

Payment form subdomain: for example my-shop, if your form lives at my-shop.payform.ru.
The payment form's secret key.

Currency: RUB. Receipts are supported; refunds from the panel are not.

CloudPayments

Public ID: CloudPayments dashboard, "Settings -> API".
API secret from the same place. A secret field.
Tax system.

Currencies: RUB, USD, EUR. Receipts, full and partial refunds are supported.

T-Kassa

TerminalKey: T-Kassa dashboard, "Terminals" section.
Terminal password. A secret field.
Tax system.

Currency: RUB. Receipts, full and partial refunds are supported.

Stripe

Secret key: Stripe Dashboard, "Developers -> API keys". A secret field.
Webhook signing secret: Stripe Dashboard, "Developers -> Webhooks", the endpoint in question. A secret field.

The invoice opens as a Stripe-hosted Checkout page. A notification is checked not only for its signature but also for its age: a callback older than five minutes is rejected, so an intercepted notification cannot be replayed later.

For currencies with no fractional part, such as JPY and KRW, the invoice amount has to be a whole number. An invoice for 199.90 will not be created in those currencies: the yen has no hundredths.

Currencies: USD, EUR, GBP, JPY, AUD, CAD, CHF, CNY, HKD, SGD, SEK, NOK, DKK, PLN, CZK, KRW, INR, BRL, MXN, ZAR, TRY, AED, ILS, NZD, THB, IDR, PHP, VND, BHD, KWD. Full and partial refunds are supported. There are no 54-FZ receipts for this kassa, so the receipt line items block is not shown for it.

Lava.top

Shop ID: Lava.top dashboard, the "Shop" section.
API key: same place, "API keys". A secret field.
Webhook secret: same place, "Webhook". It signs the payment notification. A secret field.

Currencies: USD, EUR, GBP. Receipts and refunds from the panel are not supported: a refund is issued in the Lava.top dashboard.

This kassa has no status polling either. If the notification never arrives, the invoice will not become paid on its own: check the payment in the Lava.top dashboard and contact support for a manual reconciliation.

CryptoCloud

Shop ID: CryptoCloud dashboard, the "Shops" section.
API key: the "API" section. A secret field.
Postback secret: "Shop -> Postback". It signs the notification token. A secret field.

The invoice is denominated in an ordinary currency, and the buyer picks which cryptocurrency to pay with on CryptoCloud's own page. The exchange rate is locked in by the provider when the invoice is created.

The notification is signed, but it does not count as payment by itself: the platform re-fetches the invoice from CryptoCloud and takes the amount from that answer rather than from the notification. An underpayment does not close the invoice: it stays in the "Awaiting payment" status and the payment reaction does not fire. An overpayment counts as paid.

Currencies: USD, EUR, RUB. Status polling is supported; receipts and refunds are not: a blockchain transfer is irreversible, so money can only be returned as a separate transfer to the buyer.

NOWPayments

API key: NOWPayments dashboard, "Settings -> API keys". A secret field.
IPN secret: "Settings -> IPN". It signs the notification. A secret field.

As with CryptoCloud, the invoice is denominated in an ordinary currency and the payer picks the cryptocurrency on the NOWPayments page. The notification (IPN) is signed in full, status and amount included, so no extra request to the provider is needed.

The platform passes the notification address to the provider inside the invoice itself, but the IPN mechanism has to be enabled in the NOWPayments account settings.

A partial payment does not close the invoice: while less than the invoiced amount has arrived, the invoice stays in the "Awaiting payment" status.

Currencies: USD, EUR, RUB. Status polling is supported; receipts and refunds are not.

VK Pay

Like Telegram Payments, this kassa lives only inside its own messenger. The invoice arrives not as a link but as a pay button right inside the VK conversation, and the confirmation comes as a regular community event rather than a request to a Callback URL. So there is no notification address to paste anywhere for this kassa, and the {payment:url} substitution is empty for it.

VK community ID (group_id): the numeric id of the community the transfer goes to, without the minus sign.

If a reaction using this kassa fires in Telegram or WhatsApp, no invoice is created: only VK can render a VK Pay button. The reason is visible in the "Invoice" step of the reaction card.

Currency: RUB. Receipts, status polling and refunds from the panel are not supported: disputed transfers are handled in the VK Pay dashboard.

The "payment -> access" scenario

The scenario always consists of two reactions: one issues the invoice, the other fires on payment. The split is not a formality: time passes between these two moments, and the subscriber may leave and come back.

Reaction 1: issue an invoice

The trigger is whatever starts the purchase: a command, text, a button press. Then add the Issue an invoice action and configure it:

Kassa: a specific one, or "Default kassa".
Amount: in the major currency unit, i.e. in rubles, not in kopecks. A fractional part can be written with a dot or a comma (199.90). Instead of a plain number, a substitution or a formula is allowed, for example {user:cart_total}.
Currency: from the chosen kassa's currency list, or "Kassa's default currency".
Description: what the subscriber sees on the payment page. Supports substitutions.
Invoice lifetime, sec.: how long until the invoice expires. Zero means "the provider's own default".
Save the link to a subscriber parameter: optional. Useful if the link needs to be reused later, in another reaction.
Receipt items: a name and an amount for each line, plus a VAT rate. The block is shown only for kassy whose provider supports receipts.

After the action, add a message with the payment link: insert the {payment:url} substitution into the text, otherwise the subscriber simply never gets the link. The builder warns about this when an invoice is issued but the message has no such substitution.

Besides {payment:url} there are {payment:id}, {payment:order} (the order number), {payment:amount}, {payment:currency} and {payment:description}.

Reaction 2: grant access

Create a separate reaction and choose the Payment trigger. It has:

Payment status: "Succeeded", "Failed" or "Refunded". "Succeeded" by default.
Kassa: react only to payments through a specific kassa, or to any of them.
Minimum amount: cut off small invoices. Compared against the invoice amount, entered in the major currency unit.

After that come regular actions: grant access, set a "Paid" label, write the order to a collection, send materials. The same {payment:...} substitutions are available in the text, including {payment:status} and {payment:refunded}.

The Payment trigger works both ways: a reaction on the "Refunded" status is a convenient way to automatically revoke access after a refund.

Invoice statuses

The status is visible in the payments journal and on the payment card.

Created: the invoice exists on our side, the provider has not reported on it yet. Usually a few seconds before the link appears.
Awaiting payment: the link has been issued, the subscriber has not paid yet.
Succeeded: the money has arrived, and the amount and currency match the issued invoice. This exact moment fires the payment reaction.
Failed: the payment did not go through: the bank declined it, the card failed a check, and so on. Not a final status: if the provider later confirms the payment, the invoice becomes "Succeeded".
Canceled: the payment was canceled, no further changes will follow.
Expired: the invoice's lifetime ran out. If payment still arrives later, the invoice becomes "Succeeded": money that actually arrives is always recorded.
Refunded: the full amount was refunded.
Partially refunded: part of the amount was refunded. The remainder can be refunded later, at which point the invoice becomes "Refunded".

Two rules work in your favor. A repeated notification with the same status changes nothing, so access is never granted twice. And the status never rolls back: a paid invoice cannot be "unpaid" by a late notification.

Payments journal

The Payments section is a list of all of the bot's invoices. There is a search by order number, a filter by status and by kassa.

Clicking a row opens the payment card: amount, status, kassa, payer, creation and payment time, description, and an event log. The event log shows every attempt to change the status and its kind: callback (a provider notification), a status poll, a manual reconciliation, a refund. This is the first place to check when something goes wrong.

Refunds

A refund from the panel is available for kassy that support it: MIXPLAT, YooKassa, CloudPayments, T-Kassa, Stripe. For Robokassa, Prodamus, Lava.top, VK Pay and Telegram Payments, refunds are issued in the provider's own dashboard. CryptoCloud and NOWPayments have no refund at all: a blockchain transfer is irreversible, so the money is returned as a separate transfer to the buyer.

How to issue one: Payments -> the payment in question -> the Issue a refund button on the card. The button only appears for a succeeded invoice, and only if the kassa supports refunds. Confirmation is asked as a separate question.

A refund does not have to be a full one. All five kassy listed above also support partial refunds, so an amount field appears next to the button: it holds the whole outstanding remainder of the invoice by default, but you can return less and return the rest later. You cannot return more than the remainder.

Once the provider confirms it, the invoice gets the "Refunded" status, or "Partially refunded" if only part of the amount was returned. The refund event is added to the payment's event log. If you have a reaction configured on the Payment trigger with the "Refunded" status, it will fire.

Fiscalization and receipts

The 54-FZ receipt is produced by your payment provider, not by GetMyBot. The platform only passes it the line items you set in the Issue an invoice action, and the tax system from the kassa's settings.

What follows from this:

the sum of the line items must match the invoice amount, otherwise the provider will reject the invoice;
each line item now requires an explicit VAT rate choice (none/0%/10%/20%/10-110/20-120); the quantity is treated as one unit unless set otherwise;
correctness of names, VAT rates and the payment-subject markers is your responsibility as the seller. Test a sample receipt in the provider's dashboard before your first real sale.

If something went wrong

Money was charged, but the reaction did not fire

Open the payment card and check the status and the event log. In order:

Status is not "Succeeded": the provider did not send a confirmation, or it was rejected. Check that the Callback URL from the kassa card is pasted into the provider's dashboard, and look at the payment's events.
Status is "Succeeded", but there is no reaction: check the Payment trigger's filters: kassa and minimum amount. A reaction filtered to a different kassa will not fire.
The invoice was issued outside a dialog: if the payment has no payer, there is no one to send the reaction to. The payment is recorded in the journal, but no messages go out.
The plan does not include accepting payments: in that case neither is the invoice issued, nor do payment events fire reactions.
The subscriber did not get the link: the message had no {payment:url} substitution. Check the text of the reaction that issues the invoice.

To understand exactly what happened inside the reaction, open the subscriber's dialog in People or Chats: under the message there is a card with the steps of the fired reaction. The "Invoice" step shows both a successful issue and the reason for a failure, for example "kassa not found" or "kassa does not accept USD".

The provider keeps sending notifications in a loop

This is normal behavior: payment systems repeat the notification until they get a confirmation. Repeats are safe: a notification with an already-applied status changes nothing, and access is never granted twice.

If the repeats never stop, the provider is not getting a confirmation. Common causes: the dashboard has the wrong notification address, or the signature does not match, i.e. the wrong keys were entered for the kassa. A notification with an invalid signature is rejected outright and never changes the invoice's status: this way a forged callback can never grant access.

The payment came in for a different amount

If the provider reports an amount different from the one issued, the invoice is not marked as paid, and a rejection appears in the event log. This is a safeguard, not a bug: otherwise a hundred-ruble payment would unlock access to a ten-thousand-ruble item.

What to do: check the amount in the provider's dashboard. The money is already yours, so from there it is your call: refund the payer or issue an invoice for the correct amount. If the payment is legitimate and needs to go through, contact support: reconciliation is a separate operation, and it shows up in the event log as "manual reconciliation".

The kassa is unavailable on the current plan

The Kassy screen shows a hint and offers to go to plans; the connect button stops working. Already-connected kassy are not deleted, but invoices are not issued and payment events do not fire reactions. After switching to a suitable plan, everything keeps working with the same credentials.

Platform balance and plans

This is the second circuit, unrelated to your buyers' money. The platform counts the bot's own work in requests: a reaction debits the account balance by the sum of its actions' weights, at least one request per call. See Stats and log for the full breakdown.

The Billing section shows the current balance and available plans. A plan has a price, a request volume and limits, for example the maximum number of bots. The Select button activates a plan.

The source of truth for the balance is an append-only ledger of credits and debits: a registration bonus, a plan credit, a top-up, usage. Records are only ever added to it, so the history can always be audited, and the current balance is the sum across the ledger.

A top-up creates a payment for the desired request volume. Once the provider confirms it, the balance is credited automatically, and a repeated notification will not double the credit.

What's next

Reactions: basics: how to put together an "invoice -> access" pair.
Actions: what else a reaction can do after payment.
Collections: where to store orders.
Stats and log: balance usage and forecast.
Analytics: audience and payment trends.