Paymill Integration in Spree Commerce – Teil 2

In Teil 1 haben wir schon einmal einen Einblick darüber gegeben, warum wir Paymill in Spree Commerce einbinden wollten und was so eine Integration mit sich bringt. Im zweiten Teil wollen wir uns nun “das finale Produkt”, also unsere Spree Extension namens spree_paymill beschreiben.

Ablauf einer Bezahlung mit Paymill

Wir hatten beim letzten Mal einen kurzen Überblick darüber gegeben, wie der Service von Paymill funktioniert, wollen an dieser Stelle aber noch einmal ein wenig detaillierte darauf eingehen.

Schritt 1: Kunde wählt seine Bezahlmethode im Shop aus

Ist der Kunde innerhalb des Bestellprozess an der Stelle angekommen, an der er seine Bezahlmethode auswählen kann, so wird ihm ein passendes Formular zur Eingabe der Kreditkartendaten angezeigt. Die hier eingegebenen Daten werden allerdings nicht an den Server des Shops gesendet, sondern direkt an Paymill. Hierfür bindet der Betreiber des Shops eine JavaScript-Datei von Paymill ein.

Anschließend muss er sein Formular noch so anpassen, dass ein Klick auf den Button zum Verschicken des Formulars nicht selbiges absendet, sondern eine JavaScript-Funktion aufruft, die schlussendlich die Daten aus dem Formular per AJAX-Call an den Server von Paymill sendet. Der Shopbetreiber hat sogar die Möglichkeit, die Daten vor dem Absenden mittels von Paymill bereitgestellter Funktionen auf Gültigkeit zu überprüfen.

Sind die Kreditkartendaten vom Paymill-System verifiziert worden, so sendet der Server als Antwort einen Token zurück.

Paymill Einbindung in den Spree Commerce Bestellprozess

Paymill Einbindung in den Spree Commerce Bestellprozess

Continue reading

Paymill Integration in Spree Commerce – Teil 1

Wer unseren Twitter-Account verfolgt, dem wird bereits aufgefallen sein, dass wir viel über Spree berichten. Der Grund hierfür ist so simpel wie einleuchtend: Spree Commerce ist eine Open Source E-Commerce-Plattform auf Ruby on Rails Basis und passt daher bestens in unser Portfolio. Damit uns keiner nachsagen kann, wir würden nicht hinter den Technologien stehen, die wir unseren Kunden anbieten, nutzen wir Spree unter anderem auch für unseren eigenen Uhren-Shop Uhrmensch.de und für den vor einer Woche gestarteten Shop demavet.de.

Im Vergleich zu etablierten Open Source-Lösungen wie Magento, Oxid eSales oder osCommerce ist Spree in Deutschland noch nicht sehr verbreitet, obwohl es bereits seit mehr als fünf Jahren auf dem Markt ist. Das Schöne an Spree: die Software bringt ein Basis-Set an Funktionen mit und besitzt darüber hinaus ein unglaubliches Potential, was auch einer der Gründe war, warum wir uns für Spree entschieden haben, als wir nach einer einfach anpassbaren Lösung für Uhrmensch gesucht haben.

Wie schon angedeutet, aktuell ist die Standardinstallation von Spree noch ziemlich stark auf den amerikanischen Markt ausgelegt. Das merkt der Nutzer insbesondere bei der Auswahl der out-of-the-box zur Verfügung stehenden Zahlungsmöglichkeiten.

Auf die Zahlmethoden kommt es an

Für einen noch recht kleinen Onlineshop, wie es Uhrmensch.de derzeit noch ist, lohnt es sich nicht, eine Zahlung auf Rechnung oder per Bankeinzug anzubieten. Wir starteten daher Anfang Dezember 2012 mit Zahlung per Vorkasse und einer Paypal-Integration. Die Zahlung per Vorkasse lässt sich in Spree einfach durch die integrierte Zahlungsart “Check” abdecken, welche ja einen ähnlichen Use Case darstellt. Um Zahlungen über Paypal anzunehmen, muss der Nutzer lediglich eine so genannte Extension in seinen Spree Shop einbinden.

Die Liste der Extensions auf der Spree-Website ist bereits recht lang und ein Blick darauf zeigt, dass sich hier auch einige Zahlungsmethoden verstecken, unter denen Shopbetreiber auswählen können. Die offizielle PaypalExpress Extension, welche man hier ebenfalls findet, ist übrigens auch bei uns eingebunden und funktioniert tadellos.

Doch eine der beliebtesten Zahlungsarten (neben dem Kauf auf Rechnung) in Deutschland ist und bleibt die Bezahlung per Kreditkarte.

