Skip to content
< Vorheriger Eintrag | Nächster Eintrag >

Freitag, 3. Januar 2014, 15:58

Unser Shop ab sofort ohne die alte nationale Lastschrift

Wir haben in unserem Shop (aka. Bestellsystem) auf www.manitu.de ab sofort die nationale Lastschrift rausgenommen. In Kürze wird noch eine Eingabeerleichterung für all die, die von SEPA und BIC noch nichts gehört haben, dazu kommen.

Ehrlich gesagt fürchte ich, dass es den ein oder anderen vom Bestellen abhalten könnte. :thinking:

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

NetzBlogR

Aus einer eingegebenen Kontonummer und Bankleitzahl kann man doch per Generator sicherlich eine IBAN erstellen. Gibt es nicht irgendwelche Datenbanken, auf die man zurückgreifen kann, um auch noch die passende BIC dazuzusetzen?

Damit könnte man im Hintergrund mit den "neuen" Daten hantieren, obwohl der Kunde vorne noch seine bekannten Sachen eingegeben hat. Nach einer gewissen Zeit - wenn man sich bei anderen Sachen an die langen Zahlen- und Buchstabenkolonnen gewöhnt hat - kann man ja dann auch umstellen.

Manuel Schmitt (manitu)

So werden wir das in wenigen Tagen tun :-) Also quasi einen Konverter anbieten!

Stefan

Würde mich mal sehr interessieren, auf welcher Basis du die Umwandlung einbaust. Nachdem ich das PDF mit den Umrechnungsregeln und Sonderfällen der Bundesbank gesehen habe, habe ich beschlossen, nur mit den verfügbaren Umrechnungsprogrammen (z.B. SEPA Account Converter oder VR-IBAN-Konverter) zu arbeiten. Aber meines Wissens laufen die zwar unter Wine, sind aber nicht per Kommandozeile nutzbar, also quasi nicht in eine Web-Applikation einbindbar. Deshalb: Wenn du eine Lösung kennst, wäre das ein supercooler Blogpost...!

Björn

Hallo Stefan,

wir haben folgende DLL genutzt, sicherlich kannst du dir da auch ein Commandline-Tool schreiben:

http://subsembly.com/de/sepa-api.html

Gruß

Florian

Wie schon von Floxur erwähnt ist es sehr riskant, sich auf eine solche Bibliothek zu verlassen. Soviele Banken kochen da eigene Suppen mit Prüfziffer, Affixen und Suffixen der Kontonummer. Würde ich wirklich nur mit Bedacht einsetzen.

Stefan

Naja, wenn die Bibliothek gut ist, hält sich sich zu 100% an die offiziellen (und verbindlichen) Vorgaben aus dem Dokument der Bundesbank. Darin sind die Ausnahmeregeln der Banken aufgeführt und erläutert. Mit einer Eigenentwicklung kann man einen so hohen Grad an Korrektheit kaum erreichen. Wenn dennoch vielleicht 0,1% der berechneten IBANs falsch sind und es dadurch zu Aufwand/Kosten für Recherche und Neueinzug kommt, ist das immer noch günstiger, als jeden Kunden einzeln um IBAN und BIC zu fragen. Oder wie von Manuel schon befürchtet: Ein Neukunde, der die Bestellung abbricht, weil er seine IBAN nicht weiß, ist "teurer" als eine fehlerhafte IBAN, die man dann eben nach dem ersten fehlgeschlagenen Einzug korrigiert.

Björn

Da hat du recht, allerdings haben wohl die wenigsten Banken diese Probleme. Bei dem Beispieltool, was du dir darunter laden kannst, solltest du das Bankleitzahlenverzeichnis (http://www.bundesbank.de/Redaktion/DE/Standardartikel/Kerngeschaeftsfelder/Unbarer_Zahlungsverkehr/bankleitzahlen_download.html) referenzieren. In dieser ist definiert, welche Banken Sonderregeln haben. Das Tool sagt auch, ob es die IBAN korrekt erstellen konnte oder nur Best Guess war. Wir hatten vielleicht 1% Best Guess, diese haben wir dann halt nicht automatisch übernommen.
Der Kollege hat sich trotzdem über die anderen 99% gefreut! :)

Stefan

Danke für den Tipp! Ist natürlich unter Linux eine Frickelei mit Mono o.ä. ...

Klaus

