Idee: PayTo-URLs

Hi,
mir geistert schon seit längerem eine Idee im Kopf herum, die das Online-Bezahlen deutlich bequemer machen dürfte. Damit es funktioniert, müssten aber möglichst viele Hersteller von Onlinebankingsoftware mitmachen.

Die meisten Betriebssysteme unterstützen beliebige URL-Handler, d.h. man kann ein eigenes Protokoll für Links definieren (das Protokoll ist das vor dem ersten Doppelpunkt). Bei normalen Links ist das immer "http" oder "https", aber einige Programme wie z. B. Internettelefoniesoftware unterstützen andere Protokolle, z. B. "callto" für Anrufe. Klickt man einen solchen Link an, wird das dazugehörige Programm gestartet und bekommt den Link übergeben.

Analog zum callto-Protokoll könnte man, gerade jetzt wo wir europaweit gültige Bankverbindungen (IBAN/BIC) haben, ein payto-Protokoll einführen. Die payto-URLs würden Empfänger (zwingend, IBAN/BIC), Empfängername (optional), Betrag und Währung (optional) und Betreff enthalten.

Wenn sagen wir mal ein Onlineshop nun eine Überweisung von mir will, würde er mir einen Link schicken, z. B. "payto:?iban=DE12345678901234&amount=EUR49.99&subject=Bestellung+1111111". Ich würde ihn anklicken, mein Onlinebanking-Programm würde gestartet, und ich bekäme automatisch einen Entwurf für eine Überweisung mit den entsprechenden Daten angezeigt. Diesen müsste ich ggf. vervollständigen (wenn z. B. bei einem Spendenaufruf kein Betrag angegeben ist) und ganz normal bestätigen und abschicken.

Da es sich um gültige URLs handelt, könnten auch mobile Bankingprogramme, ggf. auch über QR-Codes, über den Standard angesprochen werden.

Leute, die ihre Überweisungen per Webinterface machen, könnten die Daten natürlich weiter manuell eingeben.

Was haltet ihr von der Idee? Lesen hier Entwickler kommerzieller Onlinebankingprogramme mit, die sich vorstellen könnten, so einen Standard gemeinsam zu erarbeiten und umzusetzen?


Gruß
Jan
PS: Wenn man die Idee richtig weit treiben wollte, könnte ein optionaler Parameter eine Ziel-URL für eine Bestätigung sein. Die Bank würde dem Bankingprogramm nach Eingang der Überweisung dann eine digital signierte Bestätigung ausstellen, dass die Überweisung akzeptiert wurde und das Konto gedeckt ist (der Händler also mit seinem Geld rechnen kann), und das Bankingprogramm würde die Bestätigung an die Ziel-URL schicken. Dadurch könnte der Händler direkt sehen, dass das Geld auf dem Weg ist, ähnlich wie bei Giropay.

Das ist kein Problem: (non-standard)-URL-Handler werden (zumindest unter Windows, ich denke aber, andere Betriebssysteme werden das ähnlich handhaben) zentral im Betriebssystem registriert. D.h. das Onlinebankingprogramm, egal welches es ist, setzt einen Eintrag "payto wird von mir behandelt", und jeder Browser/Mailclient/... wird beim Klick auf einen solchen Link das Programm finden.




Die müssten leider weiter abtippen. Technisch wäre es zwar denkbar, dass sie den Link in ein Textfeld auf der Onlinebanking-Website kopieren - das wäre aber aus Sicherheitsaspekten ziemlich schlecht, denn wenn ein Bösewicht den Nutzer überredet, irgendwas in die Adressleiste des Bankingfensters zu kopieren, dann gute Nacht...

Ich denke, das größte Potential für die Mainstreamkunden ergibt sich aus der Möglichkeit, die Payto-URLs als QR-Code an Smartphones zu übergeben. Denn darüber werden immer mehr DAUs ihren Bankverkehr abwickeln, und vermutlich oft auch über entsprechende Apps.



Das ist das praktische an URL-Handlern: Jede Software, die sowas kann, kann sich dafür im System eintragen. Der Browser muss sich nicht drum kümmern, ob ein Hibiscus, StarMoney oder sonstwas am anderen Ende wartet, während das Bankingprogramm nicht wissen muss, woher der Link kommt.




Ja, zusätzliche Felder im URL-String. Wenn du dir das Beispiel anschaust, hast du jetzt schon immer name=wert, getrennt durch "&". Das ist erweiterbar.

Gruß
Jan

Unter Windows schreibt das Programm, welches das Protokoll behandeln will, einen Eintrag in die Registry. Siehe: http://msdn.microsoft.com/en-u…85%29.aspx

Da IE vor Version 9 scheinbar hirntot ist und die URLs kaputtdekodiert, müsste man die Spezifikation des URL-Formats entweder daran anpassen oder man würde die Nutzer defekter Browser ausschließen (das erklärt so einige hässliche Konstrukte die mich verwundert haben). Ist aber auch kein Beinbruch. Im Worstcase kodiert man die Links halt wirklich in b64.

Daraus ergibt sich natürlich das Problem, dass die Mail abgefangen und die Zahlungsdaten manipuliert sein könnten.

Es gibt übrigens einen Hersteller, der deine Idee in Kooperation mit einem Rechnungskauf-Anbieter vor fast einem Jahr realisiert hat. Keine Ahnung, ob ich die Software hier nennen oder für Demonstrationszwecke einen funktionierenden payto-Link posten darf. Damit der Empfänger manipulierte Auftragsdaten erkennen kann, enthält der Link einen Hashwert. Wenn die Prüfsumme nicht stimmt, gibt das Programm eine Warnmeldung aus.

Vom Ablauf her funktioniert das Ganze prima, entbindet den Zahlungspflichtigen trotz allem aber nicht von seiner Aufgabe, die Auftragsdaten zu kontrollieren.

Gruß
Jürgen

Richtig. Zur Kontrolle der Auftragsdaten braucht der Zahlungspflichtige ein Beleg, dem er vertrauen kann. Am besten einen aus Papier. Ich befürchte, ein payto-Link wird den unerfahrenen Nutzer aber eher dazu verleiten, die Auftragsdaten nicht zu kontrollieren. Selbst wenn er einen Papierbeleg hätte. Ist ja alles sicher und so schön bequem. Und genau hier sehe ich das eigentliche Problem. Wenn er die Daten selbst eingeben muss, hat er die erste Kontrolle schon mal hinter sich.

Gruß
Jürgen