Ein kleiner Exkurs: Viele Online-Käufer wissen nicht, dass Paypal es ihnen auch ermöglicht, eine Kreditkartenzahlung durchzuführen, selbst wenn sie noch kein Paypal-Konto haben. Aus diesem Grund wird in den meisten Fällen eine Whitelabel-Lösung in Shops eingesetzt, welche die Kunden innerhalb des Bestellprozesses auf eine externe Seite des so genannten Payment Service Providers (PSP) entweder direkt weiterleitet oder diese per iFrame einbindet. Hier kann der Kunde dann seine Kreditkartendaten angeben und wird im Erfolgsfall auf eine vorher definierte Rücksprungadresse im eigentlichen Shop zurückgeleitet. Ziel des Onlineshops ist es in beiden Fällen, eine so genannte PCI-Zertifizierung zu umgehen, da diese viel Zeit und Geld kostet. Um dennoch PCI konform zu sein, lässt man die Bearbeitung der Kreditkartenzahlung (inkl. Speicherung der Kreditkartendaten) durch den jeweiligen PSP durchführen, welcher seinerseits PCI zertifiziert ist.

Geld regiert die Welt

Einige der größten “Pain Points” bei der Zahlung per Kreditkarte sind die teils recht hohen Gebühren, die der PSP bei jeder Zahlung einstreicht. Darüber hinaus muss der Shopanbieter auch noch zahlreiche Hürden wie z.B. den erfolgreichen Erhalt eines Kreditkarten-Akzeptanz-Vertrages überwinden, bevor er seine erste Bestellung per Kreditkarte entgegen nehmen kann. Man merkt schnell, dass diese Zahlungsmethode für den Endkunden zwar einfach gelöst ist, der Händler aber viel Zeit und Mühe in das Thema investieren muss.

paymill-RGB copy

An diesem Punkt greifen Services wie das in den USA gestartete Stripe und sein europäischer Bruder Paymill ein. Sie versuchen, mit einem einfachen Service-Ansatz die Probleme der klassischen Kreditkartenzahlung aus der Welt zu schaffen. Hierfür wird den Shopanbietern eine leicht verständliche API angeboten, welche sie einfach in ihr Shopsystem integrieren können. Und schon kann auch der kleinste Onlineshop oder auch einfach nur eine statische Website, auf der wenige Produkten verkauft werden sollen, Kreditkartenzahlungen annehmen. *

Unschlagbar sind bei diesen Services die anfallenden Kosten. So berechnet Paymill seinen Kunden lediglich 2,95% von der jeweils getätigten Zahlung + 0,28 Euro. Es gibt keine Grundgebühr oder andere versteckte Kosten, die der Händler (monatlich) zahlen müsste.

APIs For The Masses

Wie genau funktioniert nun die Einbindung von Paymill in den eigenen Shop? Glücklicherweise gibt es für viele Systeme bereits vorgefertigte Plugins, welche eine Einbindung recht einfach werden lassen. Für Spree Commerce gab es diese bis dato aber noch nicht. Daher haben wir uns selbst daran gemacht, diese Einbindung vorzunehmen, um Kreditkartenzahlungen auf Uhrmensch.de entgegen nehmen zu können.

Zunächst einmal muss man erwähnen, dass es bereits eine Ruby-Anbindung für Paymill gibt, die von Stefan Sprenger geschrieben wurde. Wer also “Plain Ruby” machen will, der findet hier einen guten Einstieg. Als wir mit unserer Anbindung begannen, hatten wir das Gem als Basis für unsere Integration in Spree verwendet. Da hier allerdings noch nicht alle API-Calls von Paymill vorhanden waren, die wir für unseren Shop brauchten, erweiterten wir die bestehende Codebasis (unsere Änderungen sind mittlerweile in das Original-Repository eingeflossen).

Doch gehen wir kurz einen Schritt zurück. Wie bereits angedeutet verhindern Services wie Paymill und Stripe, dass sich jeder Shop PCI zertifizieren lassen muss. Erreicht wird dies, indem der jeweilige Shop die Kreditkartendaten seiner Kunden nicht in seinem System speichert, sondern die komplette Verarbeitung dieser Daten auf den Servern des Payment-Anbieters vollzogen wird. Ein ähnlicher Ansatz, wie ihn die PSPs ebenfalls fahren.

