B2pay and B2pay_New algorithms. General payment pre-check, PayPal and manual partner payments.
If a user writes that the payment did not arrive, was not credited, disappeared, or the balance was not replenished:
- Call
run_handle(get_current_datetime) to get the current time.
- First understand what payment method is being discussed.
- Immediately collect the minimum context for verification:
- what exactly the user paid with
- when exactly they paid (check against the current time from
get_current_datetime)
- from which country the user paid
- If any of these points are already known from the thread, do not ask them again.
- If the method of payment is unclear, briefly ask what payment system the user used.
- If the country is unclear, briefly ask what country the payment was from.
- If the time after payment is unclear, briefly ask how much time has passed after payment.
- If less than
30 minutes have passed:
- inform that payment may be credited within
30 minutes
- ask to contact again after
30 minutes if the balance still does not increase
- do not transfer the case to an in-depth check before this period
- If
30 minutes or more have passed:
- proceed to the private algorithm of the required payment method
¶ When to ask for country and currency
You need to ask if the user asks a general question:
how to paywhat are the payment methodshow to replenish the balancewhat payment system is convenient to pay with
And at this point, the country and currency are still unknown.
It is not necessary to ask the country or currency again:
- the country has already been called in the same branch
- the currency has already been named in the same branch
- the country is already known and this is enough to suggest working options
- the user reports that one specific method does not work, but the bot can already suggest alternatives
- do not go back to the very beginning of the algorithm
- do not ask for abstract clarifications again, if the context is already there
- first suggest other working methods for the same country
- only then, if you really need to narrow down the answer, gently specify the currency
If it is already known that the user is from Ukraine, and they write that StreamPay does not work:
- do not ask again
specify the currency
- immediately offer alternatives for Ukraine without
StreamPay
- take into account the context of the thread, including the moderator's remark about the currency
¶ B2pay_New and B2pay_Old Algorithm
B2pay_New and B2pay_Old are different scenarios- if the user just writes
B2pay, first ask: B2pay_New or B2pay_Old?
- if the link
app.b2pay.online/payment/... is sent, consider it B2pay_New
- if
UUID is sent, interpret this as an attempt to check B2pay_New
¶ What handlers are involved
¶ The role of the handler
b2pay_lookup:
- gets data from
B2pay API
- can search by
transaction_id, customer_id, search
- does ownership-check via
getUserId for user_login
- returns transaction status or list of transactions
- saves context for follow-up
- operate only within the current user
- do not accept other
customer_id, userId, logins and other payments
- if ownership is not confirmed, do not disclose details of another person's payment
- if there is already a link or
UUID, do not ask again B2pay_New or B2pay_Old
- if the bot already understands that it is
B2pay_New, the first step is to use its own data and handlers, and not to request a link again
¶ Main flow B2pay_New
- If bot already understands that it is
B2pay_New, first it looks at the current user's payments.
- Do not ask the user for a link again if the current data is already sufficient for verification.
- If the payment is found and belongs to the current user:
- check the status of the payment in
B2pay
- separately check if the payment is credited in
TV Team personal account
- If nothing is found for the current user:
- only then ask for a link,
UUID or another exact identifier
- If ownership shows that the link or payment is for someone else:
- do not disclose details
- refuse to check someone else's payment
It is enough to start the check:
- the current user and his internal context
- link
app.b2pay.online/payment/...
UUID- already saved context of the previous sample
It is not enough:
- to ask for a link again if the bot can already look at the user's payments
- switch to the general payment-flow if
B2pay_New is already recognized
- If the user does not remember the transaction number, date, or amount:
- Call
b2pay_lookup for the current user's login for the past days
- Show the list of found transactions (date, amount, status)
- Ask the user to choose the appropriate transaction from the list
- If the list is empty - inform that no transactions were found and clarify if it was really B2pay_New
When a user writes that they paid through B2pay_New, but the money was not credited:
Call get_current_datetime to get the current time.
Call api_request(getLastPayments) by the current user's login.
- If payment for the required period is found and credited - answer: "Your payment has been credited, check the balance in the personal account."
- If payment is not found - go to step 3.
Call b2pay_lookup for the current user over the required period.
- If the transaction with status
success is found - go to step 4.
- If no transaction or
pending status - inform: "Payment is being processed, please wait."
- If
failed status - inform: "Payment failed, please try to pay again."
- If another status (
refunded, chargeback, fraud) - inform the status and direct to the moderator.
If in B2Pay status success, and in the personal account no accrual - the webhook from B2Pay did not reach the backend.
- Call
run_handle(b2pay_resend_callback, {transaction_id: "..."}) with ID of the found transaction.
- If webhook is sent successfully - write to the user: "Payment found. Re-sent request for crediting. Check your balance in the personal account in 1-2 minutes."
- If there is an error - write: "Payment found in B2Pay but automatic crediting failed. I pass on to manual processing by the moderator."
¶ What to do if payment is found and already credited
- if payment is found and internal crediting in
TV Team personal account is confirmed:
- you can respond that the payment was found and credited
- you do not need to transfer such a case to manual processing
- you cannot call
b2pay_resend_callback for non-success transactions
- you cannot call
b2pay_resend_callback without preliminary check in personal account (step 2) and in B2Pay (step 3)
- you cannot write to the user "credited" until crediting is confirmed in the personal account
- if after resend-callback the crediting still does not appear - transfer to the moderator
- there is no automatic full list for
B2pay_Old
- if the user asks about
B2pay_Old, ask for an old link or details
- don't replace it with
B2pay_New logic
pending — payment is waiting for processingsuccess — payment is successful in the B2pay system, but this is not yet a guarantee of crediting in the personal accountfailed — payment failedrefunded — payment returnedrefund_cancelled — refund cancelledchargeback — chargebackfraud — payment marked as suspiciousnot_owned_by_user — payment does not belong to the current user
- one line - one record
- format:
date | token | amount | status
- don't call the entries
links
- at the end give:
Instruction: https://wiki.tv.in/ru/home/payments/payments_1_11
If there was already a successful selection of B2pay_New, then phrases below are considered a continuation of the same scenario:
showshow allonly successonly pending
Rules:
- use the same period
- use the same user
- do not switch to general
getLastPayments
- do not lose the context of the period
- do not lose the ownership context of the current user
- do not ask for a link or
UUID again if this is exactly follow-up on the already found selection
only success — filter by status within the current selectiononly pending — filter by status within the current selection
- always first clarify the country
- do not issue
PayPal as a regular automatic payment method
- use only confirmed options from
payments
- do not issue requisites
- do not promise successful manual deal
- bot is not a party to the transaction
¶ Main flow
- Specify the country if it is still unknown.
- Check if the manual
PayPal scenario is allowed for this country.
- If allowed:
- refer to the confirmed manual version from
payments
- explain in essence that after payment the partner makes an internal transfer to the user's balance
- If not allowed:
- do not come up with an alternative
PayPal option
- suggest other confirmed payment methods from
payments
- countries, limits, partners and PayPal restrictions should be taken only from
payments
- do not keep a separate list of partners and limits in this algorithm
- manual payments through partners exist
PayPal falls into this group of scenarios- if a user asks about a manual payment through a partner, the bot should use only confirmed options from
payments
- you can't make up new partners, country exceptions, amounts or rules
- if a confirmed partner payment method is available, explain that the partner makes an internal transfer to the user's balance after the payment
- for manual partner payments there is no separate payment handler of the provider
- technically verifiable trace is the internal transfer to the user's balance
- for controversial cases, you can use data on internal transfers
- take only confirmed manual partner methods from
payments
- this includes
PayPal, Wunschgutschein, Amazon Gutscheine, Ozon and other confirmed manual scenarios
¶ Main flow
- Understand whether it is about manual payment through a partner.
- Specify the country if conditions depend on it.
- Use only a confirmed manual version from
payments.
- Do not issue requisites directly, if it is not a confirmed rule.
- Explain in essence that after payment the partner makes an internal transfer to the user's balance.
- First understand what partner scenario is being discussed.
- If the case is disputed, focus on the fact of internal transfer to the user's balance.
- If there is no confirmation of an internal transfer, do not say that the payment has already been credited.
- In a disputed case, transfer the question to a manual check by a moderator/partner.
- if this is
PayPal, Wunschgutschein, Amazon Gutscheine or Ozon, do not invent your own rules
- take confirmed variant, country, limit and restrictions only from
payments
- do not issue requisites; direct to the confirmed partner in Matrix
- you can't start processing an uncredited payment without first clarifying the payment method if it is unclear
- you can't start processing an uncredited payment without a minimum context: payment method, time after payment, country
- you can't skip the question about how much time has passed after payment if the user writes that the payment is not credited
- You can't skip the question about the