Gib mir Geld! Über Kreditkartenakzeptanz im Web. Folge 1
Wer eine e-Commerce oder SaaS Anwendung betreibt wird sich auch zwangsläufig mit dem Thema Payment & Billing auseinandersetzen müssen.
Kreditkartenanbindungen bestehen aber immer aus mindestens zwei Teilen:
a) Kreditkartenakzeptanzen
Übernimmt die Abrechnung mit dem Kreditkartenunternehmen, also Visa oder Mastercard. (Amex und JCB machen meines Wissens nur Direktgeschäft).Hierzu sind Akzeptanzverträge abzuschliessen.
Akzeptanzen sind in Deutschland einige Unternehmen, beispielsweise:
- Acceptance
- B+S Card Service
- ConCardis
- Deutsche Card Services - Pago
- Elavon
- HSBC Trinkhaus & Burkhardt
- Postbank P.O.S. Transact
- Wirecard AG
b) Payment-Gateway-Anbieter
Diese Unternehmen stellen PCI DSS zertifizierte Schnittstellen zum Acquirer, also der jeweiligen Akzeptanz, her. Hier wird quasi aus einem Wust von Legacy-Enterprise-Kram eine möglichst einfache, RESTfulle Schnittstelle bzw hosted Web App. Oder auch nicht.
Die Sicherheitsrichtlinien (PCI DSS) der Kredtikartenbetreiber, verlangen: Keine elektronische Erfassung von Kredtikartendaten ausserhalb zertifizierter Infrastruktur. Als normaler Shopbetreiber darf ich deshalb keine Rohdaten mehr erfassen, sondern muss meine Nutzer direkt zum Gateway-Anbieter schicken, damit er dort seine Zahlungsdaten eingibt. Gleiches Prinzip wie bei PayPal.
Während dies für einmalige Zahlungen kein Problem ist, wird es spätestens mit variabler, nutzungsabhängiger Abrechnung eines. Oder eben mit Abo-Modellen, die bei SaaS üblich sind.
Hier gibt es einige Anbieter, die für Kundendatensätze einen Alias/interne ID an den Shop/SaaS-Betreiber herausgeben. Darauf kann man dann Folgetransaktionen abzuwickeln. Viele können dies aber bis heute nicht!
Kurzum, es gibt dutzende von Gateways, ein kleiner Auszug:
- EOS Payment
- Easycash
- ogone
- iPayment
- Heidelpay
- WireCard
- Postbank
- …
Wie man schon sieht, sind die wenigsten selbst Akzeptanzen. Man holt sich also nur einen weiteren Technologiedienstleister in die Transaktionskette und sollte daher genau schauen, was für eine Schnittstelle angeboten wird. Nach anfänglicher Skepsis bin ich von WireCard sehr angetan: Sales lieferte sofort Zahlen/Preise und nervte weder per Telefon noch mit 10 verschiedenen inhaltsleere Image-PDFs wie es andere tun. Ausserdem ist WireCard selbst Akzeptanz.
Fazit:
Man suche sich ein Unternehmen, das sowohl Aquirer (Akzeptanz) als auch Payment Gateway Provider ist. Dort bekommt man alles aus einer Hand und sie sind besonders stark durch die Kreditkartenfirmen eingebunden. Entscheidungsgrundlage sind neben den Konditionen insbesondere die passenden Schnittstellen fürs Geschäftsmodell. So sind aus eigener Erfahrung die Schnittstellen von EOS-Payment und Easycash (Letzte API Änderung: 2005!!) indiskutabel schlecht und wenig verbreitet => hoher Integrationsaufwand und mangelhafte Features.
Nun, auch die angebotenen Dienste der Gateways reichen mir nicht ohne weiteres für wiederkehrende Abrechnungen aus. Ich müsste dies, sofern kein SDK existiert, selbst entwickeln. Aber eigentlich habe ich besseres zutun: Mein eigenes Produkt und nicht eine komplizierte Paymentanbindung.
Hierfür gibt es also noch eine dritte Kategorie, die “Veredler”:
c) Recurring Billing Provider (Merchant Service Provider)
Diese sind bis jetzt noch ausnahmslos in den USA angesiedelt, da mal wieder keiner in Europa sieht, was für eine Scheisse die meisten Schnittstellen doch sind: “Nehmen Sie doch Magento, Oxid und OScommerce!11 hurrdurr.”
Diese Recurring-Billing-Provider sind PCI DSS zertifiziert und arbeiten jeweils mit mehreren Payment Gateway Providern zusammen, hauptsächlich mit us-amerikanischen.
Im Idealfall könnte man den Aquirer austauschen ohne etwas in der Anwendung zu ändern.
- Chargify.com (Europa-Kunden nur über UK, KEINE EURO UNTERSTÜTZUNG)
- recurly.com (Europa-Kunden über WireCard, cybersource (UK))
- spreedly.com (Europa-Kunden über ogone)
- Cheddargetter.com (vollständig unklare und intransparente Situation, auf Nachfrage geht alles => development on demand? … )
Als Europa-Kunden bezeichne ich den Unternehmensstandort, also in meinem Falle Deutschland. Natürlich kann man damit weltweit verkaufen bzw. abrechnen.
Alle haben aktiv gewartet Schnittstellen für Ruby. Chargify und Recurly sind m.W. selbst Rails-Apps. Auch gibt es für Endkunden ein Self-Service-Interface mit Zahlungshistorie etc.
Round about ist mit circa 45-80€ monatlichen Grundgebühren (Akzeptanz, Payment Provider Gateway, Recuring Billing Provider) und ca. 150€ Setupgebühren zu rechnen. Pro Transaktion dann 40-50ct + 3.5% – all inclusive.
In den USA gibts auch noch einen super Weg die Akzeptanzkosten zu senken:
transfs.com erlaubt das Ausschreiben des eigenen Bedarfs in einer Art Reverse-Auktion. Akzeptanzen können dann Konditionsangebote abgeben und man darauf den günstigstens Anbieter auswählen. Auch kann die Unterstützung von bestimmten Payment Gateway Providern/Recurring Billing Providern als Kriterium angegeben werden. Ist auch eine Rails-App. Leider, wie gesagt, US Only.
Comments powered by Disqus