Ipayment Patch funktioniert nicht !

[kinderwelt]

Hallo,

ich habe das Patch 1.0.2 geladen und in meinen Gambio Shop (3.0.4 SP1) eingebaut. Leider bekomme ich immer noch bei jeder Transaktion folgende Fehlermeldung.

"Security hash does not match ()"

Die Kreditkarte wird belastet aber die Bestellung nicht ausgeführt. Wie bereits beschrieben in diesem Thread. Ich weiß im Moment nicht wo ich noch suchen soll. Wer kann mir weiter helfen?

Die Daten inkl. Security Code sind im Ipayment und auch im Shop richtig eingetragen

Danke mal im Voraus

Alexander Schildknecht

[Fitstore]

Icvh habe ebenfalls Schwierigkeiten.

Habe alle änderungen, wie in der Patch-readme beschrieben durchgeführt (v1.0.2)

Ich bekomme nun im Testdurchlauf, unabhängig von der Zahlungsart als nächsten Bildschirm nur noch folgende Meldung:

Parse error: syntax error, unexpected ';' in /home/fitstore/public_html/checkout_confirmation.php on line 214

die checkout_confirmation sieht bei mir an der Stelle wie folgt aus:

$smarty->assign('PAYMENT_METHOD', constant(MODULE_PAYMENT_ . strtoupper($order->info['payment_method']) . _TEXT;_TITLE))if (isset($_GET['payment_error']) && is_object(${$_GET['payment_error']}) && ($error = ${$_GET['payment_error']}->get_error()))

$smarty->assign('error', $error['title'].'<br />'.htmlspecialchars($error['error']));

}

Was mache ich falsch? Vielleicht kann mir jemand helfen?

[Espresso-Trinker]

@kinderwelt: Wurde der Security Key, der im XTC-Backend eingetragen wurde, auch im ipayment-Backend hinterlegt?

@Fitstore: Nach dem $smarty->assign() fehlt ein ";".

[Fitstore]

Super - danke schon mal. Ich kann leider kein php wo genau muss es denn hin?

Wäre das so richtig?

$smarty->assign('PAYMENT_METHOD', constant(MODULE_PAYMENT_ . strtoupper($order->info['payment_method']) . _TEXT;_TITLE))if (isset($_GET['payment_error']); && is_object(${$_GET['payment_error']}) && ($error = ${$_GET['payment_error']}->get_error()))

$smarty->assign('error', $error['title'].'<br />'.htmlspecialchars($error['error']));

}

[Espresso-Trinker]

Statt ")) if(" ")); if(" schreiben.

[kinderwelt]

@kinderwelt: Wurde der Security Key, der im XTC-Backend eingetragen wurde, auch im ipayment-Backend hinterlegt?

@Espresso-Trinker

Ja alle Daten inkl. Security wurden im Backend hinterlegt und auch bei Ipayment hinterlegt.

Gruß

[kinderwelt]

@Espresso Trinker

Die Zahlung wird ja auch abgewickelt.

In der DB-Tabelle payment_ipayment_log finde ich für jede Zahlung 2 Einträge.

1.) Security hash does not match ()

2.) Bei der Verarbeitung ihrer Kreditkarten ist ein Fehler aufgetreten.

Bei dem ersten Eintrag werden ja auch alle übergebenen Variablen angezeigt und darin finde ich u.a.

s:10:"ret_status";s:7:"SUCCESS"

s:13:"ret_errorcode";s:1:"0"

Für mich bedeutet das, dass Ipayment meinem Shop den Wert erfolgreich abgewickelt ohne Fehler zurückgibt.

[markus67]

Hi ...

mit dem Problem schlagen sich wohl mehrere rum ... hat hier zufällig jemand schon eine Lösung gefunden? Ich habe ebenfalls das gleiche Problem. Zahlung wird abgewickelt .. Fehlermeldung beim Rückkehr in den Shop .. und keine Bestellung vorhanden.

Bin auch bereit ein paar Euros für eine Lösung auszugeben.

Danke

Markus

[openservice]

Wir haben fast das selbe Problem. Über viele Monate hinweg funktionierte der Shop und die Bezahlungen via iPayment (ELV + KK) problemlos. Nun mussten wir den Shop zu 1und1 umziehen. Es hat soweit auch alles tadellos funktioniert. Der ges. Shop läuft, alle Daten und Datenbanken wurden umkopiert, nichts verändert (außer den Configfiles und den Session-Pfaden).

Ein Einkaufen und Bezahlen ist möglich. ABER: Sobald iPayment im Spiel ist (ELV oder KK) gibt es bei uns nun die selben Probleme:

Der Kunde klickt auf Bestellen, die Abwicklung via iPayment erfolgt und wird dem Kunden auch berechnet, doch die Rückmeldung im Shop landet wieder auf der "Bestellen" Seite und nicht auf der Success-Seite. Somit bekommt der Shop nichts mit und im schlimmsten Fall drückt der Kunde nochmal auf Bestellen - der Kreislauf beginnt neu.

EINZIGE, mir wirklich bekannte Änderungen: Neuer Server, und vor allem: PHP 5.2 statt bisher 4.x

Bei uns gibt es allerdings keine Fehlermeldung in der payment_ipayment_log bzgl. Security Hash oder so. Doch damit müsste es zusammenhängen.

Im iPayment-Technik Handbuch steht noch, dass, je nach Verwendung findender Technologie (normal-modus, silent-modus oder Gateway-modus) entweder ein hidden-triger-URL bzw. ein Transaktions-Security-Key eingegeben werden muss oder nicht. Hier hatten wir bisher keine Werte eingetragen und es funktionierte. Wie ist es bei euch?

Hilfe oder Tipps sind willkommen! ;-)

[openservice]

ich möchte euch mitteilen, dass unser Problem wahrscheinlich gelöst werden konnte.

Klar, wir hatten schon länger das Patch 1.0.2 installiert. Danach, siehe Beitrag zuvor, lief alles bis wir einen Serverumzug vornahmen. ALLES lief, BIS AUF iPayment und da genauer die Rücklieferung des (OK, oder nicht OK) von iPayment an den Shop. Man landete einfach wieder auf der checkout_confirmation Seite.

Unsere Lösung: Wir haben im Shop die Funktion der Erteilung einer neuen Session-ID nach Anmeldung (sinngemäß) abgeschalten.

Unklar, ob das wirklich die Ursache sein kann, aber im Moment läuft alles planmäßig, auch iPayment (ELV+KK).

Für euch zur Info, vielleicht hilft es - dann lasst es mich hier wissen.

Klaus