Zum Inhalt wechseln



Neueste Nachrichten (in Englisch): (am laden..)

Foto

security: ipayment


Dieses Thema wurde archiviert. Dies bedeutet, dass Sie auf dieses Thema nicht antworten können.
104 Antworten in diesem Thema

#21 klausg

klausg
  • Members
  • 10 Beiträge

Geschrieben 29 February 2008 - 18:03

im source seh ich in der schnelle nur das du ein form zuviel hast..
echo tep_draw_form('checkout_confirmation', $form_action_url, 'post');

Das Zweite ist auskommentiert ...



die hidden fields kommen vom modul. Musst also im Browser auf der seite in den sourcecode gucken...

Ahja ok ... jetzt hab ich den Fehler ... das lag am Seo-G, das hat die URLs auf *.html umgeschrieben ... alles klar, jetzt klappt es soweit !

Ich danke Dir für Deine Hilfe !

MfG Klaus
MfG Klaus

#22 mikl76

mikl76
  • Members
  • 14 Beiträge

Geschrieben 04 March 2008 - 09:47

Hallo Zusammen,
kann mir jemand von euch erklären was Seo-G ist?
Ich habe auch das Problem das ich nach Zahlung mit der Kreditkarte auf eine leere Seite komme.
Gruß
Mike

#23 Henri Schmidhuber

Henri Schmidhuber
  • Team Member
  • 1754 Beiträge

Geschrieben 04 March 2008 - 10:00

SEO Urls sind suchmaschinefreundliche URLs.
Das kann natürlich Probleme machen, wenn irgendwelche weiterleitungsURLs, benachrichtigungsURLs und so nicht gehen.
-> liegt aber dann an der SEO implementierung und nicht am Modul...
§ 1422-z StGB in der Fassung vom 12.4.2012:
Wer E-Mails verschlüsselt oder unlesbar macht oder sich verschlüsselte oder unlesbare E-Mails verschafft oder weiterverbreitet wird mit Gefängnis nicht unter 2 Jahren bestraft.
Der Versuch ist strafbar.

-> Supportanfragen via PM werden unbeantwortet gelöscht!

#24 mikl76

mikl76
  • Members
  • 14 Beiträge

Geschrieben 04 March 2008 - 10:50

Ich habe die SEO im Shop ausgeschalten jedoch wird die seite noch immer nicht gefunden.

Objekt nicht gefunden!
Der angeforderte URL konnte auf dem Server nicht gefunden werden. Der Link auf der verweisenden Seite scheint falsch oder nicht mehr aktuell zu sein. Bitte informieren Sie den Autor dieser Seite über den Fehler.

URL die aufgerufen werden sollte:
ttps://www.dh-parts.de/ext/modules/payment/ipayment/process.php

Kann mir jemand helfen?

Version meines Shops: osCommerce 2.2-MS2

#25 Henri Schmidhuber

Henri Schmidhuber
  • Team Member
  • 1754 Beiträge

Geschrieben 04 March 2008 - 12:11

Sieht ds aus als ob die files unter /ext nicht hochgeladen wurden...
Überprüf das mal..
§ 1422-z StGB in der Fassung vom 12.4.2012:
Wer E-Mails verschlüsselt oder unlesbar macht oder sich verschlüsselte oder unlesbare E-Mails verschafft oder weiterverbreitet wird mit Gefängnis nicht unter 2 Jahren bestraft.
Der Versuch ist strafbar.

-> Supportanfragen via PM werden unbeantwortet gelöscht!

#26 and7

and7
  • Members
  • 171 Beiträge

Geschrieben 04 March 2008 - 12:56

Hi nochmal,

also Bezahlen per CC geht mittlerweile. Leider hat sich nun ein anderes Problem aufgetan. Wenn ich eine Bestellung mit CC aufgebe, werden in der Bestellübersichtsmail keine Optionswerte angezeigt, nur leere Zeilen. Bei einer Bestellung ohne CC gehts nachwievor gut. Ich denke ich muss beim Anpassen der ipayment_cc.php was vergessen haben. Nur was?!
mfg

