EF-Transaktionen nicht korrekt

[seppl2000]

Hallo,

habe seit heute mehrere User, die auf meiner Seite eingezahlt haben (Lose von ihrem Klamm-Account gingen auch auf meinem EF), aber die Lose wurden nicht erfolgreich gebucht laut EF-Schnittstelle.

Hast du bei den EF-Scripts vllt. auch einen kleinen Bug reingebracht im Zuge der Sprachenerweiterung?

 

[dan2406]

.... ja ich schliesse mich mal an, bei mir ist auch ein fehler beim buchen
aufgetretten ...

30.06.14 - 09:20:48 - 25.000.000 -EF 17305 - Einzahlung Losehunter.eu

MfG
...

 

[Mone]

Hi, gab es einen timeout oder wirklich eine Fehlermeldung? Beispiele wären nicht schlecht. Und die Info, um welchen EF es überhaupt geht.

Ich sehe bei deinen beiden EFs für heute, also den 30.06.14, nur erfolgreiche API-Zugriffe, bis auf einige mit dem Code 1008 (zu wenig Lose auf den klamm-Account). Ich vermute also, dass es in Wirklichkeit timeouts waren, die dein Script aus Fehler ansieht. Dafür gibt es die API-Funktion EF Confirm.

https://www.klamm.de/partner/ef_api.php?api=ef_confirm

 

[klamm]

Hast Du eine TransaktionsID für mich?

 

[Mone]

.... ja ich schliesse mich mal an, bei mir ist auch ein fehler beim buchen
aufgetretten ...

30.06.14 - 09:20:48 - 25.000.000 -EF 17305 - Einzahlung Losehunter.eu

MfG
...

17305 l_get 327048 30.06 09:20:48 1001

Das bedeutet: die Lose sind erfolgreich auf dem EF angekommen. Es kann aber sein, dass es einen timeout gab. Das muss dann Losehunter abfangen bzw mit EF Confirm prüfen.

 

[dan2406]

also es wurde vom klammkonto abgebucht, aber es erscheint nicht auf meinem user konto
bei besagter seite....

MfG

 

[Mone]

also es wurde vom klammkonto abgebucht, aber es erscheint nicht auf meinem user konto
bei besagter seite....

Dem widerspreche ich ja nicht . Die Lose sind auch auf dem EF angekommen. Der Seitenbetreiber muss sie dir aber auch gutschreiben. Ich vermute, dass es beim Buchen ein timeout gab und das Script der Seite an der Stelle nicht robust genug ist, um das abzufangen.

 

[dan2406]

okay alles klar, bedanke mich für die schnelle kommunikation...

P.S. ja kann jut sein mit dem timeout, das hatte auch etwas länger gedauert...

MfG

 

[BlueBaron]

Mir ist Heute Morgen das Gleiche passiert.
Ich wollte auf einer Seite einzahlen, es läd ungewöhnlich lange, dann eine weisse Seite mit "Service unavilibel" oder so ähnlich. Hab die Seite dann neu geladen und die Lose waren nicht da. Aber bei Klamm waren sie abgebucht.

Das 1. Mal bei mir, dass sowas passiert. Aber scheinbar bin ich nicht der Einzige, und es kommt auf verschiedenen Loseseiten vor.

 

[Burkhardk]

----

 

[seppl2000]

Also da das Problem jetzt laufend stattfindet, auf verschiedenen Seiten, muss das Problem bei der EF-Schnittstelle liegen und nicht bei uns Seitenbetreibern.

Daher jetzt nochmal: Wurde an der Schnittstelle was verändert? Vllt. hast du da einen kleinen Fehler reingebracht?

 

[klamm]

Nein es wurde nichts verändert.

Warum Timeouts auftreten kläre ich ab - aber das gilt es wie gesagt auch sauber abzufangen.

 

[Norman1979]

auch bei mir das Problem bei Klamm sind Lose weg nur leider bei Loseleihen nicht angekommen EF 11708

02.07.14 09:17:11 - 18.600.000.000 EF 11708 Rueckzahlung Losekredit - lose-leihen.de



