Paying from balance: where refunds work

There are four payment methods at the checkout, and they differ not only in the fee but also in how much time passes between the payment and the delivery.

The unique transfer amount in the crypto options is not a whim but a way to identify the payment: it is exactly what the system uses to find your transfer among the others. So rounding the amount or sending «about the same» is not allowed.

• The amount from the checkout is not rounded — the payment is identified by it.
• A crypto payment waits for network confirmation, a payment from the balance waits for nothing.
• The fee is stated at the checkout next to the method: for CryptoBot it is 5 %.
• The balance is topped up by the same methods that pay for an order.
• An SBP QR is opened with the camera app rather than with the bank scanner inside the banking app.

The same choice applies to topping up the balance: it is topped up by the same methods an order is paid with. The only difference is the moment — you pay in advance and once rather than separately in every purchase.

The balance solves one task — it removes the waiting. With a direct cryptocurrency payment, the network confirmation time passes between sending the transfer and the delivery, and the position may leave during all that time: the stock in the catalogue is live and changes. With a payment from the balance the charge happens at once, and the assembly of the order starts right there.

The second use is regular purchasing. A script working through the API cannot wait for a transfer confirmation on every iteration; it works with a balance that is topped up in advance and spent as the orders go.

The stock deserves a separate word. Positions with instant delivery leave immediately, but the volume in the catalogue is live, and between the decision to buy and the confirmation of the transfer it may change. The balance removes exactly that gap.

There is a third effect, a less obvious one. The thirty-minute checking window is counted from the purchase, not from the start of the payment. Everything you do before the charge does not spend the window — and paying from the balance removes the minutes of network waiting from it.

This is where the main difference between the channels sits, and it is not obvious from the checkout. The word «refund» describes three different mechanics, and which one fires depends not on your request but on where exactly the failure happened.

• Payment via the API from the balance: on a failed delivery the funds are returned to the balance automatically.
• Payment on the site or in the bot: there is no auto-refund, but if the delivery does not happen the funds are simply not charged.
• Replacement under the guarantee: if the account does not let you in on the first login and there is nothing to replace it with, the money goes back to the shop balance.

There is one common rule: the refund goes to the balance, not to a card. The shop makes no automatic card refund at all, and that is worth accounting for when choosing the top-up amount.

A fourth scenario — «give the money back because I changed my mind» — is not on this list. The product is digital and delivered instantly, so a refund is tied to a delivery failure or to a position not matching its description, not to the buyer's decision.

The difference between the first and the second scenario is who deals with the failure. In the API the shop deals with it itself, without a human. On the site and in the bot the money does not leave on a failure, while disputed cases go through support manually — and that is fine for a one-off purchase but a poor fit for a flow of orders.

All the shop's contact channels are in Telegram: the channel and the support bot. The shop does not use e-mail, there is no phone and no office. It does not connect web analytics either, so nobody will be able to «look at what happened during your visit» — the case is settled by the order number.

Such a contact design looks sparse, but it has a flip side: settling a case does not depend on the device or the browser you bought from. The order number finds the purchase the same way in any channel.

Hence the practice of contacting: the order number and the position SKU. Those two values are enough to find the purchase, and without them nothing starts. Both are visible in the account panel, and the SKU is visible on the position card and in the catalogue search as well.

• No delivery visible — open the order in the account panel first: the data stays there and is downloaded again.
• The position does not match the card — the support bot, the order number, the SKU, within thirty minutes.
• The payment went through but the order was not assembled — on the site and in the bot the funds are not charged, and on payment via the API from the balance they come back on their own.
• The shop does not name response times: the catalogue, the payment and the delivery run automatically, support answers by workload.

What is better left out of a request is a description like «the account stopped working after two days». The shop states plainly that it does not guarantee account behaviour after hand-over, and there is nothing to settle in such a request. The subject of the conversation is the state at the moment of delivery.

About refunds it is worth remembering one thing: they always go to the shop balance. The money on the balance pays for the next order, but the shop does not promise to send it back the way it came — and that affects the sum it is sensible to top up at a time.

Assembly takes one to two minutes, five at most. The data appears on the order screen by itself, without refreshing the page, and stays in the account panel and in the Telegram bot. The shop sends no mail notifications — it does not use e-mail in principle, all contact runs through Telegram.

The order does not disappear: the delivery can be copied or downloaded as a file again, including per separate position. That is worth remembering in the first thirty minutes — if something got lost while copying, there is no need to go to support, it is enough to open the order in the account panel.

Repeat downloading is convenient for another reason too: the delivery can be collected per separate position of the order rather than all at once. For a large purchase of several SKUs that is noticeably simpler than picking apart one common list.

From this moment the hand-over begins, and it is part of the deal too. Compare the composition of the lines, run the delivery through the converter, log in selectively — and only then change passwords and linked data: any change before the end of the check removes the replacement guarantee.