- Die Struktur, die die tatsächliche Kartennummer verbirgt, ist kein exklusives Feature von Apple Pay, sondern ein Zahlungsverfahren, das auch in großen digitalen Wallets wie Google Pay und Samsung Pay verwendet wird
- Der Kern ist die Trennung zwischen der physischen Kartennummer FPAN und der gerätespezifischen Zahlungsnummer DPAN; selbst bei derselben Karte werden auf iPhone und iPad unterschiedliche DPANs verwendet
- DPAN kann das Tracking über verschiedene Händler hinweg erschweren, bleibt aber bei Folgezahlungen innerhalb desselben Händlers erhalten und verhindert daher nicht die Nachverfolgung der Kaufhistorie bei einem einzelnen Händler
- Bei einem Leak von Zahlungsdaten ist DPAN sicherer als FPAN; DPAN funktioniert nur, wenn es zusammen mit einem einzigartigen kryptografischen Bundle eingereicht wird, das jeder Transaktion beigefügt ist
- Apple Pay verbirgt personenbezogene Daten wie Name, E-Mail, Rechnungs- und Lieferadresse oder gekaufte Produkte nicht automatisch; man sollte davon ausgehen, dass die im Zahlungsbildschirm angezeigten Informationen an den Händler weitergegeben werden
DPAN ist keine exklusive Apple-Pay-Funktion
- Wenn gesagt wird, Apple Pay verberge die echte Kreditkartennummer, dann ist der Schlüssel DPAN
- FPAN ist die 15- bis 18-stellige funding primary account number, die auf der physischen Karte aufgedruckt ist, und DPAN ist die device primary account number
- DPAN lässt sich ähnlich wie ein DNS-Record verstehen
- Nutzer können eine Website über einen Domainnamen aufrufen, ohne die tatsächliche IP-Adresse zu kennen
- Selbst bei derselben Karte erhält jedes Gerät eine eigene Nummer, wenn Apple Pay auf iPhone und iPad genutzt wird; es werden also unterschiedliche DPANs verwendet
- Schon der Name zeigt, dass es nicht „Apple Pay number“ heißt
- Google Pay und Samsung Pay verbergen als große digitale Wallets in den USA die echte Kartennummer auf dieselbe Weise
- Auch die Buttons von Amazon Pay und Shop Pay sorgen dafür, dass Zahlungen über andere Unternehmen abgewickelt werden; technisch ist das zwar kein DPAN, aber der Händler bekommt die echte FPAN dennoch nicht zu sehen
Auch Händler und Banken wollen die Offenlegung echter Kartennummern reduzieren
- Wenn Händler echte Kreditkartennummern direkt verarbeiten, steigt ihr Risikopotenzial
- Moderne Tools zur Zahlungsannahme sind darauf ausgelegt, Zahlungsdaten so zu erfassen, dass möglichst wenige Personen Zugriff auf echte Karteninformationen haben
- Die Vermutung, Banken würden kein DPAN verwenden, passt nicht zu den tatsächlichen Fällen
- Viele Banken wie Wells Fargo, Chase und Bank of America betreiben oder betrieben eigene digitale Wallets und schützen dabei alle die normalen Kontonummern mit DPAN
- Auch Paze, das von großen US-Banken genutzt wird, verwendet DPAN
- Einer der zentralen Gründe, mit denen Paze wirbt, ist: “Paze does not share your actual card number with the merchant.”
Welches Tracking DPAN verhindert – und welches nicht
- Die Aussage, DPAN ändere sich bei jeder Transaktion, ist nicht korrekt
- Bei fortlaufenden Transaktionen mit demselben Händler wird dieselbe DPAN verwendet
- Diese Struktur kann für Datenbroker, die Transaktionsdaten verschiedener Händler kaufen, um das Einkaufsverhalten einer Person zu analysieren, eine Hürde darstellen
- Umgekehrt kann ein einzelner Händler anhand der von Apple Pay bereitgestellten DPAN weiterhin die Transaktionshistorie dieses Kunden einsehen
- Situationen wie der bekannte Fall, in dem Target auf Basis der eigenen Kaufhistorie Rückschlüsse auf den Zustand von Kunden zog, verhindert Apple Pay nicht
- Andere digitale Wallets haben dieselbe Einschränkung
Schutzwirkung von DPAN bei Datenlecks
- Wenn Zahlungsdaten von Karten offengelegt werden, ist DPAN sicherer als FPAN
- Im Jahr 2024 sollte kein Händler mehr Kreditkartennummern direkt verarbeiten, aber es kann vorkommen, dass ein Payment Gateway gehackt wird und DPAN plus Ablaufdatum offengelegt werden
- Ein Angreifer kann mit einer geleakten DPAN allein keine Zahlung ausführen
- DPAN funktioniert nur, wenn es als Teil eines für jede Transaktion einzigartigen kryptografischen Bundles eingereicht wird
- Es gibt zwar Möglichkeiten, mit über Apple Pay erfassten Karten wiederkehrende Zahlungen auszuführen, aber ein Hacker sollte dazu nicht in der Lage sein
- Deshalb ist ein Leak von FPAN deutlich gefährlicher als ein Leak von DPANs, die von allen digitalen Wallets erfasst werden
Apple Pay verbirgt personenbezogene Daten nicht automatisch
- Die Vorstellung, Apple Pay verschleiere personenbezogene Daten automatisch, entspricht nicht den Tatsachen
- Führt man in einem Test-Händlerkonto eine echte Apple-Pay-Transaktion aus, werden in den Berichten auf Händlerebene Informationen wie Name, E-Mail sowie Rechnungsadresse und Wohnadresse angezeigt
- Für Zahlungen physischer Waren werden Versandinformationen benötigt; daher erlaubt das Apple-Pay-SDK Händlern auszuwählen, welche personenbezogenen Daten sie vom Kunden anfordern
- Produktinformationen werden ebenfalls an Apple Pay übermittelt, damit angezeigt werden kann, was der Käufer erwirbt, und diese Informationen werden ebenfalls an den Händler weitergegeben
- Man sollte davon ausgehen, dass die Informationen, die bei der Zahlung auf der Apple-Pay-Karte angezeigt werden, an den Händler übermittelt werden
- In diesem Punkt unterscheidet sich Apple Pay nicht von anderen Zahlungsarten
- Händler wählen im Checkout aus, welche personenbezogenen Daten sie benötigen oder anfordern möchten
- Andere digitale Wallets funktionieren auf dieselbe Weise
Welchen Schutz digitale Wallets tatsächlich bieten
- Apple Pay ist ein gutes Zahlungsmittel, und Apple hat dazu beigetragen, diese Form digitaler Wallets zu popularisieren
- Die Funktionen von Apple Pay sind in der Branche jedoch nicht einzigartig
- DPAN ist nützlich, um die Nachverfolgung der Käufe einer Person über mehrere Händler hinweg zu erschweren und das Risiko für Kunden bei einem Leak von Zahlungsdaten zu verringern
1 Kommentare
Hacker-News-Kommentare
Ich würde gern in ELI5-Form verstehen, wie Apple Pay und Google Pay tatsächlich funktionieren. Früher dachte ich, dass sie die Karteninformationen einfach an den Händler oder den Zahlungsabwickler weitergeben, und der Originaltext scheint ähnlich zu klingen; ich habe auch gesehen, dass bei Google Pay mit Amex einige Händler die Zahlung ablehnen, anders als bei MasterCard
Manchmal wirkt es so, als würden Apple/Google selbst wie ein Zahlungsabwickler oder sogar als eigene Zahlungsmethode auftreten. Das lag daran, dass sie Transaktionsdaten sammeln und es so aussah, als hätten Supermarktterminals spezielle Unterstützung für die Apple/Google-Pay-Apps gebraucht
Wenn das so ist, frage ich mich, was genau ihr proprietäres Geheimrezept ist und warum es schwierig oder unmöglich ist, sie durch eine Open-Source-Alternative zu ersetzen. Liegt es daran, dass auf iOS/Android nur Apple/Google vollständigen Zugriff auf den NFC-Chip haben?
https://news.ycombinator.com/item?id=39845805
Entscheidend ist die Voreinstellung. Pro Gerät kann es nur eine Standard-Wallet für Visa und Mastercard geben, und im Vorteil ist die Lösung, bei der man vor dem Antippen nicht erst eine App öffnen muss. Google Pay hat einen großen Vorteil gegenüber der HCE-Wallet einer einzelnen ausgebenden Bank, weil es Karten vieler Banken unterstützt
Apple/Google greifen vermittelnd ein, wenn eine neue Karte auf einem bestimmten Gerät registriert wird, sind aber nicht Teil des eigentlichen POS-Transaktionsablaufs
Der Händler muss weiterhin die zugrunde liegende Kartenmarke akzeptieren. Modernes Google Pay und Apple Pay sind keine Proxy-Karten, die die Kartenmarke austauschen, und unterscheiden sich damit von Diensten wie Curve
Offline-Terminals benötigen keine gesonderte Unterstützung. Solange das Terminal keinen Bug hat, funktioniert es überall dort, wo das zugrunde liegende Kartensystem akzeptiert wird. Das physische und logische Protokoll ist dasselbe wie bei Plastikkarten, und aus Sicht des Terminals ist es kaum zu unterscheiden
Im Web ist es anders. Onlineshop und Zahlungsdienstleister müssen es ausdrücklich unterstützen
Deshalb haben drahtlose Terminals Apple Pay und Google Pay meist einfach akzeptiert, ohne dass viel spezielle Unterstützung nötig war. Eine der Änderungen war meiner Erinnerung nach, dass für solche Geräte höhere Zahlungslimits als für kontaktlose Karten galten, weil sie als sicherer angesehen wurden
Warum eine Open-Source-Implementierung schwierig ist: EMV ist komplex in der Umsetzung und erfordert viele Tests und Validierungen mit Spezialgeräten. Das Gerät braucht einen sicheren Bereich, um private Schlüssel sicher zu speichern, und die App muss überprüfen können, dass biometrische Authentifizierung oder eine PIN-Entsperrung verwendet wurde, um die Sicherheit des Nutzers zu gewährleisten
Außerdem muss der Einrichtungsprozess mit den Backends der kartenausgebenden Banken integriert werden, um die nötigen Schlüssel und Informationen zu erhalten. Auch eine Open-Source-Implementierung müsste wahrscheinlich Verträge mit Banken schließen und eine Laborvalidierung über Stellen wie UL durchlaufen
Apple Pay, Google Pay und von Banken bereitgestellte Zahlungs-Apps bestätigen per Biometrie die Zustimmung des Karteninhabers und machen manche Zahlungen dadurch zu Transaktionen „mit Karteninhaber“
Deshalb werden einige Arten von Chargebacks sofort abgelehnt, und bei anderen sinken die Anforderungen an Händlernachweise
Das ist Teil der Standards der Kartennetzwerke; wer sich dafür interessiert, kann es auf https://www.emvco.com/ nachlesen
Dass es keine Open-Source-Option gibt, liegt daran, dass die Sicherheit der Implementierung zertifiziert werden muss und man dafür ein kommerzielles Unternehmen braucht, das mit Banken zusammenarbeitet. Außerdem müsste man sich mit sehr vielen Banken einzeln integrieren
Eine End-to-End-Transaktion, die alle Kartensysteme, alle Zahlungsarten und alle Geräte korrekt abdeckt, zum Laufen zu bringen, ist ziemlich knifflig. Jedes Kartensystem hat unterschiedliche unterstützte Parameter für den „Payment Kernel“ und unterschiedliche Zertifizierungsanforderungen
Oder es ist der Versuch, Transaktionsgebühren zu sparen. Amex ist für Händler in der Regel deutlich teurer
https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...
Als Apple Pay erstmals breite Verbreitung fand, habe ich es auf Basis meiner Erfahrungen mit der Abwicklung von Zahlungen im Einzelhandel ziemlich genau untersucht. Am beeindruckendsten war damals, wie tief es in Branchenstandards verwurzelt war.
Nichts nach der Funkübertragung war Apple-spezifisch, und nach allem, was in diesem Artikel steht, scheint das bis heute so geblieben zu sein.
Ich erinnere mich, dass einige Händler, die kartenbasiertes Tap-to-Pay bewusst akzeptierten, unbeabsichtigt auch das sehr standardkonforme Apple Tap-to-Pay akzeptierten und deshalb ihre Systeme ändern mussten. Besonders CVS fällt mir dazu ein; sie waren wohl Teil eines konkurrierenden Zahlungssystems und wollten die Verfügbarkeit dieses Systems im Laden offenbar als Abgrenzung zu Apple Pay nutzen.
Als sich kürzlich der Mythos verbreitete, „das geht nur mit Apple Pay“, habe ich mich gefragt, ob sich seit meiner letzten Beschäftigung damit etwas geändert hatte. Deshalb freue ich mich, dass der Autor den aktuellen Stand in genau diesem Kontext noch einmal geprüft hat.
Obwohl es nicht offiziell unterstützt wurde, funktionierte Apple Pay überall in Australien, was mich ziemlich überrascht hat. In den USA unterstützten es damals nur sehr wenige Händler, aber in Australien war es standardbasiert, sodass im Grunde 99 % der POS-Terminals es bereits konnten.
Dazu kam der verwirrende Zustand von Android-Zahlungen. Samsung Pay konnte entweder NFC oder die Emulation von Magnetstreifen bedeuten. Google ist berüchtigt dafür, kein konsistentes Branding hinzubekommen, und zwischen den vielen Iterationen von Wallet und Google Pay ist bis heute schwer zu erkennen, was eigentlich was ist.
Was in solchen Diskussionen fehlt: Transaktionen mit Wallets wie Apple Pay, Google Pay und Samsung Pay sind inzwischen genauso nachverfolgbar wie Transaktionen mit der zugrunde liegenden Kartennummer.
Die DPAN ist zwar für ein bestimmtes Gerät eindeutig, aber Zahlungsdienstleister von Händlern können heute in der Autorisierungsantwort des Kartennetzwerks einen eindeutigen Bezeichner namens PAR erhalten. Dieser Bezeichner ist über alle DPANs derselben Karte hinweg identisch und soll im Idealfall sogar bestehen bleiben, wenn sich die Kartennummer ändert, solange dasselbe Basiskonto dahintersteht.
Mit dem PAR kann ein Händler keine Zahlung belasten, daher ist es kein Sicherheitsproblem. Man sollte aber nicht erwarten, dass Zahlungen mit digitalen Wallets privater sind als normale Karten- oder Kartennummernzahlungen.
https://wcapra.com/payment-account-reference-capraplus-your-...
https://www.securetechalliance.org/wp-content/uploads/EMVCo-...
Dem Artikel von Matt Birchler wurde ein Absatz hinzugefügt: „In einer früheren Version hatte ich geschrieben, dass sich die DPAN je nach Händler ändert, aber das war ein Fehler. Das war mein Fehler, weil ich zu hastig geschrieben habe.“ Dennoch wirkt der Rest des Artikels weiterhin so, als gäbe es händlerspezifisch eindeutige DPANs, und ich kann dafür keine Grundlage finden.
Auch Apples eigene Dokumentation https://support.apple.com/en-us/HT203027 sagt, dass die DPAN — dort als Device Account Number bezeichnet — nur pro Gerät eindeutig ist. Wenn eine Karte zu Apple Pay hinzugefügt wird, wird die DPAN dieses Geräts erzeugt, und sie ändert sich danach nicht mehr, es sei denn, man entfernt die Karte und fügt sie erneut hinzu.
Wenn man also dieselbe Karte auf zwei Geräten wie iPhone und Apple Watch verwendet, unterscheiden sich die DPANs und das erschwert die Nachverfolgung. Nutzt man dieselbe Karte auf demselben Gerät jedoch bei mehreren Händlern, würde ich davon ausgehen, dass Datenbroker das nachverfolgen können.
Ich verstehe nicht, warum SSO und mobile Zahlungen keine standardisierte Schnittstelle sind, über die jeder einen Anbieter bereitstellen kann. Sollte es nicht statt „Login mit Google“ oder „Login mit Apple“ eher „Mit meinem bevorzugten SSO-Anbieter anmelden“ geben? Dasselbe gilt für „Mit meinem bevorzugten Zahlungsanbieter bezahlen“.
Noch schlimmer ist, dass Anbieter oder Websites oft nur einige dieser Anbieter unterstützen, sodass SSO de facto kein echtes SSO mehr ist.
Es gibt sicher Gründe dafür, aber ich habe mich nicht näher damit beschäftigt. Es wirkt so, als müsste es eine gemeinsame, von allen Anbietern befolgte Spezifikation geben, und falls nicht, wird das irgendwann vermutlich gesetzlich erzwungen werden.
Der Standard existiert also bereits, und theoretisch könnte man in ein Login-Formular eine E-Mail-Adresse eingeben oder sie vom Browser automatisch ausfüllen lassen, woraufhin ein OAuth-Login für diese Domain folgt, und falls der Server zum ersten Mal mit dieser Domain kommuniziert, könnte er den Client sogar spontan registrieren. Ich habe das in der Praxis noch nie gesehen, aber es wäre schön.
[0] https://datatracker.ietf.org/doc/html/rfc7591
[1] https://datatracker.ietf.org/doc/html/rfc8414
Statt Dienste bereitzustellen und dafür eine faire Gebühr zu verlangen, ist man dazu übergegangen, Nutzer zuzuspammen oder Daten zu sammeln, um sie später noch mehr zuzuspammen.
Offene Standards sind nicht das, was die heutigen Anbieter wollen. Denn dann könnten Nutzer leicht zu anderen Alternativen wechseln und wären nicht länger „engagiert“.
Interessanterweise wurde Apple Pay eingeführt, nachdem große australische Banken jahrelang stark auf mehr kontaktloses Bezahlen hingearbeitet hatten. Als Apple dann dazukam und US-typische Gebühren verlangte, war die Infrastruktur also bereits von den Banken selbst aufgebaut worden.
Australiens Großbanken haben sich jahrelang gegen die Unterstützung von Apple Pay gewehrt, mussten aber am Ende nachgeben, weil der Druck der Kunden zu groß wurde.
Noch heute sind alle darüber sehr verärgert, und wenn Regulierungsbehörden die Öffnung des NFC-Chips erzwingen, werden sie Apple Pay sofort fallen lassen. Bisher war es jedoch schwer, jemanden zu finden, der mit dem Jammern der größten inländischen Banken mitfühlt.
https://www.accc.gov.au/media-release/accc-denies-authorisat...
Kanadische Banken versuchten unter Android ebenfalls eigene kontaktlose Bezahllösungen wie TD Pay, aber niemand wollte sie. Am Ende gaben sie auf und boten Google Pay an.
Ich denke, es wird ähnlich laufen. Selbst wenn Apple NFC-Zahlungen öffnet, wird niemand die Banking-App nutzen wollen, sondern lieber First-Party-Unterstützung wie Apple Pay oder Google Pay bevorzugen.
Man muss sich nur ansehen, wie viele Leute tatsächlich Samsung Pay statt Google Pay nutzen.
Einige Händler wie CVS schalteten Tap-Zahlungen ab, als Apple Pay eingeführt wurde.
Ich frage mich, ob der Teil „Händler können beim Checkout so viele personenbezogene Daten anfordern, wie sie benötigen, und Apple Pay verhindert das nicht“ auch beim Einkaufen im Laden gilt.
Um im Supermarkt Eier zu kaufen, braucht niemand meinen Namen und meine Adresse. Verlangen Apple/Google eindeutig meine Zustimmung, wenn sie Informationen teilen, die offensichtlich nicht nötig sind? Oder ist das wie bei AGB oder einer Shrink-Wrap-EULA nach dem Prinzip „Friss oder stirb“?
Ich habe solche Zahlungssysteme noch nie verwendet.
Die im Artikel erwähnten zusätzlichen Informationen werden nur bei „Online“-Zahlungen weitergegeben. Dazu zählen aber auch Fälle, in denen man mit dem Handy einen QR-Code scannt und dann in Safari oder einem App Clip bezahlt, was ich inzwischen in einigen Restaurants gesehen habe.
Dann bekommt das Restaurant so viele Informationen, wie es angefordert hat. Dazu können Name, Adresse und E-Mail-Adresse gehören. Vermutlich wird das normalerweise im Zahlungssheet angezeigt, aber als ich es zum ersten Mal in einem Restaurant benutzt habe, habe ich das nicht richtig wahrgenommen.
Inzwischen bitte ich den Kellner darum, das eigentliche Terminal zu bringen, damit ich antippen kann, oder ich gebe einfach die physische Karte.
Ein wenig am Thema vorbei, aber ich verstehe immer noch nicht, warum Apple Pay den aktuell zu zahlenden Betrag nicht vor der Transaktionsfreigabe auf dem Bildschirm anzeigen kann.
Das scheint kein UX-Problem zu sein, sondern eher so, als würde das Apple-Gerät den Betrag überhaupt nicht kennen. Woran liegt das?
Es hat bei mir etwas gedauert, das zu verstehen. Ich konnte nicht nachvollziehen, wie Apple Pay im Flugmodus funktioniert, aber natürlich funktioniert es. Eine normale Visa-Karte funktioniert schließlich auch ohne Internetverbindung.
Im Grunde ist beides dasselbe. Wenn sich alle an den Standard halten, gibt es genau deshalb auch nichts zusätzlich zu „unterstützen“. Siehe den Schwesterkommentar von jjcm: https://news.ycombinator.com/item?id=39846117
Deshalb gehe ich davon aus, dass das NFC-Lesegerät den Zahlungsbetrag nicht „sendet“. Eine Plastikkarte hatte nie eine Möglichkeit, diese Information zu verarbeiten, und auch das iPhone hat keine Möglichkeit, diese Information zu empfangen und zu sagen: „Moment, warte, bis der Nutzer per Wischgeste bestätigt.“
Ich weiß nicht, wo Gruber gesagt haben soll: „Das macht nur Apple Pay.“ Der Autor scheint auf ein paar Fehler oder ungenaue Details bei Gruber hinzuweisen, und es wirkt so, als wäre das schon alles.
[Update: Verdammt, ich lag falsch. Matt Birchler, der in der Zahlungsbranche arbeitet, hat die Funktionsweise gut erklärt, und es stellte sich heraus, dass große Banken und Kreditkartenunternehmen bei Tap-to-Pay-Transaktionen händlerspezifische „DPAN“-Nummern erzeugen. Dennoch bleibe ich bei meiner Behauptung, dass Apple Wallet mindestens genauso sicher oder sicherer ist als jede digitale Zahlungs-App eines Kartenausgebers.]
Das ist der Beitrag des ursprünglichen Autors Gruber.
Gruber hat seinen Fehler ebenfalls eingeräumt.
Gruber ist ein offener Apple-Fan, aber normalerweise lag er bei den Fakten meist richtig, gab zu, was er nicht wusste, und verlinkte Experten auf dem jeweiligen Gebiet.
Seit den Apple-Maßnahmen im Zuge des EU-DMA scheint er jedoch jegliche Objektivität verloren zu haben. Er tut so, als würde er den Gesetzestext besser verstehen als die EC, wendet einen US-amerikanischen Ansatz auf eine sehr andere europäische Gesetzgebungspraxis an und übernimmt Apples böswillige Aussagen einfach ungeprüft.
Diese Veränderung fällt mit Apples merkwürdig feindseliger Haltung gegenüber der EU zusammen, daher könnte das Grundproblem sein, dass Gruber Apple zu sehr vertraut.
Diese Haltung scheint er auch bei der Antitrust-Klage der US-Regierung beizubehalten.
Fairerweise muss man sagen, dass die sozialen Medien voller Apple-Anhänger sind, die sich als Rechtsexperten ausgeben und bei fast allem falschliegen, sodass es für ihn schwierig sein könnte, legitime Gegenpositionen zu sehen.
Zu der Aussage „Apple hat großartige Arbeit dabei geleistet, solche digitalen Wallets populär zu machen, aber was sie tun, ist in der Branche nicht einzigartig“: Ich erinnere mich vielleicht falsch, aber ich glaube, als Apple Pay neu war, war es ziemlich einzigartig. Deshalb gab es auch so wenige Orte, die es unterstützten.
Andere mobile Bezahlsysteme, etwa frühe Versionen von Samsung Pay, schienen die Kartennummer unverändert an das Terminal zu senden.
Interessanterweise scheint es im Vereinigten Königreich noch immer ein £100-Limit zu geben, während ich in den USA mit kontaktlosen Android-Zahlungen schon Beträge von über 2000 $ bezahlt habe.
Vielleicht wurde sie nur direkt an die Bank geschickt und der Händler bekam sie nicht zu sehen, aber es war trotzdem die echte Nummer. Das erste Mal, dass ich von DPAN gehört habe, war bei Apple.
Die USA liegen bei Kartenzahlungstechnologie aus verschiedenen Gründen stark zurück. Als ich in Polen mit einer Karte zu Besuch war, die im Rest der Welt schon seit Jahren verwendet wurde, musste ich erst besondere Umgehungstricks lernen, damit der Kassierer die Zahlung überhaupt annehmen konnte.