PS: ist erledigt und geklärt

 

[Deax]

Bei mir war es auch so einmal wie beschrieben das Guthaben nicht ankam und dann auch noch umgekehrt, das 65mrd. ausgezahlt wurden und ich keine Statistik habe was sehr ärgerlich ist.

Es wurde nun extra das umgeschrieben, das aufjedenfall zuerst bei mir die Buchung erledigt wird und falls es bei Klamm hakt das nix ankommt eine Retour auf meiner Seite erfolgt. Beim AZ/EZ-System solch ein Fehler kann teuer werden und hatten es genau nach Anleitung hier in meinem Script.

Vorallem kann ich auch nix nachvollziehen, wenn auf meiner Seite die Statistiken zu diesen Fehlbuchungen fehlen. Naja habe es nun zum Glück anders lösen lassen erstmal, aber auch mein Progger sagte normal darf sowas nicht sein.

 

[klamm]

Es gibt die API EF-Confirm, mit der Du jederzeit prüfen kannst ob eine zuvor abgesetzte Transaktion letztendlich ausgeführt wurde oder nicht (wenn das Script nicht geantwortet hat). Erst dann würde ich rückbuchen.

 

[HackStorm]

Nur bringt das nichts, ich erkläre mal etwas besser die Situation:

Es muss irgendwie ein fehler bei den Internet Knotenpunkten sein denn für den einen ist es erreichbar für den anderen nur mit sehr langer wartezeit somit konnte man eine Auszahlung Beantragen diese wurde an klamm geschickt doch bevor die Rückmeldung an das Script kamm das die Auszahlung erfolgt ist oder überhaupt eine Rückmeldung kamm vergingen minuten somit hatte der user zeit per abbrech funktion im Browser das ganze zu stoppen und konnte das guthaben nochmal auszahlen.

da bringt mir auch eine 2 abfrage zu klamm nichts wo dies verifiziert zumindest nicht in diesem fall.

 

[klamm]

Nein, sobald Deine Anfrage unsere Server erreicht, wird diese bei uns abgearbeitet - halt bei Überlast evtl. zu langsam um Deinem Script noch zu antworten. Wenn Du dann 5min später prüfst (was read-only/schnell ist) bekommst Du eine 100%ige Rückmeldung über den Ausgang.

Ein Fehler beim Knotenpunkt würde hier gar nichts anstoßen, richtig.
Es ist aber DB-Überlast gewesen - mittlerweile übrigens behoben.

 

[HackStorm]

Lach.. sorry das ich lachen muss ich weiß nicht ob du es jetzt richtig gelesen hast durch diese Zeitverzögerung konnte der user die abfrage vom script stoppen. ergo es kamm keine rückantwort und sorry aber durch den fehler bringt mir es 5 min später auch nichts in 5 minuten räume ich nen supergroßen ef mit dem fehler leer.

nochmal beispiel:

Anfrage mit losen senden -> abfrage bei klamm angekommen -> klamm sendet rückmeldung -> Script verbucht.

in diesem fall:
Anfrage mit losen senden -> abfrage bei klamm angekommen -> user bricht die scriptausführung ab.

Um sowas zu vermeiden müsste klamm die api komplett umändern:

die Transation wie normal beim ef abbuchen beim user nur vormerken danach eine Rückmeldung ans script schicken dort wird das guthaben abgezogen und sendet an klamm die überweisungsbestätigung das verbucht werden darf.

nur so kann man das zu 100% vermeiden.

mag sein das Db überlasst herschte aber das war dann noch zusätzlich denn es waren auch andere seiten betroffen wo nichts mit klamm zu tun haben die ewig geladen haben.

 

[theHacker]

user bricht die scriptausführung ab.

Wieso gibst du denn dann dem Benutzer die Möglichkeit, das Script abzubrechen?

Das is ja kein Problem auf Seite des EFs, sondern auf deiner

 

[Deax]

Über dem Browser kann man den Ladevorgang abbrechen...