mPay og ServeTheWorld-problemer …

Santo

Active Member
Hei,

Jeg forsøkte meg i 2006 med en Windows-hostingpakke hos ServeTheWorld, men måtte den gang droppe de som hostingpartner da jeg fikk problemer med å benytte mPay der.

Problemet var en eller annen slags cache som gjorde at meldinger ble debitert riktig første gangen, men etterpå slapp systemet igjennom samme kode flere ganger. ASP-scriptet som benyttes gjør egentlig en ny Microsoft.XMLHTTP-forespørsel mot Infogates mPay-server hver gang og skal dermed ikke slippe igjennom samme kode flere ganger, men hos ServeTheWorld virket det som om den første forespørselen ble lagret/cachet, og at det derfor ikke ble gjort noen nye sjekker mot Infogates server.

Det har nå gått en god stund siden dette skjedde og jeg tenkte derfor at jeg skulle forsøke meg med en ny hostingpakke hos ServeTheWorld. Jeg hadde et lite håp om at de hadde fått rekonfigurert serverne sine, eller fått endret dette ukjente som skapte/skaper problemer … Men neida, det eksakt samme problemet er fortsatt tilstede.

Jeg forsøkte forøvrig tilbake i 2006 å få hjelp av både Infogate (som jeg egentlig ikke tror har noe med problemet å gjøre) og ServeTheWorld, men hverken Infogate eller ServeTheWorld klarte å finne ut hva dette kom av. Jeg skal ta kontakt med ServeTheWorld igjen nå også, men har desverre ikke for store håp om at de finner ut hva dette skyldes.

Er det noen her som kan tenke seg hva dette kommer av? Jeg har brukt det samme debiteringsscriptet hos mange andre hoster både i Norge og utlandet, men det er kun hos ServeTheWorld at det ikke fungerer som det skal.

*forvirret* :confused:
 

Santo

Active Member
Ingen som har noen ideer eller ledetråder til hva problemene jeg beskrev tidligere kan komme av? Antakeligvis er problemene ikke mPay-relaterte, men heller ServeTheWorld og http-request relaterte …

Et eksempel fra mine nyeste erfaringer:

Jeg har en kode, f.eks. DFRTDSFR, som er verdt 10,- kr. Jeg forsøker å logge inn på testområdet mitt som koster kr 1,-. Dermed skal systemet si OK og slippe meg inn og debitere koden slik at det står igjen 9,- i verdi på koden. Så langt så bra.

Andre gangen jeg forsøker å logge inn igjen med den samme koden sier fortsatt systemet OK (som det jo også skal gjøre iogmed at det er penger igjen på koden), men jeg får fortsatt beskjed om at restverdien er på 9,- kr når den nå skulle vært 8,- kr.

Når jeg sjekker kodens verdi eksternt (hos en annen velfungerende host) så er den faktiske restverdien 8,- kr. Altså har mPay debitert koden riktig og sendt riktig restverdi til ServeTheWorld-serveren, men serveren til ServeTheWorld velger å presentere resultatet av den første http-requesten istedetfor den nyeste …

Jeg har også forsøkt å legge til en ekstra random-verdi i http-requesten (se kode nedenfor) slik at requesten skal være litt forskjellig hver gang, men dette hjalp desverre ikke.

Jeg vet heller ikke eksakt hvor lenge systemet til ServeTheWorld husker den første requesten, men det er ihvertfall snakk om en del timer, men mindre enn et døgn …

Så, det var noen flere ledetråder. Håper noen har mulighet til å vri hodet litt sammen med meg :)

Opprinnelig debitering:

Url = "http://www.infogate.no/mpayplus/debitx.aspx?"
QueryString = "clientid=" & ClientID & "&mpaycode=" & code & "&amount=" & amount

Set objHTTP = Server.CreateObject("Microsoft.XMLHTTP")
objHTTP.open "GET", Url & QueryString, false
objHTTP.send
Account = objHTTP.responseText
Set objHTTP= Nothing


Så forsøkte jeg å legge til en random key for at requesten ikke skulle være identisk:

Randomize
rndKey = int(Rnd * 100000)


Url = "http://www.infogate.no/mpayplus/debitx.aspx?"
QueryString = "clientid=" & ClientID & "&mpaycode=" & code & "&amount=" & amount & "&rndkey=" & rndKey

Set objHTTP = Server.CreateObject("Microsoft.XMLHTTP")
objHTTP.open "GET", Url & QueryString, false
objHTTP.send
Account = objHTTP.responseText
Set objHTTP= Nothing
 
Sist redigert:

Santo

Active Member
Jeg har kommet frem til en løsning, selv om jeg fortsatt ikke har funnet ut hvorfor ServeTheWorld-serveren oppfører seg annerledes enn alle andre servere jeg har benyttet …

Løsningen ble ihvertfall å benytte Msxml2.ServerXMLHTTP istedetfor Microsoft.XMLHTTP.

Jeg sier forøvrig gjerne ja takk for mer informasjon om problemet om noen skulle ha noe mer å tilføye i saken.
 
Topp