Der Unterschied bei der Verwendung von Paymill ist nun wie folgt: Der Shopanbieter bindet ein Javascript-File auf der Payment-Seite seines Shops ein. Werden nun die Kreditkartendaten durch den Kunden eingegeben, so wir das Formular nicht direkt abgeschickt, sondern die Daten werden per AJAX an Paymill übermittelt (das Javascript-File bringt übrigens auch von Haus aus direkt einige Prüfmöglichkeiten für die eingegebenen Werte mit sich). Wurden die Kreditkartendaten als Gültig verifiziert, so antwortet der Paymill-Server mit einem Token, welchen das Shopsystem im Anschluss einmalig verwenden kann, um z.B. einen Betrag auf der Kreditkarte eines Kunden zu reservieren. Dieser Schritt wird dann allerdings über eine direkte, serverseitige Kommunikation im Backend vorgenommen. In unserem Fall also durch den Shop.

Spree Commerce setzt als Basis für seine Zahlmethoden auf eine starke Integration mit ActiveMerchant (AM), einem Framework, welches aus der Codebasis von Shopify extrahiert wurde. Zunächst hatten wir noch versucht, unsere Integration unabhängig von AM vorzunehmen, doch entschieden wir uns nach kurzer Zeit dazu, hier ebenfalls eine Erweiterung des bestehenden Codes vorzunehmen um dichter am bereits bestehenden Spree-Code zu sein – und auch, weil es zu diesem Zeitpunkt noch keine Anbindung an die Paymill-API in AM gab.

Wir gossen unsere Shop spezifischen Anpassungen in eine offizielle Spree Extension, die wir klassisch und einfach spree_paymill genannt haben. Nach einigen weiteren Tests auf Uhrmensch.de werden wir die Extension in den kommenden Wochen noch offiziell freigegeben, damit sie auch andere Spree Shops nutzen können.

Das “Problem” mit Open Source

Ein klarer Vorteil von Open Source Software ist es, dass jeder Entwickler bestehenden Code erweitern kann. In unserem Fall wurde dies allerdings zu einem (kleinen) Nachteil, da die EntwicklerInnen von spreed.ly in der Zwischenzeit selber an AM geschraubt und ebenfalls eine Anbindung an Paymill vorgenommen hatten, die nicht mehr zu dem Codeansatz passte, welchen wir ins Auge gefasst hatten. Aufgrund des weiter fortgeschrittenen Codes von spreed.ly entschieden wir uns dazu, nicht unsere Anbindung von Paymill zu verwenden, da wir so die Abhängigkeit zum Ruby-Paymill Gem entfernen konnten.

Allerdings mussten wir auch hier erneut eigene Anpassungen vornehmen, denn die Erweiterung von AM führte die Authentifizierung der Kreditkartendaten und das Reservieren des Betrages in einem Schritt durch. In Deutschland ist es aber Pflicht, dem Kunden vor dem Absenden einer Bestellung eine Übersicht über seine mögliche Bestellung anzuzeigen, bevor er diese endgültig abschickt. Es ist möglich, diesen Preview-Schritt in Spree einzuschalten, jedoch hat dies zur Folge, dass die Bestellung nicht direkt durchgeführt und damit der Betrag auf der Kreditkarte auch nicht sofort reserviert wird. Erst wenn der Kunde seine mögliche Bestellung überprüft und endgültig bestätigt hat, dass er diese ausführen will, wird der Betrag auf der Kreditkarte reserviert. Aus diesem Grund sind wir derzeit dabei, eine Änderung im AM-Repository zu beantragen, um die Autorisierung einer Zahlung auch mit einem bestehenden Token direkt durchführen zu können.

Dies war Teil 1 unseres Erfahrungsberichtes zum Thema Paymill Integration in Spree Commerce. Im zweiten Teil werden wir uns näher mit der technischen Umsetzung einer neuen Payment-Methode in Spree und der Anbindung von Paymill über ActiveMerchant befassen.

 

* Um Zahlungen des Live-Systems annehmen zu können, muss man noch einen schriftlichen Vertrag mit Paymill abschliessen.

webionate Hackathon #1

Heutzutage gehört es für Unternehmen (nicht nur aus der IT) zum guten Ton, wenn man seinen Entwicklern für einen bestimmen Zeitraum frei gibt, um gemeinsam an einem oder mehreren Projekten zu arbeiten, welche nichts mit den eigentlichen Aufgaben im Tagesgeschäft zu tun haben. Wenn das Unternehmen dann auch noch (fast) komplett aus Entwicklern besteht, dann bietet sich so etwas auch wunderbar als Team bildende Maßnahme für die gesamte Belegschaft an.

Internet Status? Check!

Internet Status? Check!