andi

#27 mikl76

mikl76
  • Members
  • 14 Beiträge

Geschrieben 04 March 2008 - 15:43

Danke an Henri!
Es lag an den Datein in /ext

Vielen Dank

#28 Henri Schmidhuber

Henri Schmidhuber
  • Team Member
  • 1754 Beiträge

Geschrieben 04 March 2008 - 17:14

Shit, mein Fehler
function before_process() {
	  global $HTTP_GET_VARS, $customer_id, $order, $order_totals, $sendto, $billto, $payment, $currency, $currencies, $cart, $cart_Ipayment_Direct_ID;
	  global $$payment;
	  global $languages_id;

global $languages_id; ist neu
§ 1422-z StGB in der Fassung vom 12.4.2012:
Wer E-Mails verschlüsselt oder unlesbar macht oder sich verschlüsselte oder unlesbare E-Mails verschafft oder weiterverbreitet wird mit Gefängnis nicht unter 2 Jahren bestraft.
Der Versuch ist strafbar.

-> Supportanfragen via PM werden unbeantwortet gelöscht!

#29 and7

and7
  • Members
  • 171 Beiträge

Geschrieben 05 March 2008 - 09:53

global $languages_id; ist neu

Da muss man auch mal drauf kommen :lol: Danke dir, es scheint jetzt alles zu gehen, wie es gehen muss
mfg

andi

#30 and7

and7
  • Members
  • 171 Beiträge

Geschrieben 05 March 2008 - 16:58

Jetzt ist mir doch nochwas aufgefallen nach intensiven Testen.

Erstes Szenario:
Kunde möchte mit Visa bezahlen, gibt aber aus Versehen Mastercard an. Bestellung wird abgewickelt, Buchungsbestätigungsmails werden "falsch" mit Mastercard verschickt. Keine Fehlermeldung.

Zweites Szenario:
Kunde gibt ein falsches Gültigkeitsdatum an. Bestellung wird abgewickelt, Buchungsbestätigungsmails werden "falsch" mit den angegeben Gültigkeitsdatum verschickt. Keine Fehlermeldung.

Drittes Szenario:
Kunde gibt falsche CVC Nummer (die dreistellige) an. Bestellung wird abgewickelt, Bestätigungsmails werden verschickt. Keine Fehlermeldung.

Bei falscher Kreditkartennummer oder in der Vergangheit liegendes Gültigkeitsdatum wird korrekt, mit richtiger Fehlermelung, auf checkout_payment.php redirected.

Wenn ich mich bei ipayment einlogge, stehen die Zahlungen aus Szenario 1 bis 3 als autorisiert und abgebucht da. Bei Szenario 2 steht in den ipayment Zahlungsdetails "Mastercard", obwohl es keine Mastercard ist. Bei Szenario 3 steht hinter "Kartenprüfnummer angegeben" ein "Ja", obwohl sie falsch übermittelt wurde.

Ist dass so gewollt? Getestet habe ich mit "richtigen" Kreditkarten auf einer Simulationsanwendung seitens ipayment (dem Zufolge werden keine Autorisierungsnummern vergeben). Hat dieses Verhalten nochwer beobachtet?
mfg

andi

#31 and7

and7
  • Members
  • 171 Beiträge

Geschrieben 06 March 2008 - 09:24

Guten Morgen,

habe noch ein wenig rumprobiert, diesmal auf einer nicht simulierten iPayment Anwendung.

Szenario1 kann man zwar nachwievor bspw. für eine Visa einfach Mastercard angeben, aber bei iPayment wird anhand der Kreditkartennummer der Kartentyp erkannt.

Szenario2 wird nun richtig gehandhabt und mit korrekter Fehlermeldung auf checkout_payment.php redirected.

Szenario3 wird nun fast richtig gehandhabt. Es wird mit der Fehlermeldung "Kartennummer und Gültigkeitsdatum" (selbe wie bei Szenaio2) auf checkout_payment.php redirected. Damit kann ich aber leben :(

Bleibt nur noch die Frage wieso solche Tests nicht auch bei einer simulierten ipayment Anwendung funktionieren ;)

Nichtsdestotrotz, danke an Henri fürs Bereitstellen der neuen Contrib.
... Im c't artikel las ich, dass die Erweiterung die ein Dienstleister für xtc programmierte (du?) auch PCI-DSS konform ist. Gilt selbes auch für dein Modul für osc? Beide Module scheinen nach dem Artikel ja etwas unterschiedlich zu arbeiten.
mfg

andi

#32 funfanta

funfanta
  • Members
  • 1 Beiträge

Geschrieben 06 March 2008 - 11:51

Moin,

ich hatte auch fast alle beschriebenen Schwierigkeiten. Die meisten konnte ich lösen.

Nun aber bekomme ich bei jeder Bestellung den Fehler: Die angegebene Transaktion ist bereits im System.

Selbst als ich heute Morgen den Browser neu geöffnet, eine neue Bestellung erzeugt, den Simulationsmodus aktiviert und eine Testkreditkartennummer (welche Prüfnummer und welches Datum muß man eigentlich bei Testdaten angeben?) genutzt habe, erschien die Meldung.

Ich nutze die Version osCommerce 2.2-MS2.

Danke für jede Hilfe / jeden Hinweis.

Grüße aus Hamburg,

Jens

#33 Henri Schmidhuber

Henri Schmidhuber
  • Team Member
  • 1754 Beiträge

Geschrieben 06 March 2008 - 16:09

Hi !

offizielle Antwort:
>> >> Erstes Szenario:
>> >> Kunde möchte mit Visa bezahlen, gibt aber aus Versehen Mastercard an.
>> >> Bestellung wird abgewickelt, Buchungsbestätigungsmails werden "falsch"
>> >> mit Mastercard verschickt. Keine Fehlermeldung.

Die Kartentyp-Auswahl ist nur Makkulatur und ist nur dazu da, das Kunden
besser Visualisieren welche Karten verfügbar sind.
Es ist Absicht das eine falsche Auswahl trotzdem durchgeht.

>> >> Zweites Szenario:
>> >> Kunde gibt ein falsches Gültigkeitsdatum an. Bestellung wird
>> >> abgewickelt, Buchungsbestätigungsmails werden "falsch" mit den
>> >> angegeben Gültigkeitsdatum verschickt. Keine Fehlermeldung.

Das liegt - wenn Verfallsdatum trotzdem in der Zukunft ist, am
Simulationsmodus, da dort nur geprüft wird das das Datum in der Zukunft ist.

>> >> Drittes Szenario:
>> >> Kunde gibt falsche CVC Nummer (die dreistellige) an. Bestellung wird
>> >> abgewickelt, Bestätigungsmails werden verschickt. Keine Fehlermeldung.

Ebenfalls SImulationsmodus -> CVC kann nur durch die Bank geprüft
werden. Wir prüfen nur das die länge korrekt ist.

>> >> Bei falscher Kreditkartennummer oder in der Vergangheit liegendes
>> >> Gültigkeitsdatum wird korrekt, mit richtiger Fehlermelung, auf
>> >> checkout_payment.php redirected.

jupp :-)