Als Alternative zu Subsembly möchte ich insbes. für Linux noch libsepa (https://libsepa.com) erwähnen.
APIs stehen für C, PHP, Perl und Java bereit.

Stefan

Danke für den Tipp! (Das tar.gz ist allerdings in Wirklichkeit nur ein tar. Mein gzip meckerte sehr.)

Floxur

Jein, für die Masse geht das sicher Kontonr und Bankleitzahl eingeben lassen und intern umrechnen. Gibt aber inzwischen (zu viele) Banken mit einer Ausnahmeregel dazu.

Dirk

Es ist ein frommer Wunsch, dass Übergangsphasen auch als solche benutzt werden. An drei Dingen sehe ich das:

1. IPv6: Dass das nötig ist, ist inzwischen wohl jedem klar, allerdings: Welcher Anbieter bietet natives IPv6 und IPv4 als Sonderleistung, die dazugebucht werden muss (ist ja im Regelfall sogar meistens noch umgekehrt)? Und IPv6-Server? Ich sehe schwarz, da es kein endgültiges Datum gibt. Es wäre sicher ein leichtes zu sagen, dass ab dem-und-dem Tag keinerlei IPv4-Traffic mehr geroutet werden wird. Wer bis dahin nicht geupdatet hat, hat eben Pech gehabt

2. Python 3. Seit dem Jahre 2008 besteht inzwischen nun schon die „Übergangsphase“ von Python 2.x zu Python 3. Da Version 2.x nach wie vor noch mit Sicherheitspatches versorgt wird, hat noch KEIN EINZIGES größeres Projekt umgestellt – Warum auch, es gibt kein Datum, ab dem Python 2 nicht mehr versorgt werden wird.

3. Positivbeispiel DVB-T. Es wurde von Anfang an gesagt: Ab dem-und-dem Datum funktioniert analoger terrestrischer Empfang des TV-Programms nicht mehr. Übergangszeit (iirc) 2 Jahre. Basta!

Das wird mit SEPA genau so laufen. Allewelt wird „Übersetzer“ bereitstellen, damit sich niemand seine Daten merken muss (die ja nun bis auf das DE am Anfang, und die Prüfziffer keine echten Unterschiede aufweisen).

So wie wir also in 10 JAhren vermutlich noch immer hauptsächlich IPv4 und Python 2 haben, wird sich der Normalbürger auch nicht mit SEPA auseinandersetzen müssen.

Debe

vServer mit reiner IPv6-Anbindung habe ich schon gesehen - auch tatsächlich preiswert; der Anbieter hat wohl kaum noch IPv4-Adressen. Das nützt mir natürlich nichts, wenn ich eine Webseite für die Allgemeinheit anbieten will, für manche Dienste mag das aber OK sein.

Florian

> So wie wir also in 10 JAhren vermutlich noch immer hauptsächlich IPv4
> und Python 2 haben, wird sich der Normalbürger auch nicht mit SEPA
> auseinandersetzen müssen.
Das ist einfach nicht richtig. Ab 2016 gibt es für niemanden mehr die alte Kontnonummer/BLZ. Jeder Normalbürger muss dann schön IBAN/BIC bei allen Transaktionen benutzen. Und ab 2016 ist die BIC dann afaik auch nicht mehr notwendig (BLZ ist ja ohnehin in der IBAN einkodiert).

Du siehst schon, das ist etwas völlig anderes als IPv6 (tatsächlich aktuell für keinen Normalbürger notwendig), oder Python 2 (was damit noch läuft, läuft halt). SEPA ist verpflichtend, ab 2016 für alle. Da muss sich dann auch jeder Normalbürger mit auseinandersetzen.

Dirk

Ab 2016 wird es auch weiterhin „Übersetzer“ geben, so dass auch weiterhin jeder überall seine bisherige Kontonummer/Bankleitzahl-Kombination eingeben kann. Und ich gehe auch sehr davon aus, dass Leute, die Geschäfte machen wollen, auch weiterhin ihre Kontonummer und ihre Bankleitzahl in den Bestellinformationen angeben (wenn nicht sowieso per Mandat – bzw. Lastschrift – abgebucht wird).

… oder habe ich irgendwas verpasst, vonwegen, dass es verboten wird, etwas anderes als die IBAN (noch mit BIC) im Zahlungsverkehr anzugeben, und entsprechende Übersetzer damit illegal werden?

Ich kenne Leute, die noch heute in D-Mark umrechnen und die seit ~18 Jahren aktuelle Rechtschreibung nicht nur nach wie vor ignorieren, sondern sie auch nach wie vor noch „neue Rechtschreibung“ nennen. Ich glaube nicht, dass vor 2020 auch nur irgendein „Normalbürger“ seine IBAN auswendig kennt.

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Formular-Optionen