Auch wir wollten diesem Trend in nichts nachstehen und so machten wir uns am 15. Februar auf den Weg nach Groß Schwansee, einem Örtchen in Mecklenburg Vorpommern und damit 1 1/2 Fahrstunden von unserem Hauptquartier in Hamburg entfernt, wo wir uns für die kommenden 27 Stunden in einem Ferienhaus einschlossen, um an einem neuen Projekt zu werkeln.

Bereits im Vorfeld hatten wir aus einer Vielzahl an Vorschlägen unseren Favoriten hierfür ausgesucht, denn wir wollten nicht unnötige Zeit mit der Findung einer Idee verlieren, die allen Beteiligten zusagte. In größeren Unternehmen bilden sich zum jeweiligen Hackathon meist kleinere Gruppen, um ein Projekt gemeinsam anzugehen, bei einem Team von gerade einmal 6 Leuten machte dies für uns allerdings nicht ganz so viel Sinn, so dass wir uns dafür entschieden, ein gemeinsames Projekt in Angriff zu nehmen.

Planungsphase Planungsphase

Das Projekt

Wer uns schon einmal in unserem Büro besucht hat, dem wird der [riesige] 60” Fernseher aufgefallen sein, der an einer unserer Bürowände hängt. Wir nutzen diesen, um jederzeit bestens informiert zu sein. Hierfür haben wir ein Chromebook an den Fernseher angeschlossen, auf welchem mehrere Browser-Tabs geöffnet sind, die unter anderem Flowdock, einige unserer Google Analytics Accounts (im Live-View) und andere Seiten, wie z.B. Google News anzeigen. Damit wir nicht per Hand ständig zwischen den einzelnen Tabs wechseln müssen, ist in Chrome eine Extension installiert, welche diese Arbeit für uns übernimmt.

IMG_1427

Doch das ständige wechseln zwischen den einzelnen Browser-Tabs bringt einige Nachteile mit sich. Je nachdem, wie die jeweilige Website aufgebaut ist, wird sie auf einem so großen Gerät mehr oder weniger gut angezeigt. Ein großer Fernseher ist halt nicht das, was (Web-) Entwickler im Kopf haben, wenn sie sich Gedanken über die Geräte (ihrer Zielgruppe) machen. Hinzu kommt, dass sich die Extension zum wechseln der Tabs nicht so detailliert einstellen lässt. Eine Eingrenzung, dass nur bestimmten Tabs nach dem Wechsel neu geladen werden, ist leider nicht möglich. Schade, denn bei vielen Seite wäre dies überhaupt nicht von Nöten, da sie ihre Daten per AJAX aktualisieren (wie z.B. Google Analytics).

IMG_1428

Hier wollten wir mit unserer App (Codename “Houston”) nun ansetzen und den Nutzern eine Möglichkeit bieten, die für sie relevanten Daten auf einem großen Display bestmöglich zu präsentieren. Die Idee war es, einen offenen Dienst zu bauen, an den andere Entwickler/Anwender ihre eigenen (web)Hooks, wie zum Beispiel github, anbinden können. Die Grundidee sollte auf flowdock basieren, aber anstatt des statischen 2-Spalten-Designs, wollten wir unsere Lösung – wie bereits erwähnt – auf großen Geräte anzeigen lassen und so eher zu einer Art Dashboard machen, welches einen Überblick über die Geschehnisse in der eigenen Firma (und der restlichen Welt) bietet.

Hierfür sollte es neben der eigentlichen Timeline möglich sein, verschiedenste so genannte “Widgets” einzubinden, welche die Daten entsprechend des jeweiligen Services auf vordefinierte Art und Weise darstellen.

Happy Group Hacking

Happy Group Hacking

Direkt nach unserer Ankunft starteten wir mit unserer ersten Planungsphase, um herauszufinden, was wir in den kommenden Stunden überhaupt erreichen konnten/wollten. Sofort wurde uns klar, dass wir zunächst einmal ein “Basis-Framework” würden erstellen müssen, um sogenannte “Events” entgegen zu nehmen, diese dann weiter verarbeiten und schlussendlich darstellen zu lassen.

Events können dabei von verschiedenster Art sein, wie zum Beispiel der erfolgreichen Bestellung eines Kunden, in einem unserer (Spree Commerce) Onlineshops oder auch dem push einer Codeänderung in einem unserer Repositories, welche auf github mit Houston verbunden sind. Wir wollten außerdem eine Möglichkeit schaffen, Google Analytics sinnvoll in die App einzubinden, damit unser Shopmanager [Claus] die Werte seiner geliebten KPIs auf einen Blick bewundern kann.

