Einerseits natürlich alle Daten, die für die Transaktion relevant sind, und bis zu sechs eigens definierte Variablen. Und nun kommen wir zur Sache: Unsere eigene User-ID, Zahlungs-ID und unseren Hash hängen wir nun an den URL einfach daran. Sie befinden sich nämlich in den eigenen USER-Variablen (aus dem Array). Wir haben also folgendes Array:
$array=array(12345,1234567,'','','','',10,'EUR','Einzahlung auf www.test.com','USER: MUSTERMANN',1122, '79bf16b7c1384f02aac5a2a759bca179','12345','','','','PROJEKTPASSWORT');
Es gibt nun wieder verschiedene Möglichkeiten, die Daten an den Server von sofortüberweisung zu senden. Ich habe mich für den Direktaufruf entschieden. Hierbei gibt es einen aufrufbaren URL von sofortüberweisung, dem man die Parameter aus dem Array übergeben muss.
Nun fragt man sich natürlich zu recht: Muss ich mein Passwort nun im Klartext per URL übergeben? Nein, natürlich nicht. Ebenso sind die Daten nicht manipulierbar. Denn zur Kontrolle erwartet der Fremdserver wieder einen Hash aus den Daten des Arrays. Notwendig ist hier natürlich, dass man alle Daten, die sich auch im Array befinden, mitliefert. Dieses sieht dann wie in Listing 2 aus.
Listing 2
$array=array(12345, 1234567, '', '', '', '', 10, 'EUR', 'Einzahlung auf www.test.com', 'USER: MUSTERMANN', 1122, '79bf16b7c1384f02aac5a2a759bca179', '12345', '', '', '', 'PROJEKTPASSWORT');
Grundsätzlich erwarten die Fremdserver einen wählbaren Hash, der aus dem Array erzeugt wird. Ich habe mich in unserem Beispiel für den MD5 Hash entschieden. sofortüberweisung berechnet den Hash, indem alle Array-Elemente durch ein Pipe in einem String getrennt werden. Aus diesem String wird dann der Hash erzeugt. So kann sichergestellt werden, dass nur das Projekt und der Fremdserver das Passwort kennen. Beispielhaft wird das in Listing 3 gezeigt.
Listing 3
$data_implode = implode('|', $array);
$hash = md5($data_implode);
// Nun erzeugen wir daraus eine konforme URL:
$url = '?user_id='.$array[0].
'&project_id='.$array[1].
'&amount='.$array[6].
'&reason_1='.$array[8].
'&reason_2='.$array[9].
'&user_variable_0='.$array[10].
'&user_variable_1='.$array[11].
'&user_variable_2='.$array[12].
'&user_variable_3='.$array[13].
'&user_variable_4='.$array[14].
'&user_variable_5='.$array[15].
'&hash='.$hash;
$url_zum_aufruf='https://www.sofortueberweisung.de/payment/start'.$url;
Diesen URL können wir nun als Link anbieten oder einfach direkt darauf weiterleiten. Ich persönlich bevorzuge letztere Methode, da der entsprechende User den URL nicht sehen und daher auch nicht in die Versuchung kommen wird, etwas zu manipulieren.
Hat man alles richtig gemacht, erscheint sofort die Frage nach der entsprechenden Bankleitzahl des Kunden. Der weitere Zahlprozess findet vollständig auf den Servern von sofortüberweisung statt und man muss sich um nichts weiter kümmern (Abb. 2). Sollte man Fehler im Skript haben, erscheint eine entsprechende Fehlermeldung (Abb. 3).
Abb. 2: Nur noch die BLZ eingeben
Abb. 3: Aussagekräftige Fehlermeldung
Die Server von sofortüberweisung kümmern sich nun um die Zahlungsabwicklung mit den jeweiligen Banken. Nach einem abgeschlossenen Zahlungsvorgang werden die entsprechenden Benachrichtigungen angestoßen. In unserem Fall haben wir zur Automatisierung die http:// -Benachrichtigung als bestmögliche Lösung befunden. Diese legt man einfach online im Projektbereich an. Wichtig für uns sind hier die selbst definierbaren Felder, die man mit verschiedensten Variablen füllen kann (Abb. 4).
Abb. 4: Eigene HTTP-Benachrichtigung anlegen
Bei einer automatisierten Zahlungsabwicklung sind vor allem die Felder, die wir vorhin übergeben haben, und der Betrag wichtig. Es empfiehlt sich, den URL für das „Empfangsskript“ zu verstecken und durch ein Passwort PHP-seitig zu schützen – auch wenn Ihre Besucher diesen URL nie zu Gesicht bekommen werden. Ein passender Benachrichtigungs-URL für unser Beispiel wäre also folgender: http://www.test.com/secure/payment_in.php?my_pwd=12345. Diese Benachrichtigung beinhaltet ein selbstdefiniertes Passwort zur Absicherung und alle relevanten Daten zur Zahlung: zum Beispiel den gezahlten Betrag, die externe Transaktionsnummer (für spätere Nachfragen lohnt es sich immer, sie zu speichern), unsere Rechnungsnummer, den selbst erstellen einmaligen Hash und die Kundennummer des Kunden, der gerade gezahlt hat. Folgende Daten in Listing 4 werden für die weitere Verarbeitung gesendet (gekürzt).
Listing 4
my_pwd => 12345 amount => 250.00 trans => 31556-126763-4FACA317-3F94 zahlungs_id => 1122 unique_hash => 79bf16b7c1384f02aac5a2a759bca179 user_id => 31556 transaction => 31556-126763-4FACA317-3F94 project_id => 126763 sender_holder => Max Mustermann sender_account_number => 2XXXXX89 sender_bank_code => 888XXXXX sender_bank_name => Demo Bank sender_bank_bic => PNAGXXXXXXX sender_iban => DE16888XXXXXXXXXXXXX89 sender_country_id => DE recipient_holder => Martin Bassus recipient_account_number => 0XXXX30 recipient_bank_code => XXXXXXXX recipient_bank_name => Deutsche BXXXXX recipient_bank_bic => DEUTXXXXXXX recipient_iban => DE78860XXXXXXXXXXXXX00 recipient_country_id => DE international_transaction => 0 currency_id => EUR reason_1 => Einzahlung auf www.test.com reason_2 => USER MUSTERMANN security_criteria => 1 user_variable_0 => 1122 user_variable_1 => 79bf16b7c1384f02aac5a2a759bca179 user_variable_2 => 12345 user_variable_3 => user_variable_4 => user_variable_5 => email_recipient => created => 2012-05-11 07:27:02 hash => 33bc2bfde133871333df3c6cffbb4ab0
Was in der payment_in.php passiert, ist vielfältig. Man kann die Rechnung in der Datenbank mit gutem Gewissen als gezahlt markieren, den Kunden eine Zahlungsbestätigung senden, seine Umsatzzahlen in verschiedenen Tabellen anpassen, das Lager um die bestellten Produkte erleichtern, den Versand per E-Mail benachrichtigen und einiges mehr. Wer vorher nur auf „Manuelle Zahlung“ (Überweisung) ausgelegt war und alles von Hand machte, hat nun einen Prozess mit wenigen Handgriffen massiv optimiert und kann die gesparte Zeit für wichtigere Dinge nutzen.
Weiter mit: Teil 3
Alle Teile: Teil 1, Teil 2, Teil 3
Meinungen zu diesem Beitrag