Custom Request Form for Manual Payment Acceptance
Operator replenishment variant with manual verification of payment receipt. Not all payments can and should be automated - for example, plastic card payments or individual regional payment systems. In such cases, the operator's manual replenishment option is appropriate.
This guide is for those who have a good knowledge of the constructor and are looking for ways to implement more complex functionality. If you do not know what Variables and Actions are, do not know how to work with Forms, and have no idea how the "Invisible Button" differs from the "Admin Button" - just do not read this guide and do not ask questions about it - it is intended for those who really understand what is going on, but not for those who will be led by the hand and told how to create buttons.
It should be noted that this option is suitable for projects in which there are a large number of replenishment options, and also if it is expected that they will change from time to time. The form uses rather wasteful ways of handling variables and Actions, so the form came out quite expensive, but very convenient to use. After all, you create a form once, and you will use it constantly. In any case, you do not have to take the full functionality for yourself - you can use individual elements and approaches in your project - there are quite a lot of original ideas in the form.
This Form is designed to make the process of manually replenishing the balance in the bot as easy as possible for both counterparties, as well as to eliminate possible errors, inaccuracies and mess in this process. A feature of the approach used is that the user does not receive details until the operator is ready to accept his payment. This approach requires a little more attention from the operator, however, it allows the user to be sure that there is a person on the other side who is dealing with his question and that his request and the money sent will be processed, and not just sent to the void.
❖ Purchase of functionality
All functionality is purchased IN YOUR BOT, for this go to your bot:☞ 🔐Admin| 🧩Extensions
IMPORTANT: The purchase of functionality for the bot is available only to the Creator (owner) of the bot. Admins CANNOT buy functionality!
You will need:
1. Variables - 6-7 pieces☞ 🔐Admin | 🧩Extensions | 📂Variables
2. Actions - 18 pieces☞ 🔐Admin | 🧩Extensions | 📂Actions
3. Invisible buttons and messages☞ 🔐Admin | 🧩Extensions | 📂Buttons
4. Conditions for buttons☞ 🔐Admin | 🧩Extensions | 📂Buttons
5. Macros and expressions for buttons☞ 🔐Admin | 🧩Extensions | 📂Buttons
6. User macros☞ 🔐Admin | 🧩Extensions | 📂Macros
❖ Form creation
How it works
The essence of the method is that a user who wants to replenish the balance in the bot addresses the operator directly, indicating all the necessary data, after which the operator sends him the details for the transfer with one click of the Trigger Command. The user performs the transfer and informs the operator about it by pressing the inline button. After that, the operator checks the receival of funds to the project's wallet and charges the user's the balance in the Bot. If at some stage the user considers it necessary to cancel the replenishment, the admin will receive a message about this, in addition, the user will not be able to order two payments at the same time, he will need to cancel the first before ordering the second.
The form itself will consist of two unequal parts.
● The first part is the buttons representing all the replenishment options, in which we set the data for each of the currencies.
● The second part is the functionality that will be common to all currencies - this is the very form of interaction between the user and the operator.
This approach allows you, as the owner of the bot, to easily change the list of currencies that you are ready to accept - add new currencies and delete unnecessary ones, while you do not need to touch the form itself.
Form structure
0. Top Up Button (/topup)
╠ 0.1 Currency Button
╚ 0.2 Form Button (invisible) (/payform)
╠ 1. Send Request to Operator
║ ╠ 1.1 Cancel Request
║ ╚ 1.2 Paid (invisible) (/paid)
║ ╠ 1.2. 1 Confirm Payment
║ ╚ 1.2.2 Cancel Request
╚ 2. Cancel
1. Create variables
Text:
• payname
• paytrigger
Numeric:
• payrate
• payround
• payrequest
Global
• cur - currency code of your bot (eg USD)
• paymin (OPTIONAL) - the sum of minimal deposit - you need it if yiou use ONE typeof currency in your project (If each of the deposit currencies should have its own minimum amount, then this variable should be individual and set each time in the «Currency Button»).
2. Currency button
Below is an example of creating ONE button for one deposit option. For each of the options you need, you will have to create such a button.
Add a new button and give the button a deposit option name (For example: USDT, BTC, TRX). In our example, we will create a button for the USDT-trc20 variant of the Tron network.
Pre-Actions:
1. Action-text - into the variable (payname) the name of the deposit option (USDT-trc20).
2. Action-numbers - into the variable (payrate) the exchange rate (1 if the rate is not needed).
3. Action-text - into a variable (paytrigger) command for the Trigger (/tusdt).
4. Action-numbers - into the variable (payround) the number of rounding signs (2).
5. Action-command - command to switch to the general form (/payform)
3. General form
Add a new button - name it «func_payform» (you can set your own name)
• Make the button invisible to the User and Admin.
• Add a command (/payform)
• Form - Input variable (paysum) - Asking to enter the desired amount of replenishment (data can be formatted before saving - rounded)
✏️ Enter the required amount of %cur% (minimum %paymin%):
• Button message - Show the entered amount and ask to confirm the send.
**%payname%** Payment Request
👤 Payer: **%firstname%**
📅 Date: __%date% - %time%__I pay: `{round(%paysum% / %payrate%, %payround%)}` %payname%
4. Buttons
Button 1. Send Request to Operator
• Condition {%paysum% >= %paymin%} - check the entered amount for compliance with the minimum (paymin)
Pre-Actions:
• Action-condition - check the flag that the request has not been sent before {%payrequest% == 0}
❌ You have already sent a request.
ℹ️ Cancel the previous request before sending a new one.
• Action-message - send a message with a request to admins in the group
**%payname%** Payment Request
👤 Payer: **{replace("%firstname%", "#", "")} {replace("%lastname%", "#", "")}**
🆔 #u%usercode% | `%userid%`
📅 Date: __%date% %time%__
#u%usercode%I pay: `{round(%paysum% / %payrate%, %payround%)}` %payname%
%paytrigger% |
In the message above, the expression {replace("%firstname%", "#", "")} {replace("%lastname%", "#", "")}escapes the hashtags in the username so that formatting does not slip off in messages.
• Action-numbers - (set value) set flag 1 to the variable (payrequest) that the request was sent
• Message Button - your request has been sent, please wait for details and amount
⏳ Your request has been sent to the operator...
1. Wait for payment details...
2. Transfer: `{round(%paysum% / %payrate%, %payround%)}` **%payname%** to the address that WILL be provided.
3. Confirm payment.
❗️ATTENTION: Your request will not be processed without PAYMENT CONFIRMATION!
Button 1.1 Cancel Request
• Condition {%payrequest% == 1} - check the flag that the request was sent earlier
❌ You have not sent requests to cancel them.
• Action-message - send a cancellation message to admins in the group
❌ Cancel Payment **%payname%**
👤 Payer: **%firstname% %lastname%**
🆔 #u%usercode% | `%userid%`
📅 Date: __%date% %time%__Requested: `%paysum%` %cur%
Should have paid:
`{round(%paysum% / %payrate%, %payround%)}` %payname%
• Action-numbers - (set value) set the flag 0 to the variable (payrequest) - remove the flag that the request was sent
• Button message - Your request has been cancelled.
✔️ Request cancelled.
Post-Actions
• Action-command - move the user to the top of the form (/topup)
Button 1.2 Paid (invisible)
• Command to access (/paid)
• Button message - Are you sure you paid?
❓ Are you sure you paid?
Button 1.2.1 Confirm Payment
• Condition {%payrequest% == 1} - check the flag that the request was sent earlier
❌ You have not sent requests to cancel them.
Pre-Actions
• Action-message - send a confirmation message to admins in the group
✅ %payname% confirmation
👤 Payer: {replace("%firstname%", "#", "")} {replace("%lastname%", "#", "")}
🆔 #u%usercode% | %userid%
📅 Date: %date% %time%
#u%usercode%I get: %paysum% %cur%
I paid: {round(%paysum% / %payrate%, %payround%)} %payname%
🪄 /varadd balance %userid% %paysum%
• Action-numbers - (set value) set the flag 0 to the variable (payrequest) - remove the flag that the request was sent
Post-Actions
• Action-command - move the user to the top of the form (/topup)
• Button Message - An acknowledgment has been sent.
✔️ Payment confirmation **%payname%** sent to the operator.
`%date% - %time%`⏳ Wait for accrual...
Button 1.2.2 Cancel Request
Pre-Actions
• Action-message - send a cancellation message to admins in the group
❌ Cancel **%payname%**
👤 Payer: **{replace("%firstname%", "#", "")} {replace("%lastname%", "#", "")}**
🆔 #u%usercode% | `%userid%`
📅 Date: `%date%` - `%time%`Should have received: `%paysum%` %cur%
Should have sent:
`{round(%paysum% / %payrate%, %payround%)}` %payname%
• Action-numbers - (set value) set the flag 0 to the variable (payrequest) - remove the flag that the request was sent
Post-Actions
• Action-command - move the user to the top of the form (/topup)
• Button message - Your request has been cancelled.
✔️ Your request has been cancelled.
Button 2. Cancel
• Action-command - move the user to the top of the form (/topup)
5. Triggers
Create a Button Trigger in the form of a command corresponding to the one that was written to a variable in an individual form. In our case, the /tusdt command.
The trigger message contains payment details and an inline button with the name "I paid" and the button command "Paid" (/paid).
For more information on triggers, see the Groups Guide.
6. Form unlock
In general, the form works quite stably, however, there are mentally handicapped users who can disrupt the work of this form as well. For example, clearing the history of the Bot right in the middle of the order, restarting it and etc. Introducing additional protection against such behavior is irrational, so some alternatively gifted people may have problems canceling an old order.
In order to unlock such a form for the user, you will need to send a command like:
/varset payrequest userid 0
For convenience, you can create a separate form for yourself with the user ID, followed by a message with this command and the ID entered. Copy the command, send it to the bot. You can make it so that the user can independently unlock this form for himself by creating a separate button and Action assigning the appropriate value to this variable. You can even make a paid unlock - it generally quickly disciplines such retards.