Wer mich kennt weiss, dass ich seit über 7 Jahre Debian Nutzer bin und seit 2004 virtualisiere. Zuerst rudimentär mittes linux-vserver.org (aka ctx patch), später dann mittels XEN.
Während fake-Virtualisierungen wie OpenVZ oder Linux-VServer nur den laufenden Linux Kernel in verschiedene Kontexte splitten, bilden XEN, KVM, VMWare und co .native Virtualisierung über die CPU-Erweiterungen oder Paravirtualisierung an.
In vielen Fällen ist die Paravirtualisierung noch die performanteste Wahl: Hier hat die Gast-VM Treiber installiert, die bestimmte Dinge direkt per Software mit dem Virtualisierer lösen, beispielsweise Netzwerkanbindung. Dies hat aber möglicherweise sicherheitstechnisch einen Nachteil und erfordert für jedes Gastsystem eine explizite Unterstützung.
Aber zurück zum Thema:
Früher habe ich gerne für den Host, also in XEN die dom0, wie auch für Gäste (domU) die gleiche Distribution verwendet. Mit der rapiden Weiterentwicklung von kvm und dem ausserhalb der Kernel-Mainline gepflegten XEN wurde es jedoch immer schwerer und aufwändiger: Ich möchte auf dem “host” einfach nicht selbst kernel bauen und upgraden müssen. Der Host sollte quasi so stabil wie möglich sein, mit dem geringst möglichen Overhead. Es sollte eine stabile Updateversorgung über Jahre hinweg geben, die ohne manuelles Paketbauen auskommt.
Bleiben also noch folgende Distributionen übrig:
Ubuntu Server kann für vieles die beste Wahl sein, ich tendiere jedoch trotzdem zu Centos. Die Virtualsierungsabstrahierung, also libvirt, wird von RedHat gepflegt, auch ist Redhat sehr stark in kvm involviert. Somit bin ich relativ frei in der Wahl des Virtualisierers und profitiere von Redhats Enterprise Linux.
Wenn ich etwas an Debian und Ubuntu nicht mag, dann der Umgang mit XEN in den letzten Releases: Ich kann und will nicht einen produktiven Server alle 6 oder 12 Monate neu installieren oder die Virtualisierungslösung wechseln, schliesslich sind davon dutzende VM betroffen. Einfach bei einem neueren Release auf XEN-Support zu verzichten oder nur noch “per Hand” zu Unterstützen ist nicht die richtige Wahl.
TL;DR
Für virtualisierte Systeme in der root-VM/dom0 nur Distributionen einsetzen, die lange supported werden und eher konservativ sind. Auch VMWare ESXi ist eine gute Sache, wenn die Hardware unterstützt wird — ist jedoch nur mit vSphere wirklich nutzbar und das kostet Geld.
Für Gäste-VM kann man dann das Ubuntu, Gentoo, LFS, wasauchimmer einsetzen. patchen und tunen wie man möchte.
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:
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:
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.
Als Euro-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.
Nicht angucken, wenn ihr schwache Nerven habt…Loveparade 2010 Chronologie einer Katastrophe - Teil 4 Massenpanik
Nicht angucken, wenn ihr schwache Nerven habt…Loveparade 2010 Chronologie einer Katastrophe - Teil 3 Massenpanik
O2 ist der letzte Scheissladen. Inkompetentes Personal an jedem Ende. Bei der Produktplanung, bei der Abrechnung und beim Kundendienst.
Ja, ich werde ausfällig. Weil auch der Kundendienst unter aller Sau unhöflich ist!
Der neueste Kracher:
Ich habe mit meinem iPad eine o2 Simkarte bestellt und das O2 Blue genannte Angebot für einen Monat genutzt. Das dafür bereitgestellte Kundenmenü ist nur auf dem iPad aufzurufen, nicht auf einem Desktop.
Auch der überlange Passwort-Vergessen-Link in der Email ist mit Mail.app auf dem iPad nicht anzuklicken und erfordert copy+paste orgien.
Nachdem also die 15 EUR von meinem Konto abgebucht wurden, bekam ich keine Rechnung.
Natürlich nicht auf dem Postweg und auch in keiner digitalen Form. Nichts. Keine Möglichkeit online eine Rechnung einzusehen oder sonstwie einen Beleg zu erhalten.
Also auf dem iPad das Kundenmenü durchgesucht und einen Punkt gefunden auf Anforderung eines Umsatzsteuerbeleges.
Jedoch: Die Seite ist leer. Kein Inhalt, kein Link. Nichts.
Also habe ich via Kundenmenü den Support kontaktiert um bitte mir diesen Beleg zukommen zu lassen.
Und was erhalte ich per Mail?
Einen Link auf ein PDF mit 25 Feldern zum ausfüllen und hinfaxen!
Mit dem iPad?!
Wer hat Euch ins Gehirn geschissen? Das ist jetzt die dritte indiskutable Aktion in diesem Jahr.
Ich werde Euch bei jeder Gelegenheit bekämpfen, Online wie Offline über Eure Produkte, euer mieses, primitives Telefonpersonal, das unter dem Niveau dieses Posting anzusiedeln ist, und eine Bearbeitungszeit von über zwei Wochen für eine schiftliche Kündigung erzählen.
O2 ist also ein Laden voller Versager geworden. Wie Alice.
Beweise:
1. Anmeldebestätigungsmail. Hinweis auf Kundencenter.
2. Ein Versuch mit dem Desktop das Kundenmenü zu erreichen
3. Login via iPad
4. Accountübersicht
5. Leere Seite
Habe dann auf dem iPad über die Kontakt-Möglichkeit den Beleg angefordert.
Mailantwort:
