Onnodige statusverzoeken iDeal door CRON, logbestanden van honderden megabytes, tragere iDealsystemen! Options

[aldert]

Vandaag gebeld door iDeal. Mijn systeem deed een beetje veel statusverzoeken.

Het probleem lag hem in het CRON script dat elk kwartier checkte. Er waren blijkbaar een aantal regels in tabel ideal_payments die een transaction_id van 0 hadden. Die krijgen uiteraard nooit een status hoger dan wachtend op betaling. Schoon of deze tabel op, of bouw voorwaarde in query te controleren betalingen:

$payments_query = mysql_query("SELECT * FROM " . TABLE_IDEAL_PAYMENTS . " WHERE payment_status='".MODULE_PAYMENT_IDEALM_ORDER_PENDING_STATUS_ID."'");

wordt dan:

$payments_query = mysql_query("SELECT * FROM " . TABLE_IDEAL_PAYMENTS . " WHERE payment_status='".MODULE_PAYMENT_IDEALM_ORDER_PENDING_STATUS_ID."' AND transaction_id != 0 ");

in idealm_cron.php in /admin/

Eventueel ook nog aanpassen in idealm.php, als je veel handmatig update.

[thisnix]

Ik had afgelopen weken ook al een paar telefoontjes van de ING. Men zegde toe om de code te sturen, maar dat is tot op heden nog niet gebeurd. Dit was wat men mij melde per email vandaag:

Gedurende afgelopen maand is door iDEAL geconstateerd dat vanuit uw
AcceptantenID maar liefst 20655 status verzoeken zijn uitgevoerd met
transactienummer welke alleen NULLEN (0000000000000000) bevat.
Ons is niet duidelijk waarom deze transacties ingestuurd zijn, ze belastten het ideal server platform onterecht.
Het zal u duidelijk (moeten) zijn dat dit niet de bedoeling is.

We willen u met klem vragen een onderzoek te starten naar de oorzaak van deze 'status requests' om
performance problemen op de iDEAL servers te voorkomen.


Het lijkt verdacht veel op wat aldert meld. Maar als dat zo is, dan moeten toch (veel???) meer mensen hier last van hebben?

Een aanvullend verzoek van mijn kant resulteerde in dit mailtje:

Er zijn inderdaad meerdere relaties met hetzelfde probleem. Allen veroorzaakt door de OS commerce shop. Helaas is er nog geen enkele relatie geweest die ons van de programmaregels heeft kunnen voorzien. De noodzaak is inmiddels wel zo hoog dat we u dringend willen verzoeken zelf op onderzoek uit te gaan. Het is immers uw systeem, waar wij verder geen zicht op hebben.

In uw systeem zit een ingebouwde automatische loop. Wij verzoeken u deze loop uit te zetten.

Het probleem lag hem in het CRON script dat elk kwartier checkte. Er waren blijkbaar een aantal regels in tabel ideal_payments die een transaction_id van 0 hadden. Die krijgen uiteraard nooit een status hoger dan wachtend op betaling. Schoon of deze tabel op, of bouw voorwaarde in query te controleren betalingen:

$payments_query = mysql_query("SELECT * FROM " . TABLE_IDEAL_PAYMENTS . " WHERE payment_status='".MODULE_PAYMENT_IDEALM_ORDER_PENDING_STATUS_ID."'");

wordt dan:

$payments_query = mysql_query("SELECT * FROM " . TABLE_IDEAL_PAYMENTS . " WHERE payment_status='".MODULE_PAYMENT_IDEALM_ORDER_PENDING_STATUS_ID."' AND transaction_id != 0 ");

in idealm_cron.php in /admin/

Als ik het zo lees hoef ik dus alleen het stukje AND .... 0 eraan toe te voegen. Maar hoe check ik of dit werkt?
En nog een kleinigheid staat er in de regel:
"APOSTROF_SPATIE_AND? Ik twijfel even over die spatie...

Trouwens van grote logbestanden of tabellen met enorm veel gegevens heb ik geen last.

This post has been edited by thisnix: 12-09-2008, 19:15:01

[joop]

Die oplossing werkt gewoon, kan je vanuit gaan.

Het leuke blijft nog steeds dat de banken vergeten dat ze zelf de transactie met een id van 0 veroorzaken als hun eigen ideal systeem weer eens een hickup heeft.

Maar ja, wat doe je eraan.

[Arjo]

wordt dan:

$payments_query = mysql_query("SELECT * FROM " . TABLE_IDEAL_PAYMENTS . " WHERE payment_status='".MODULE_PAYMENT_IDEALM_ORDER_PENDING_STATUS_ID."' AND transaction_id != 0 ");