IMG_7255 IMG_1449

Tech, Tech, Tech:

Nach der Planung wurde die erste “Recon-Phase” gestartet, um herauszufinden, mit welchen Technologien wir unsere Ideen überhaupt umgesetzt bekommen bzw. welchen OpenSource Code wir weiterverwenden können, um das Rad nicht neu zu erfinden, wenn dies nicht nötig ist. Dass wir als WebFramework Rails 3 verwenden wollten, stand bereits im Vorfeld fest und erweitert wurde es durch unseren aktuellen Software-Stack: SASS, CoffeeScript, HAML und Foundation von Zurb.

Ein zentraler Teil unserer Lösung musste ein passendes Messaging-System sein, welches die aufgelaufenen Events an eine unbegrenzte Anzahl an Clients im Frontend schickt. Hier entschieden wir uns relativ schnell dazu, FAYE zu verwenden, weil es uns viele lästige Dinge in diesem Bereich abnahm und von Haus aus bereits in die gängigen Browsern läuft. FAYE baut eine Websocket-Verbindung mit dem Client auf, sofern dieser Websockets unterstützt. Ist dies nicht der Fall, so wird auf eine der anderen Methoden (Long-polling via HTTP POST, Cross Origin Resource Sharing, Callback-polling via JSON-P) umgeschwungen, um den Transport der Informationen sicher zu stellen.

Blick auf den ersten Prototypen

Prüfender Blick auf den ersten Prototypen

Die Datenkommunikation zwischen Back- und FrontEnd sollte per JSON erfolgen. Damit wir im FrontEnd die Antwort des Servers nicht auch noch per Hand verarbeiten müssen, entschieden wir uns dazu, die JavaScript Rendering Engine Tempo einzusetzen. Dank dieser müssen wir uns um das Verarbeiten des an den Browser zurückgesendeten JSONs keine Sorgen machen, da Tempo die Daten direkt in die jeweilig Struktur unseres Templates integriert. Einfach das nötige JS-File integrieren und die Daten über einen simplen Aufruf in der Form Tempo.prepare(element).render(data); in das Template rendern lassen. Fertig!

Der aktuelle Stand

“Houston, wir haben zu wenig Zeit!” – Ziel unseres Hackathons war es nicht, eine Release-fähige Version der Software fertig zu bekommen. Dafür würde die Zeit nicht reichen. Aktuell haben wir einen Stand, der zwar noch eine sehr frühe Phase darstellt, aber wir können über Testaufrufe Daten erfolgreich in unsere Event-Queue pushen. Wir haben ebenfalls bereits angefangen, eine Anbindung der Google Analytics API zu bauen und können Daten aus unseren Accounts in einem passenden Widget darstellen. Derzeit sind unsere Prioritäten allerdings ein wenig anders gesetzt, so dass wir Houston aktuell ein wenig auf Eis gelegt haben, um uns anderen Dingen zu widmen. Wer weiß, ob es uns nicht in ein paar Wochen wieder überkommt und wir uns erneut an das Projekt wagen. Es gibt bereits schon erste Gedanken darüber, ein anderes Messaging-System als FAYE zu verwenden, aber dazu vielleicht mehr an einer anderen Stelle.

IMG_7285 IMG_7279

Fazit

Wir hatten auf unserem ersten webionate-internen Hackathon eine Menge Spaß und haben viel (miteinander) gelernt, das uns in Zukunft behilflich sein wird, unsere Kunden noch besser beraten zu können. Nicht zuletzt hat dieser Event dazu beigetragen, alle Beteiligten weiter zusammen zu schweißen und das war auf alle Fälle eines unserer erklärten Ziele.

AddOns

  • Dank Karsten haben wir uns bestens ernährt, denn er kochte uns ein wundervolles Abendmahl bestehend aus Lachs an Tomaten und Rosmarin mit Nudeln, Fenchel und frisch geriebenem Parmesan.
  • Auch Entwickler brauchen (ein wenig) Schlaf, und nachdem wir am Freitag bis 4 Uhr morgens gewerkelt hatten, waren wir um 8 schon wieder auf den Beinen und hackten vor uns hin
  • Um ein wenig Sauerstoff zu tanken und uns die Gegend anzusehen, haben wir am Samstag vor unserer Abfahrt auch noch einen gemeinsamen Spaziergang unternommen (s. Fotos)
  • Dank RedBull und Extreme-Coffee von Claus wurde die Aufmerksamkeitsspanne aller Beteiligten um mehrere Stunden erweitert ;)
IMG_7294 IMG_7298