>> >> Wenn ich mich bei ipayment einlogge, stehen die Zahlungen aus Szenario
>> >> 1 bis 3 als autorisiert und abgebucht da. Bei Szenario 2 steht in den
>> >> ipayment Zahlungsdetails "Mastercard", obwohl es keine Mastercard ist.

Da brauch ich die Trx-Nummer. Wir prüfen den Kartentyp sehr genau.

>> >> Bei Szenario 3 steht hinter "Kartenprüfnummer angegeben" ein "Ja",
>> >> obwohl sie falsch übermittelt wurde.

Sie war ja angegeben ... und wegen Simulation halt nicht wirklich geprüft-
§ 1422-z StGB in der Fassung vom 12.4.2012:
Wer E-Mails verschlüsselt oder unlesbar macht oder sich verschlüsselte oder unlesbare E-Mails verschafft oder weiterverbreitet wird mit Gefängnis nicht unter 2 Jahren bestraft.
Der Versuch ist strafbar.

-> Supportanfragen via PM werden unbeantwortet gelöscht!

#34 and7

and7
  • Members
  • 171 Beiträge

Geschrieben 07 March 2008 - 09:08

danke für deine Antworten :P Wie gesagt, im Livebetrieb funktioniert nun alles reibungslos (vorerst! *zitter*) insofern ist die Trx-Nummer wohl hinfällig :)
mfg