Moet dat niet <> 0 zijn in plaats van != 0? In SQL is het "niet gelijk aan" teken toch <>?

[Boudy]

Moet dat niet <> 0 zijn in plaats van != 0? In SQL is het "niet gelijk aan" teken toch <>?

nee

<> != ongelijk aan, maar groter of kleiner dan.

!= = is niet

Boudy

[aldert]

Ok, inmiddels er ook achter waarom die *#(%&)(*)( ING mij telkens mailt over niet uitgevoerde statusverzoeken en waarom ik zo nu en dan handmatig bestellingen met Tx-code=0 moet verwijderen:

Dus enige frustratie even van mij afgeschreven. Straks bannen ze mij nog :

CODE

Subject: Onderhoud zorgt voor mislukte transacties!!!

Tenminste, ik mag hopen dat het onderhoud is. Ik kreeg een e-mail van een klant dat zijn bestelling maar steeds niet wilde lukken en ik moet zeggen, dat gebeurt NOGAL VAAK met not-iDeal.

Mijn websysteem krijgt fijntjes GEEN transactiecode doorgegeven, zodat het systeem onmogelijk de status kan checken en ik
1. Jullie irritante e-mails krijg over het niet uitgevoerd zijn van een status request (nogal wiedes, ik heb geen Tx-code)
2. Ik jullie servers had belast met het telkens opvragen van status van bestelling met Tx-code 0, ware het niet dat ik heb ingebouwd dat deze transacties niet meer gecheckt worden.
3. De voorraad geclaimd wordt door een bestelling die ik handmatig weer moet verwijderen.
4. e-mails van klanten krijg hierover.
5. Mogelijk omzet derf!!!
6 EN VOORAL TIJD VERSPEEL!

Doe er wat aan/mee!

Dit betreft bijvoorbeeld transactie:
005000031**69
005000031**27
005000031**64

0050000313775096
005000031**44

Wat ik van jullie terugkrijg wanneer betaling niet mogelijk is (want jullie verdienen natuurlijk niet zo graag 75 cent aan die transactie):

--------------------Start of message
receiving from ssl://ideal.secure-ing.com:443/ideal/iDeal: HTTP/1.0 200 OK
Date: Sun, 03 May 2009 16:57:34 GMT
Server: Apache-Coyote/1.1
RC: DEC_SYS
PT: 868
Content-Type: text/html;charset=ISO-8859-15
Content-Length: 514
Set-Cookie: AlteonP=3e4510ce3e451221baeebaeb; path=
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<ErrorRes xmlns="http://www.idealdesk.com/Message" version="1.1.0">
  <createDateTimeStamp>2009-05-03T16:57:34.871Z</createDateTimeStamp>
  <Error>
    <errorCode>SO1000</errorCode>
            <errorMessage>Failure in system</errorMessage>
                            <errorDetail>System generating error: acquirer</errorDetail>
                <consumerMessage>Betalen met iDEAL is nu niet mogelijk. Probeer het later nogmaals of betaal op een andere manier.</consumerMessage>
  </Error>
</ErrorRes>
--------------------End of message

GEEN TRANSACTIECODE!

Hoe moet ik dan ooit de mislukte bestelling controleren in het iDeal systeem?

Mijn excuses voor de toon. U kunt er natuurlijk ook niets aan doen.

[joop]

Ban, afsluiten, rekening opheffen, faillissement aanvragen, staat je allemaal te wachten met zo een toon.

Mij benieuwen wat ze daar op antwoorden.

[aldert]

Verkoop ik me aandelen ING, ha, dat zal ze leren!

Nouja, als ik geen antwoord krijg zal ik even een wat technischer antwoord geven en een nieuw ticket aanmaken

Een medewerker is als het goed is hierop getraind hoor (even testen) ;-)

[aldert]

Geachte relatie, Er zijn inderdaad storingen geweest bij enkele deelnemende banken die reeds verholpen zijn. Onze excuses voor het ongerief. Wij vertrouwen erop dat alle transacties nu weer goed gaan. met vriendelijke groet, ING/iDEAL

Hiermee is het probleem van bestellingen met Tx-code 0 nog niet opgelost... Ik hoop dat ze nu eens gaan kijken naar de verkeerde terugmelding...

[scouse]

Ik heb net nog het pakketje van idealhulp.nl geïntegreerd in mijn osc.
Mijn (en dus hun) idealm_cron.php is nog niet aangepast in de zin zoals hierboven beschreven.