PHP und Anbindung an ein Zahlungssystem

[robotto7831a]

Hallo zusammen,

ich bastel gerade an einem Webshop. Und dort kann man dann mit Kreditkarte oder Onlineüberweisung bezahlen.

Jetzt muss ich über GET eine bestimmte URL aufrufen und dort die entsprechenden Daten mitgeben. Danach kommt ein Stream zurück mit entsprechendem Status ob es geklappt hat oder nicht usw.

Jetzt brauch ich mal einen Denkanstoß. Wie rufe ich innerhalb des Webshops diese URL auf und wie komme ich an den Rückgabewert dran.

Hoffe jemand hat eine passende Idee.

Frank

[Stephan601]

Du wirst deine Daten doch sicherlich über ein Formular abschicken. Das sollte in etwa so aussehen.

<form name="form1" method="GET" action="DEINE URL">

</form>

Die zurückgegebenen Werte kannst du mit $_GET oder $_Post abfangen.

Außerdem ist statt des "GET" ein "POST" besser, weil man dann die übergebenen Variablen nicht in der URL Zeile mitlesen und manipulieren kann.

Berichtigt mich, falls ich Müll geschrieben hab.

[baba007]

ich verstehe ehrlich gesagt nicht, was jetzt wo und wofür übertragen wird. Könntest du dein Problem etwas detaillierter beschreiben ?

[Amstelchen]

wenn dein PHP den fopen url wrapper aktiviert hat, dann führt schon ein fopen("http://user : pass@deinhost.tld/deinverzeichnis/deinedatei.ext") mit anschliessendem fread zum ziel. bei HTTPS und/oder vorangeschaltetem proxy siehts schon komplexer aus. oder du kapselst deinen GET-aufruf z.b. in der class HTTPRequest, die sich auf http://de.php.net/fopen findet.

s'Amstel

[robotto7831a]

Der Anbieter der die Zahlungen "eintreibt" möchte die Daten per GET übertragen haben.

An die URL wird die Kontonummer, die Bankleitzahl, der Betrag usw. usw. angehängt.

fopen wäre auch eine Möglichkeit.

Frank

[burns]

Ich hab zurzeit mit ähnlichen Problemen mit XML-Schnittstellen zu tun.

Ich habe die Ziel-Url mit fsockopen geöffnet und dann einen Header mit allen GET-Parametern mit fwrite an die URL geschickt.

Danach kannst du deinen Datei-Handler einfach mit fgets auslesen.

Bsp:

$fp = fsockopen("123.456.7.89", 80, &$errno, &$errstr, 100);

$httpHeader = "GET /verz/datei.php HTTP/1.1\r\n"; 

$httpHeader .= "Host: 123.456.7.89\r\n"; 

$httpHeader .= "Content-type: text/xml; charset=\"ISO-8859-1\"\r\n"; 

$httpHeader .= "Content-length: ".strlen($requestbody)."\r\n"; 

fwrite($fp, $httpHeader);

while (!feof($fp)) {

       echo htmlentities(fgets($fp));

}

[/PHP]

Oder noch einfacher: http://sourceforge.net/projects/snoopy/

gruß

burns

[Amstelchen]

Der Anbieter der die Zahlungen "eintreibt" möchte die Daten per GET übertragen haben.

An die URL wird die Kontonummer, die Bankleitzahl, der Betrag usw. usw. angehängt.

ich sehe da allerdings die problematik, dass die daten dann unverschlüsselt durchs netz geschickt werden, selbst wenn HTTPS verwendet würde. immerhin stehen dann die kontodaten in den parameterwerten des URL. ich würde als kunde da nicht einkaufen

s'Amstel

[etherius]

Ich würde da auch eher nicht einkaufen. Was sich aber anbieten würde ist z.B. eine Erweiterung von PHP wie CURL http://de2.php.net/curl

Damit kann man auch POST Daten übertragen:

Ich hab grad keine Zeit den Code selbst zu tippen aber es steht ein ganz anschaulicher Kommentar bei den CURL Funktionen auf php.net

<?

$url="http://anything";

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);

curl_setopt ($ch, CURLOPT_POST, 1);

curl_setopt ($ch, CURLOPT_POSTFIELDS, "fieldname=fieldvalue&fieldname=fieldvalue&");

curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);

$store = curl_exec ($ch);

$content = curl_exec ($ch); # This returns HTML

curl_close ($ch);

?>

[/PHP]

Der Kommentar stammt von admin at sellchain dot com geschrieben, ich hoffe ich darf das hier so zitieren.

mfg

Eth

[Whatever]

ich sehe da allerdings die problematik, dass die daten dann unverschlüsselt durchs netz geschickt werden, selbst wenn HTTPS verwendet würde. immerhin stehen dann die kontodaten in den parameterwerten des URL. ich würde als kunde da nicht einkaufen

s'Amstel

Ich würde ich das nicht sehen. Der HTTP-Request geht ja schließlich vom Webserver auf dem der Shop läuft ab, d.h. die einzigen beiden stellen wo er (realistisch betrachtet) abgefangen werden kann sind innerhalb der beiden RZ (einmal auf Seite von ihm, einmal bei dem Anbieter des Einzugsservice). Und ich glaube kaum das sich die Admins dort die Zeit mit Kontonummern-Fishing vertreiben...da gibt es einfachere Methoden um an Kontonr.-BLZ-Namen-Kombinationen zu kommen

[Amstelchen]

Ich würde ich das nicht sehen. Der HTTP-Request geht ja schließlich vom Webserver auf dem der Shop läuft ab, d.h. die einzigen beiden stellen wo er (realistisch betrachtet) abgefangen werden kann sind innerhalb der beiden RZ (einmal auf Seite von ihm, einmal bei dem Anbieter des Einzugsservice). Und ich glaube kaum das sich die Admins dort die Zeit mit Kontonummern-Fishing vertreiben...da gibt es einfachere Methoden um an Kontonr.-BLZ-Namen-Kombinationen zu kommen

und die rechenzentren sind deiner meinung nach nach direkt verbunden - es liegen keine interfaces dazwischen, an denen der unverschlüsselte HTTP-traffic mitgeschnitten werden kann? meiner meinung nach geht es prinzipiell darum, dass kontoinformation via SSL übertragen werden sollten - egal, wie minimal die gefahr des sniffens sein kann. es sind annahmen der gefahr, aber ich würde nie darauf vertrauen, dass sensible informationen nicht in falsche hände geraten. fast offtopic, aber man bedenke nur, was heutzutage alles mit fishing möglich sein dürfte.

s'Amstel

[Whatever]

und die rechenzentren sind deiner meinung nach nach direkt verbunden - es liegen keine interfaces dazwischen, an denen der unverschlüsselte HTTP-traffic mitgeschnitten werden kann?

Daher meine "realistisch gesehen".

Natürlich leigen da meist noch ein halbes dutzend Stationen zwischen. An denen läuft allerdings eine verdammt große Menge Informationen vorbei. Glaubst du wirklich da würde je jemand daher kommen und nach HTTP-Request filtern in den "?k=[0-9]+&b=[0-9]+&in=[a-zA-Z]+&iv=[a-zA-Z]+" vorkommt???

Und wenn du Kontonummer und BLZ als sensible Daten betrachtest denn würde ich diese 29300 Leute mal darauf aufmerksam machen.

[robotto7831a]

@all

Ich habe mir die Schnittstelle nicht ausgedacht. Die ist so. Ich muss nur damit arbeiten. Und es ist ein großes Zahlungsunternehmen.

Frank