andi

#35 mmss

mmss
  • Members
  • 1 Beiträge

Geschrieben 11 March 2008 - 15:43

hallo henri!

nach der installation der neuen version erhalte ich folgende fehlermeldung, wenn ich die kreditkarten-daten auf checkout_confirmation.php eingebe.

"
Folgender Fehler wurde vom Kreditkartenunternehmen während des Prozesses gemeldet:
Die Zahlung wurde abgelehnt (ipayment-FPS/FDS).
"

die änderungen an der checkout_confirmation.php habe ich durchgeführt. die daten werden an
https://ipayment.de/...x/processor.php gesendet

so sehen die übertragenen daten aus (ausgabe von "live http headers"; mit dummy-zahlen geändert), wenn das formular abgeschickt wird:

addr_name=Peter+Beispiel&
cc_typ=VisaCard&
cc_number=1234567890123456&
cc_expdate_month=08&
cc_expdate_year=09&
cc_checkcode=123&
silent=1&
trx_paymenttyp=cc&
trxuser_id=1234&
trxpassword=12345678&
ignore_cc_typ_mismatch=1&
order_id=9999&
shopper_id=12345-9999&
transaction_id=9999&
advanced_strict_id_check=1&
strict_id_check=&
from_ip=210.70.170.220&
trx_currency=EUR&
trx_amount=1234&
trx_typ=auth&
addr_email=mail@mail.de&
addr_street=strasse22&
addr_city=berlin&
addr_zip=12345&
addr_country=DE&
addr_state=BAW&
addr_telefon=123456789&
redirect_url=https%3A%2F%2Fwww.example.de%2Fcatalog%2Fext%2Fmodules%2Fpayment%2Fipayment%2Fprocess.php&
silent_error_url=https%3A%2F%2Fwww.example.de%2Fcatalog%2Fcheckout_payment.php%2Fpayment_error%2Fipayment_cc&
hidden_trigger_url=https%3A%2F%2Fwww.example.de%2Fcatalog%2Fext%2Fmodules%2Fpayment%2Fipayment%2Fhidden_trigger_cc.php&
error_lang=de&
shop_lang=german&
client_name=PROJECT_VERSION&
client_version=ipayment-CC-Modul+2.0&
invoice_text=Nr.+9999+example.de&
x=42&
y=16

ipayment-daten habe ich mehrmals überprüft, auch die kreditkarten-daten sind korrekt und müssen funktionieren.

wo kann der fehler liegen?

osc-version: MS 2.2 (2006)

#36 supersonic

supersonic
  • Members
  • 85 Beiträge

Geschrieben 19 March 2008 - 16:25

Hallo Henri,

danke erstmal für Deine Geduld und Mühen. Ich habe ähnliche Probleme wie die Leute hier und komme dem Ganzen so nach und nach auf die Schliche. Mir ist folgender Fehler in Deiner Anleitung aufgefallen.

