Endlich ist es geschafft! Meine Direktanbindung an den Paymaster der Firma GZS funktioniert endlich.
Ich kann Euch gar nicht sagen, wieviele Nerven mich das gekostet hat. (An dieser Stelle noch einmal vielen Dank an die freundliche Dame vom GZS-Support-Team, die meinen ständigen Anfragen mit einer Engelsgeduld entgegentrat.)
Die Klasse, in der ich alle Funktionen zur direkten Kommunikation mit dem Paymaster gekapselt habe, steht eigentlich schon eine ganze Weile. Patrick hatte mir für erste Tests einen kleinen Server geschrieben, mit dem man den Paymaster simulieren konnte. Wir haben damit zunächst "Trockenübungnen" gemacht, weil unser Testaccount noch nicht fertig war.
Als es dann zur Sache ging, traten schnell die ersten Probleme auf. Der Verbindungsaufbau klappte, aber der Paymaster meldete uns statt eines fröhlichen "HTTP/1.1 200 OK" dauernd ein frustrierendes "HTTP/1.1 100 Continue". Mistfink! Sobald wir ein Byte zu wenig oder zuviel sendeten (Content-Length), leifen wir in einen Timeout. Also musste ein anderes Problem vorliegen.
Der entscheidende Tip kam dann vom Support-Team: Anstelle von "HTTP 1.1" wie es im Handbuch beschrieben ist, wird "HTTP 1.0" in der Anfrage verlangt. Ein kleiner, aber feiner Unterschied. (Anm.: Die Antwort des Servers beruht jedoch immer auf "HTTP 1.1"!)
Nach dieser Erkenntnis lieferte der Paymaster auch die gewünschte Antwort. Bei der Bestätigungsanfrage krachte es allerdings abermals. Auf eine korrekte Anfrage antwortete der Server ohne Angabe der Content-Length, allerdings auch ohne "Connection: Close". Bekommt man ein "Connection: Close", weiß man, dass man den Stream leerlesen soll, und dann die Verbindung gekappt wird. Lautes Fluchen konnte ich mir nicht verkneifen, aber Patrick bemerkte nur, dass sich ja eh keiner an die Standards halten würde, und ich mich nicht so aufregen solle.
Wie auch immer. Im Beispiel im Handbuch steht eine Content-Length-Angabe in der Antwort. Davon sollte man sich allerdings nicht täuschen lassen: Sie kommt nicht. Als Workaround habe ich mich damit angefreundet bei nicht gesetzter Content-Length den Stream leerzulesen. Das ist nicht ganz sauber, aber es funktioniert.
Ein weiteres kleines "Bonbon" ist, dass bei der Serverantwort auf die Bestätigungsanfrage als erstes Zeichen ein kleines "k" gesendet wird. Da der Client zunächst auf "HTTP/1.1 200 OK" prüft, führt dies zu einem neuen Problem. Hier sollte man den regulären Ausdruck etwas aufweichen: /^k?HTTP/[0-9]+\..[0-9]+\s+(200\sOK)/i
Ich hoffe, ich konnte mit diesem Artikel helfen, Frust zu vermeiden (und vielleicht sogar den GZS-Support etwas zu entlasten). Auf Anfrage stelle ich ggf. auch gerne meine Paymaster-Klasse zur Verfügung.
Abschließend würde ich gerne noch eine Frage stellen, die mir während der Entwicklung tausendfach in den Kopf kam: Warum zum Henker bietet die GZS keinen Webservice für die Zahlungsabwicklung an? Aus technischer Sicht sicherlich ein Klacks, zumal im Backend das .NET-Framework zu Verfügung steht. Für die Entwickler der Clients wäre das insofern angenehmer, weil man sich dann auf die wesentlichen Dinge konzentrieren könnte und sich nicht mit den Details der Verbindung auseinandersetzen müsste. Außerdem könnte der Webservice mit aussagekräftigen Fehlermeldungen auf fehlerhafte Anfragen reagieren.