Der Ersteindruck

PayPal ist erstmal ein typischer Amerikaner, wo die paypal.de schonmal auf die paypal.com umleitet, und irgendwie sparrt man sich gleich das Impressum. Besonders interessant, wenn man mal die technische Support-Hotline braucht, z.B. wenn man sich fragt wie man in deren Sandbox, einen Nutzer-Account nun den aktiviert. Zugegeben, hab ich da die Dokumentation nicht gründlich gelesen, aber bei einigen PDFs im Integration Center, überfliegt man die gerne.

Google erstmal dein Freund auf der Suche nach dem Impressum, trotzdem hilft es nicht all zu weit, den bald kann man erfahren, nachdem man sich mit wiederholtem Drücken der „Eins“ durch die Hotline gebombt hat, dass es bei Paypal keine technische Hotline gibt.

Die Dame am Telefon ist trotzdem sehr freundlich, und empfiehlt den den Bugtracker (oder Merchant Technical Support), mit dem man erst einmal sowieso schon aufgespürt hat, aber vor den ganzen Eingabefeldern und der Registrierung dann doch abgewogen hat mal zu versuchen bei der Hotline anzurufen.

Einen halben Tag später hat man dann schließlich die wichtigsten Fragen geklärt, sich mit den Möglichkeiten der API vertraut gemacht, ein paar mal an die Tür gerannt, durch mehrere kleine Anrufe unterbrochen worden, Mittagspause nciht gemacht … ein ganz normaler Arbeitsalltag! Jedenfalls war dann Zeit mit der Implementierung wirklich anzufangen.

Übrigens: es scheint es sehr in Mode zu kommen das Gespräch durch Sicherheits-Meldungen in die Länge zu ziehen – only for 14¢ per minute!

Zur Integration

Das PayPal Integration Center stellt einige Möglichkeiten vor Paypal-Zahlungen in die Webseite zu integrieren.

Da ist erstmal natürlich die favorisierte Methode über Webservices, die allerdings bei Paypal nicht ganz so einfach zu realisieren ist. Gleich gesagt, PayPal ist Top-Nodge Technology, und sie setzen für SOAP Version 1.2 des Protokolls, sowie HTTPS und hauseigene Triple-Authentifizierung bzw. Signierung mit einem PayPal Private voraus.

Kurzum: auch ein gut kompiliertes PHP 5.2.1 mit SOAP machte irgendwann mit Meldungen bzgl. invalide Signierung oder Version des SOAP-Headers, oder einigen Namespace bzw. XDN-Validierungsfehlern schlapp. Zumindestens hab ich es irgendwann gelassen mich um eine einfache Implementierung via SOAP zu kümmern.

Stattdessen hab ich gleich einmal ein paar Bibliotheken gezogen, die sich allesamt um die Implementierung der PayPal-Services bemühten. Zwei funktionierten überhaupt nicht, zwei durften mit der Konstante SOAP_1_2 statt SOAP_1_1 gefixt werden, um nur wenig später gleiche Namespace-Fehlermeldungen auszuspucken, wie meine eigene Implementierung. Eine weitere Implementierung benutze SOAP-XML-Bausteine – also Templates – und funktionierte zwar erst einmal, trotzdem machte mir das Sorgen, falls PayPal zukünftig updaten würde.

Zuletzt entschied ich dennoch dafür es mit dem PayPal eigenen SDK zu verwenden. Zwar sind hier keine einfachen Beispieldateien gegeben, eher eine komplette Testapplikation, die es schwierig macht, jene Quelltext-Teile zu identifizieren, die auch übernommen werden wollen. Dennoch lässt sich alles in PEAR installieren, oder besser *zähneknirsch* überschreiben, denn ein eigener PEAR-Channel scheint nicht zu exisiteren!

Fazit: Nach langen Dokumentationen, mächtigen Codebeispielen wurde mir allmählich klar, weshalb es dutzende Webseiten mit dem namen PayPal und/oder Developer in ihrem Domain-Namen gibt. Dabei handelt es sich bei PayPal doch nur um ein „einfaches“ Bezahl-System! *Hände-flehend-in-den-Himmel-streck*