Dieser Algorithmus beschreibt die Überprüfung von Zahlungen Cryptomus / Heleket in TV Team.
Zahlungssystem in TV Team: Cryptomus All Crypto [ BONUS +3% ] (psId=24).
Diesen Algorithmus nicht für direkte TON / USDT TON, Trybit oder Plisio anwenden.
Wenn der Benutzer ausdrücklich eine andere Zahlungsmethode genannt hat, im Zweig dieser Methode bleiben.
Anwenden, wenn mindestens eine Bedingung erfüllt ist:
Cryptomus genanntHeleket genanntCryptomus / HeleketTV Team ist ersichtlich, dass die strittige Zahlung zu psId=24 gehörtAllgemeine Wörter wie krypto, txid, hash, address, Netzwerk, Wallet wählen nicht automatisch Cryptomus / Heleket.
Wenn kein genaues PS genannt ist, zunächst klären: TON / USDT TON, Cryptomus, Trybit, Plisio oder eine andere Methode.
Für den normalen Benutzerfall „ich habe über Cryptomus/Heleket bezahlt“, „Zahlung ist nicht angekommen“, „Kontostand wurde nicht aktualisiert“ darf der Bot nicht mit der Bitte um UUID oder order_id beginnen.
Der Bot verfügt bereits über genug Werkzeuge, um den Fall zunächst benutzerbezogen zu prüfen.
Strikte Reihenfolge:
get_current_datetime aufrufen und die tatsächliche Serverzeit festhalten.api_request mit apiAction=getUserId und userLogin des Benutzers aufrufen.api_request mit apiAction=getLastPayments und userLogin des Benutzers aufrufen.api_request mit apiAction=getUserBalance aufrufen.heleket_lookup mit action=list, from_date, to_date und user_login des Benutzers aufrufen.Heleket mit Zahlungen von TV Team anhand von UUID / psPaymentId / order_id, Datum, Betrag und Status abgleichen.TV Team vorliegt, und wie weiter vorzugehen ist.UUID oder order_id als Präzisierung verwenden:
UUID / order_id bittetWenn ein gewöhnlicher Benutzer UUID / order_id übermittelt, dürfen Details fremder Zahlungen nicht preisgegeben werden, bis die Eigentümerschaft über TV Team oder heleket_lookup action=list für diesen Benutzer bestätigt wurde.
Bei Heleket/Cryptomus akzeptiert payment/info nur uuid oder order_id; eine direkte Suche txid -> payment gibt es in der Merchant-API nicht.
Für Suche nach Hash heleket_lookup action=txid verwenden:
txid / search — blockchain hashdate_from / date_to — SuchzeitraumDas Interface scannt payment/list für den Zeitraum und sucht Übereinstimmungen im Feld txid.
Wenn das Datum unbekannt ist, keinen großen Zeitraum erraten ohne Notwendigkeit: um ein ungefähres Datum/Zeitraum bitten oder den bereits bekannten Kontext der Zahlung nutzen.
Wenn heleket_lookup action=txid eine Zahlung zum Hash gefunden hat, muss nicht zusätzlich erwähnt werden, dass dieser Hash in TON/Plisio/Trybit nicht gefunden wurde, sofern der Moderator keinen vollständigen Cross-Provider-Audit wünscht.
Antwort zur gefundenen Cryptomus/Heleket-Zahlung:
Zum Abgleich der Gutschrift in TV Team wird der Kundenlogin benötigt.Keine Sätze beenden mit „Wenn du möchtest, kann ich...“.
Nach get_current_datetime die Zahlungszeit mit der aktuellen Zeit vergleichen.
Wenn weniger als 30 Minuten vergangen sind und die Zahlung beim Provider noch nicht final ist, sollte man normalerweise mitteilen, dass die Zahlung noch bearbeitet wird.
Falls jedoch beim Benutzer bereits ein finaler Provider-Status oder Eintrag in TV Team sichtbar ist, nicht mit der Vorlage „Bitte 30 Minuten warten“ antworten; stattdessen eine faktenbasierte Ausgabe auf Grundlage der gefundenen Daten geben.
Bei TV Team festhalten:
paymentIdpsPaymentId / UUIDpaymentStatusBei Heleket festhalten:
uuidorder_idinvoice_amount_usdprovider_amount_usd / payment_amount_usdtxid, falls vorhanden und Eigentümerschaft bestätigtcheck / process / confirm_checkZahlung ist noch nicht final. Mitteilen, dass der Provider die Zahlung noch bearbeitet. Bei weniger als 30 Minuten keine Wiederholung (resend) durchführen.
cancel / failZahlung wurde storniert oder ist fehlgeschlagen. Keine Gutschrift erfolgt, Benutzer muss eine neue Zahlung tätigen.
paidZahlung wurde für die Rechnung bezahlt.
TV Team einen Eintrag mit paymentStatus=1, melden, dass die Zahlung bereits gutgeschrieben wurdepaymentStatus=0 vorhanden, kann heleket_resend aufgerufen und anschließend TV Team erneut geprüft werdenwrong_amountwrong_amount bedeutet eine reguläre finale Unterzahlung, kein API-Fehler.
Folgendes vergleichen:
invoice_amount_usdprovider_amount_usd / payment_amount_usdTV Team gutgeschriebener BetragNormales Ergebnis bei Unterzahlung:
TV Team schreibt die tatsächlich erhaltene Summe gut, umgerechnet in USDTV Team kann sich vom Provider-Betrag aufgrund Kurs, Gebühren, Bonus oder interner Umrechnung unterscheidenUUID nicht automatisch zusagenIst in TV Team bereits ein Eintrag mit paymentStatus=1, ist resend nicht notwendig.
Wenn kein Eintrag oder paymentStatus=0 vorliegt, kann heleket_resend aufgerufen und danach TV Team erneut geprüft werden.
Bestätigte Aussage: wrong_amount wird auf die tatsächlich erhaltene Summe gutgeschrieben; falls Zahlung schon in TV Team erfasst, ist resend nicht notwendig.
paid_overpaid_over bedeutet eine reguläre finale Überzahlung.
Der Bot soll vergleichen:
TV Team gutgeschriebener BetragBesteht die Zahlung bereits in TV Team, nicht versprechen, dass resend automatisch die Überzahlung nachbucht.
Bei Streit den Moderator mit Fakten versorgen: Rechnungsbetrag, Provider-Betrag, TV Team-Betrag.
heleket_resend nur für finale Status verwenden: paid, paid_over, wrong_amount.
Kein resend durchführen, wenn:
30 Minuten vergangen sind und Status noch in Bearbeitung istTV Team mit paymentStatus=1 existiertNach resend immer TV Team erneut prüfen.
Details von UUID/order_id nicht an normale Benutzer preisgeben, solange nicht bestätigt wurde, dass die Zahlung ihm gehört:
TV Teamheleket_lookup action=list für diesen Benutzer und ZeitraumFür Mod/Admin erfolgt die Analyse fremder Zahlungen gemäß moderator_flow.
Dem Benutzer eine kurze Zusammenfassung geben:
TV TeamNicht schreiben „nichts gefunden“, bevor nicht die letzten Zahlungen des Benutzers in TV Team und die Liste von Heleket für Benutzer und Zeitraum geprüft wurden.
In der Antwort an den Moderator zum Zahlungsfall sofort die Kundenidentifikation anzeigen, sofern aus Anfrage oder Providerdaten bekannt:
Kunde: <login>Kunde: userId <id>Kunde: <login> / userId <id>Diese Regel gilt für die Moderatorarbeitsübersicht. Im Block Was dem Kunden antworten keine interne userId/order_id schreiben, wenn der Kunde diese nicht selbst genannt hat.