Siehe Beitragslink 16: Du schreibst, dass die genannte Zeile vermutlich fehlt ... Ja, denn laut Deiner Anleitung (PDF Seite 8) soll sie auskommentiert werden, bzw. wird der geänderte Quellcode nicht vollständig nach oben kopiert.

Ich benutze das ELV Modul im Testbetrieb (mit User ID 9999 usw) unter 2.2 MS ... Ich kriege jetzt folgende Meldung:

Bitte kontrollieren Sie die Daten Ihrer Kreditkarte!

obwohl es das ELV Modul ist..

oder mit einer anderen Bankverbindung:

Die angegebene Transaktion ist bereits im System.


...woran kann das noch liegen?

Grüße

Bearbeitet von supersonic, 19 March 2008 - 16:28.

RTFM

#37 supersonic

supersonic
  • Members
  • 85 Beiträge

Geschrieben 20 March 2008 - 20:01

Hallo,

zur Info:

ich habe beide Probleme gelöst...es lag an mir. Zum einen hatte ich noch aus Versehen das alte KK Modul von iPayment vor dem Lastschrift Modul positioniert und aktiviert ..deswegen die Meldung, dass die KK Daten zu überprüfen sein.

Das andere Problem war, weil die Transaktion anscheinend vom iPayment Testaccount gespeichert wird.

Mit meinem eigenen Account komme ich dann weiter..allerdings sollen immer noch die Bankdaten überprüft werden. Zwischendurch gingen sogar zweimal Testbestellungen im Sim- Modus an iPayment durch und wurden trotz Fehlermeldung verarbeitet. Im Shop komme ich trotzdem nicht weiter ... wird da was nicht weitergegeben?

Langsam verzweifle ich :-(
RTFM

#38 Henri Schmidhuber

Henri Schmidhuber
  • Team Member
  • 1754 Beiträge

Geschrieben 24 March 2008 - 10:05

Ich habe gerade keine Kristallkugel zur Hand. Aber im zweifelsfalle mich mal direkt per email kontaktieren, dann kann ich mal drüberschauen.


Grüße
Henri
§ 1422-z StGB in der Fassung vom 12.4.2012:
Wer E-Mails verschlüsselt oder unlesbar macht oder sich verschlüsselte oder unlesbare E-Mails verschafft oder weiterverbreitet wird mit Gefängnis nicht unter 2 Jahren bestraft.
Der Versuch ist strafbar.

-> Supportanfragen via PM werden unbeantwortet gelöscht!

#39 and7

and7
  • Members
  • 171 Beiträge

Geschrieben 03 April 2008 - 15:57

"
Folgender Fehler wurde vom Kreditkartenunternehmen während des Prozesses gemeldet:
Die Zahlung wurde abgelehnt (ipayment-FPS/FDS).
"


Diesen Fehler habe ich nach dem ich drei kurz aufeinander folgende Transaktionen von ein und der selben IP Adresse durchführe. Hast du evtl eine statische IP bei deinem ISP? Evtl bist du mit dieser auf einer permanenten Blacklist bei iPayment gelandet... ...Wenn du keine statische IP hast probier doch einfach mal eine Neueinwahl zum ISP / Routerreboot, das hilft bei mir zumindest <_<
mfg

andi

#40 Henri Schmidhuber

Henri Schmidhuber
  • Team Member
  • 1754 Beiträge

Geschrieben 03 April 2008 - 17:14

kann sein, da gibts aber normallerweise ne Email: ipayment: Kunden-IP fuer Zahlungen voruebergehend gesperrt....
§ 1422-z StGB in der Fassung vom 12.4.2012:
Wer E-Mails verschlüsselt oder unlesbar macht oder sich verschlüsselte oder unlesbare E-Mails verschafft oder weiterverbreitet wird mit Gefängnis nicht unter 2 Jahren bestraft.
Der Versuch ist strafbar.

-> Supportanfragen via PM werden unbeantwortet gelöscht!