WooCommerce Redsys Gateway 32.1.x

Die Entwicklung dieser Version hat 2.300 Euro gekostet. Die kumulierten Kosten für dieses Jahr betragen 37.430 Euro. Die kumulierten Kosten seit der ersten Version betragen 236.160 Euro, aber die Kosten für dich sind nur die Lizenz von 79€.

Neue Version 32.1.x des Redsys-Plugins für WooCommerce von WooCommerce.com.

Versionen des Branches

• 32.1.0

32.1.0

Neu:

• Der WooCommerce-Statusbericht (WooCommerce – Status) listet jetzt auch auf, was im Tab “Erweiterte Einstellungen” von Redsys aktiviert ist: Push-Benachrichtigungen, fortlaufende Rechnungen, QR-Codes, gespeicherte Karten, Überschreibung von Bestellstatus, bedingte Regeln, Abonnements, E-Mail-Abstimmung, Agentenhandelsprotokolle und die API der Verwaltungs-App. Die Anmeldedaten werden niemals angezeigt: es wird nur angegeben, ob sie konfiguriert sind oder nicht. Sie werden beim Kopieren des Berichts zur Unterstützung mitgesendet, was genau das Ziel ist: eine Supportanfrage kommt bereits mit der Konfiguration.
• Du kannst jetzt entscheiden, ob deinen Kunden die Option “Eine Kreditkarte für Abonnements hinzufügen” in Mein Konto – Zahlungsmethoden angeboten wird. Bisher erschien diese Option allein, sobald ein aktives Abonnement-Plugin vorhanden war, ohne Möglichkeit, sie zu entfernen, und das ist nicht das, was jeder Shop möchte: In einem Shop, in dem die Abonnementkarte immer beim Kauf erfasst wird, war es nur eine Einladung für den Kunden, eine Karte zu speichern, die niemals belastet werden würde. Der neue Schalter befindet sich in Redsys – Erweiterte Einstellungen – Gespeicherte Karten, ist aktiviert, damit sich in den Shops, die es bereits angeboten haben, nichts ändert, und wenn du ihn deaktivierst, bleibt nur die 1-Klick-Karte. Auch im WooCommerce-Statusbericht wird darüber informiert.

Sicherheit:

• Das Plugin schrieb in seine eigene Protokolldatei die Adresse der “Bestellung erhalten”-Seite jeder Bestellung, bei allen Zahlungen, und diese Adresse enthält den Bestellschlüssel: das private Token, das WooCommerce im Zahlungslink des Käufers setzt und das dieses Plugin verlangt, bevor eine Bestellung angezeigt wird. Jeder, der Lesezugriff auf die Protokolldatei hatte, konnte daher diese Bestellungen öffnen und den Namen, die E-Mail, die Telefonnummer und die Adressen einsehen, die sie enthielten. Dies geschah unabhängig davon, ob das Debug-Protokoll im Shop aktiviert war oder nicht, da dieser spezifische Punkt ohne Überprüfung dieser Einstellung ins Log schrieb. Jetzt respektiert es die Debug-Einstellung wie die anderen Protokolle, die das Plugin schreibt, und der Schlüssel wird durch “[redacted]” ersetzt, bevor irgendetwas geschrieben wird, sodass er nicht einmal mit aktiviertem Log aufgezeichnet wird. Diese Ersetzung wurde anschließend auf alle Protokollzeilen des Plugins angewendet, und nicht nur auf die, die gemeldet wurde: etwa neunzig weitere Zeilen in den Gateways druckten diese Adressen immer, wenn das Debug-Protokoll aktiv war, einschließlich derjenigen, die die vollständige Nachricht an die Bank übermittelten. Bereits geschriebene Protokolldateien enthalten weiterhin diese Adressen: Wenn du sie hast, lösche sie.
• Die Seite, die den Käufer zu Redsys (und Bizum) weiterleitet, akzeptierte jede Bestellnummer, die in ihrer Adresse geschrieben wurde, ohne zu überprüfen, ob derjenige, der sie anforderte, auch die Bestellung aufgegeben hat. Da die Bestellnummern fortlaufend sind, konnte jemand sie durchgehen und die Daten, die das Plugin an die Bank für die Bestellungen anderer Kunden sendet, lesen: Name, E-Mail, Telefon und die Rechnungs- und Versandadressen, zusammen mit dem Betrag und der Beschreibung des Gekauften. Zu keinem Zeitpunkt wurde eine Kartennummer, ein Sicherheitscode oder ein Signaturschlüssel offengelegt, und auf diesem Weg konnte nichts bezahlt oder geändert werden. Diese Seite verlangt jetzt den Bestellschlüssel, den WooCommerce im Zahlungslink des Käufers selbst einfügt, sodass eine Anfrage, die nicht zur Bestellung gehört, mit einer Seite “Forbidden” beantwortet wird, anstatt bearbeitet zu werden. Dieselbe Überprüfung wurde zum Zahlungs-Popup der Checkout-Seite hinzugefügt. Gemeldet vom Sicherheitsteam von Tivify (TVUP Streaming Media), das das Problem klar beschrieben hat und uns Zeit gegeben hat, es zu beheben, bevor es öffentlich gemacht wurde. Danke.
• Die drei Vorautorisierungsschaltflächen auf dem Bestellbildschirm (autorisieren, stornieren und teilweise abbuchen) und die Kundensuche von PayGold akzeptierten ihre Anfragen ohne ein Sicherheitstoken. Die Berechtigungsprüfung war bereits an ihrem Platz, sodass nur ein Shop-Manager oder ein Administrator sie verwenden konnte und niemand sonst sie ausführen konnte, aber ein Administrator mit bereits geöffnetem Sitzung konnte getäuscht werden, um sie von einer anderen Website aus auszulösen, ohne es zu merken. Alle vier tragen jetzt ein Sicherheitstoken von WordPress und überprüfen es, was diesen Weg schließt.
• Das Agentenhandelsprotokoll konnte aktiviert werden, ohne dass jemand es ausgewählt hatte, in Shops, die automatisch aktualisiert werden. Es veröffentlicht Adressen, mit denen Maschinen kommunizieren können, daher ist es so konzipiert, dass es deaktiviert bleibt, es sei denn, du aktivierst es, und jetzt ist es deaktiviert. Wenn du es aktiviert hattest, ändert sich für dich nichts.
• Die im Plugin enthaltene Google-Bibliothek wurde aktualisiert, was zwei Fehler in dem Teil behebt, der Netzwerk-Anfragen durchführt.

Aktualisiert:

• Wenn die Erneuerung eines Abonnements fehlschlägt, sagt die Notiz, die zur Bestellung hinzugefügt wird, jetzt genau, welcher Schritt fehlgeschlagen ist und mit welchem Handels- und Terminalcode der Versuch unternommen wurde. Bisher schrieben die sechs möglichen Fehler die gleiche Notiz, die wenig informativ war, was es fast unmöglich machte, eine fehlgeschlagene Erneuerung ohne Zugriff auf den Shop zu diagnostizieren, insbesondere in Shops, in denen das Debug-Protokoll nicht geschrieben wird.
• Wenn Apple Pay den Shop nicht mit Apple validieren kann, erfasst das Protokoll jetzt die Erklärung von Apple selbst und ob die Zertifikatsdateien lesbar sind. Apple antwortet mit einem generischen “Expectation Failed” und gibt den tatsächlichen Grund im Textkörper seiner Antwort an, der nie protokolliert wurde, sodass diese Fehler eine Sackgasse waren.
• Das verteilte Plugin enthält jetzt keine Entwicklungs- und Build-Skripte des Projekts mehr, die Konfiguration seiner lokalen Testumgebung, seine Editor- und Git-Hook-Verzeichnisse, sein README für Entwickler oder ein internes Sicherheitsüberprüfungsdokument. Nichts davon wurde geladen, wenn das Plugin ausgeführt wurde, aber es hat auch nichts auf dem Server eines Shops zu suchen. Der Inhalt des Pakets wird jetzt automatisch vor jeder Veröffentlichung gegen eine Liste dessen überprüft, was das Plugin tatsächlich verteilt, sodass etwas, das in Zukunft zum Projekt hinzugefügt wird, nicht im Zip reisen kann, ohne dass es jemand bemerkt.
• Die E-Mail-Abstimmungsaufgabe existiert jetzt nur, solange diese Funktion aktiviert ist, und nur einmal. Zuvor wurde sie in allen Shops erstellt und alle fünf Minuten ohne Funktion geweckt.
• Alle Übersetzungen sind wieder vollständig. Neunundsechzig Texte, die durch aktuelle Versionen hinzugefügt wurden, erschienen weiterhin auf Englisch: Einstellungsbeschriftungen, der Statusbericht und einige Nachrichten, die ein Käufer sehen kann. Spanisch, Katalanisch, Baskisch, Galizisch, Französisch und Portugiesisch sind wieder zu hundert Prozent.
• Das Token, das den Link “eine Karte hinzufügen” schützt, wird jetzt in konstanter Zeit verglichen, wie der Rest der Geheimnisse, die dieses Plugin vergleicht. Diese Vergleichszeit über das Internet zu messen, ist kein praktikabler Angriff, sodass es nichts Ausnutzbares gab; der Fehler war die Inkonsistenz, da dies der einzige Vergleich war, der zurückblieb, als die anderen während der Arbeit an den Signaturen migriert wurden.

Behoben:

• Mit InSite konnte das Bezahlen mit einer Karte, die der Käufer gespeichert hatte, das Geld abbuchen und dennoch die Bestellung als fehlgeschlagen anzeigen. Wenn die Bank eine solche Zahlung genehmigt, ohne den Käufer zu bitten, dies mit der App seiner Bank zu bestätigen, was bei einer gespeicherten Karte der Fall ist, suchte das Plugin das Ergebnis an der falschen Stelle, fand nichts und behandelte dieses “Nichts” als Ablehnung. Die Belastung war bereits erfolgt, sodass Käufer, denen gesagt wurde, dass die Zahlung fehlgeschlagen sei, ein zweites Mal zahlten und doppelt belastet wurden. Das Ergebnis wird jetzt aus der von der Bank selbst signierten Antwort gelesen, die dieselbe ist, die der Rest der Zahlung verwendet. Dies betraf sowohl den klassischen Checkout als auch den Block-Checkout sowie die Erneuerungen von Abonnements. Gemeldet von zwei Shops mit wenigen Tagen Abstand, einer davon verfolgte es bis zur genauen Zeile. Danke.
• In der Kartenzahlung wurde eine Zahlung mit einer gespeicherten Karte als abgeschlossen betrachtet, nur mit der Autorisierungsnummer, ohne die tatsächliche Antwort der Bank zu überprüfen, die daneben steht. Eine abgelehnte Zahlung, die dennoch etwas in diesem Feld hatte, markierte daher die Bestellung als bezahlt, und der Shop versendete die Ware, ohne sie belastet zu haben. Jetzt wird verlangt, dass beide übereinstimmen, bevor eine Bestellung abgeschlossen wird. Wenn die Antwort der Bank vollständig fehlt, wird die Zahlung nicht abgeschlossen, da nichts darauf hinweist, dass sie genehmigt wurde; ein Shop, dessen Bank dieses Feld tatsächlich weglässt, kann absichtlich das vorherige Verhalten mit dem dokumentierten Filter redsys_allow_payment_without_ds_response wiederherstellen, der nicht verwendet werden kann, um eine Zahlung zu akzeptieren, die die Bank abgelehnt hat.
• In Shops, die bestimmte Checkout-Plugins verwenden, darunter Fluid Checkout, wurden alle Zahlungen von Redsys mit dem Fehler SIS0574 abgelehnt. Die Bank verlangt eine kurze Beschreibung des Browsers des Käufers mit jeder Zahlung (seine Sprache, die Größe seines Bildschirms und Ähnliches), die das Plugin über versteckte Felder erfasst, die es dem Checkout hinzufügt. Diese Felder wurden hinzugefügt, als die Kartenzahlung erstellt wurde, was in diesen Shops geschieht, nachdem ein anderes Plugin bereits WooCommerce die endgültige Liste der Checkout-Felder angefordert hat, und WooCommerce erstellt diese Liste nur einmal und nie wieder. Die Felder wurden daher nicht erstellt, nicht ausgefüllt und nicht gesendet, und die Bank wies die Zahlung zurück. Jetzt werden sie hinzugefügt, sobald das Plugin geladen wird, bevor jemand die Liste anfordern kann, was alle Gateways betrifft, die sie benötigen, die Kartenzahlung, Bizum und die Wallets, und nicht nur InSite. In InSite wird die Beschreibung des Browsers außerdem jetzt zusammen mit den restlichen Zahlungsdaten übermittelt, anstatt nur von der Bestellung abhängig zu sein, sodass sie einen sich selbst rekonstruierenden Checkout überlebt. Gemeldet von einem Integrator, der bereits die nachgewiesene Diagnose mitbrachte. Danke.
• Wenn eine Zahlung storniert oder abgelehnt wurde, kehrte der Käufer zum Shop zurück, aber die Bestellung blieb ausstehend und der Warenkorb wurde nicht wiederhergestellt. Die Adresse, die das Plugin der Bank gab, um den Käufer zurückzuleiten, war in der Form geschrieben, die für Links innerhalb einer Webseite verwendet wird, nicht in der Form, die für eine echte Adresse verwendet wird, sodass der Shop die Rücksendung ohne die Bestellreferenz, ohne ihre Nummer und ohne ihr Sicherheitstoken erhielt und nichts zu stornieren hatte. Dies betraf Bizum, Google Pay, Apple Pay, Lastschrift, Überweisung, InSite und die Kartenzahlung, solange die Einstellung “Zurück zu” auf “Bestellung stornieren” gesetzt war. In MasterPass wurde dieselbe Adresse direkt leer gesendet, aufgrund eines Schreibfehlers eines einzigen wiederholten Zeichens in drei Zeilen. Alles läuft jetzt über ein einziges Stück gemeinsamen Codes, sodass ein Gateway, das in Zukunft hinzugefügt wird, sich nicht erneut irren kann.
• Im Popup-Zahlungsmodus (modal) führte das Abbrechen einer Zahlung zu nichts, und der Käufer blieb mit der ausstehenden Bestellung im Warenkorb. Die Adresse, an die das Plugin den Browser sendete, wurde auf eine Weise geschrieben, die der Browser als Link innerhalb eines Dokuments interpretiert und nicht als Webadresse, sodass alles, was nach dem ersten Parameter kam, verworfen wurde: die Bestellreferenz, ihre Nummer und ihr Sicherheitstoken verschwanden, und WooCommerce hatte nichts zu stornieren. Der gleiche Fehler betraf die Adresse, an die der Käufer nach der Zahlung zurückgegeben wird, wo ein Trackingparameter stillschweigend verloren ging. Beide sind korrigiert, sowohl bei der Kartenzahlung als auch bei InSite, und das korrigierte Verhalten wurde in einem echten Browser überprüft.
• Der Checkout konnte mit einem kritischen Fehler sterben, anstatt den Käufer zur Bank zu senden, bei einem registrierten Kunden, dessen Kundenkarte seit ihrer Erstellung nie geändert wurde. Das Plugin erstellt ein Sicherheitsdatenpaket für die Bank bei jeder Zahlung, und eines der Felder ist das Datum, an dem das Kundenkonto zuletzt geändert wurde, das WooCommerce in einem Konto, das nie berührt wurde, normalerweise leer lässt, normalerweise eines, das durch einen Import, eine Migration oder automatisch durch ein anderes Plugin erstellt wurde. Das Plugin las dieses leere Datum, als wäre es ein echtes Datum, und die Zahlungsseite stoppte dort. Jetzt greift es auf das Erstellungsdatum des Kontos zurück, was bedeutet, dass es “nie geändert” ist, und derselbe Schutz wurde dem entsprechenden Code hinzugefügt, den die Abonnements verwenden, wo dieses leere Datum stillschweigend an die Bank als “heute geändert” gemeldet wurde, was falsche Informationen für ihre Betrugsprüfungen ist.
• Redsys und die anderen Gateways konnten für alle, einschließlich normaler Käufer, aus dem Checkout verschwinden, in Shops, in denen die Liste “nur diesen Benutzern anzeigen” im Testmodus nie ausgefüllt wurde. Das Plugin las diese leere Einstellung als “zeige es einem Benutzer, dessen ID nichts ist”, was mit niemandem übereinstimmt, sodass die Zahlungsmethode für alle Besucher verborgen blieb. Es betraf nur

• Geschäfte, deren Einstellungen von etwas anderem als dem Einstellungsbildschirm, einem Import, einer Migration oder der API des Plugin-Managements geschrieben worden wären, da das manuelle Speichern dieses Bildschirms einen anderen leeren Wert speichert, der niemals ausgelöst wurde. Korrigiert in den neun Gateways, die denselben Code teilten.
• Die mit Apple Pay oder Google Pay von einem Kunden ohne Konto bezahlten Abonnements erhielten niemals die Genehmigung für wiederkehrende Zahlungen von der Bank, sodass die erste Erneuerung mit einer Notiz fehlschlug, die besagte, dass keine Karte vorhanden sei. Dies geschah in Geschäften, in denen die allgemeine Option „Kunden erlauben, während des Bezahlvorgangs ein Konto zu erstellen“ deaktiviert ist, was in Geschäften, die den Kauf als Gast ermöglichen, üblich ist: Die Zahlungswege der Wallets sahen die Überschreibung, die WooCommerce Subscriptions selbst vornahm, nicht, sodass kein Konto erstellt wurde und ohne Konto die Genehmigung der Bank nicht gespeichert werden konnte. Korrigiert in den vier Standorten, die es verwalten (Apple Pay und Google Pay, sowohl im klassischen Checkout als auch im Block-Checkout).
• Das Zahlungs-Skript des Block-Checkouts war gegen eine Version von React kompiliert, die WordPress selbst nicht akzeptiert. Eine nur für die Entwicklung erforderliche Abhängigkeit brachte eine neuere Version von React in den Build, und WordPress lehnt die von ihm erzeugten Elemente ab, sodass die Zahlungsmethode möglicherweise nicht im Block-Checkout angezeigt wurde. Der Build fixiert jetzt die Version, die WordPress verwendet, und das Skript wurde neu generiert.
• Der Warenkorb und der Checkout konnten für nicht identifizierte Besucher in Geschäften mit gespeicherten Karten oder Abonnements merklich langsam werden. Der interne Helfer WCRed() des Plugins baute jedes Mal, wenn er aufgerufen wurde, eine neue Kopie seines globalen Objekts auf, und dieses Objekt registriert drei WordPress-Hooks zum Zeitpunkt des Aufbaus. WordPress ersetzt diese Hooks nicht, sondern fügt sie hinzu, sodass in einem Geschäft, in dem der Helfer einmal für jede gespeicherte Karte oder jedes Abonnement aufgerufen wird, dieselben drei Überprüfungen Hunderte von Malen registriert wurden und jedes Mal, wenn WooCommerce die Liste der verfügbaren Zahlungsmethoden aufbaute, erneut ausgeführt wurden. In einem Geschäft, das das Problem meldete, kam es zu etwa 438 doppelten Einträgen pro Seitenladung und etwa 1,7 Sekunden PHP-Arbeit auf der Warenkorbseite, von denen nur 56 Millisekunden Datenbankabfragen waren. Der Helfer baut jetzt dieses Objekt nur einmal auf und wiederverwendet es, sodass die Hooks genau einmal pro Anfrage registriert werden. Das Verhalten des Plugins ändert sich dadurch nicht: Das Objekt speichert keine anfragespezifischen Daten. Die gleiche Behandlung eines Objekts pro Anfrage wurde auf den Helfer WCPSD2() angewendet, der identisch war.
• In einem kleinen Teil der Geschäfte wurde der Schlüssel zur Signatur von Handelsagenten (UCP) in einer Form gespeichert, die niemals verwendet werden konnte, sodass jede Signaturüberprüfung gegen ihn fehlschlug und das veröffentlichte Schlüsseldokument nicht dem Standard folgte. Wenn das Plugin diesen Schlüssel erstellte, kam eine seiner beiden Koordinaten von OpenSSL gelegentlich einen Byte kürzer zurück, als der Standard verlangt, etwa in 1 von 135 Geschäften, und das Plugin speicherte ihn unverändert, anstatt ihn aufzufüllen. Von diesem Zeitpunkt an konnte das Geschäft seine eigenen Signaturen nicht überprüfen, noch konnte es ein externer Agent tun, bis der Schlüssel rotiert wurde. Der Schlüssel wird jetzt bis zur geforderten Länge aufgefüllt gespeichert, und ein bereits in der kurzen Form gespeicherter Schlüssel wird automatisch beim ersten Lesen repariert, sodass kein Händler etwas rotieren muss.
• In Geschäften mit PHP 8.0 oder älter führte die Aktivierung der E-Mail-Abstimmung zu einem Serverfehler, anstatt einfach nicht zu funktionieren. Das Plugin überprüft dies jetzt vorher und hinterlässt eine klare Notiz in seinem Protokoll. Die Funktion selbst benötigt weiterhin PHP 8.1.
• Hintergrundaufgaben häuften sich in Dutzenden von Kopien von sich selbst in der Liste der geplanten Aktionen von WooCommerce. Korrigiert in allen Standorten, an denen das Plugin etwas plant, und die bereits vorhandenen Kopien werden automatisch bereinigt.
• Eine Benachrichtigung an die mobile App konnte verloren gehen, ohne einen Fehler anzuzeigen, wenn sie zur falschen Zeit gesendet wurde.
• PHP-Warnungen erschienen im Serverprotokoll bei jedem Besuch der Seite „Bestellung bezahlen“, die von den Gateways von Apple Pay und Google Pay stammten. Für die Käufer war nichts kaputt, aber das Debug-Protokoll dieser Gateways registrierte nichts von diesem Schritt, sodass jeder, der versuchte, ein Problem dort zu diagnostizieren, einen Fehler und nicht eine Stille sah. Gemeldet von einem Händler und in drei Gateways gefunden, anstatt nur dem, das gemeldet wurde. Danke.
• Die Aktivierung des Debug-Protokolls zur Untersuchung eines Problems mit Kreditkartenzahlungen erzeugte Warnungen anstelle der Informationen, für die es aktiviert wurde.
• Der Button „Mit Google verbinden“ in den Einstellungen zur E-Mail-Abstimmung wurde niemals angezeigt. Der Zugriff war bereits möglich, indem die Google-Daten ausgefüllt und auf „Änderungen speichern“ geklickt wurde, sodass dies eine Abkürzung wiederherstellt, aber die Funktion nicht freischaltet.
• Das Plugin sendete an den Shop eine E-Mail mit dem Hinweis „Redsys sendet keine Tokenisierungsfelder“, nachdem Zahlungen, bei denen Redsys jedes einzelne gesendet hatte, getätigt wurden. Die Überprüfung, die hinter dieser Warnung steht, prüfte eine Variable, die im Plugin nirgendwo existiert, und ein Test über etwas, das nicht existiert, ist immer wahr, sodass die Warnung bei jeder Zahlung, die eine Karte speicherte, erschien. Die Händler brachten es zu ihrer Bank, die mit Recht antwortete, dass das Terminal in Ordnung sei. Die Warnung informiert jetzt nur über tatsächliche Abwesenheiten und gibt im Protokoll an, welches Feld fehlte, das Ablaufdatum, die Kartennummer oder die Marke, anstatt nur zu sagen, dass etwas fehlte. Es musste auch aufhören, die Marke zu lesen, nachdem das Plugin sie in einen Anzeigenamen umgewandelt hatte, da diese Umwandlung „Unbekannt“ antwortet, wenn keine Marke vorhanden ist, was die Warnung in eine verwandelt hätte, die niemals erscheinen könnte. Derselbe Block schrieb „unbekannt“ als Kartennummer im Debug-Protokoll bei jeder Zahlung, aufgrund eines Variablennamens mit einem Buchstaben zu viel; jetzt schreibt er die tatsächliche maskierte Nummer.
• Die Suche auf dem Redsys-Token-Bildschirm (WooCommerce – Redsys-Token) nach E-Mail oder Benutzername fand keine gespeicherte Karte ab dem fünfundzwanzigsten. Der Bildschirm forderte die Datenbank nach einer Seite von Tokens an und suchte dann innerhalb dieser Seite, und da sie ohne eine bestimmte Reihenfolge angefordert wurden, war diese Seite immer die fünfundzwanzig ältesten Tokens des Shops, sodass die kürzlich gespeicherten Karten, die die einzigen waren, nach denen jemand suchte, unerreichbar waren. Die Suche erfolgt jetzt in der Datenbank über alle Tokens, und die Liste kommt von neu nach alt. Der Zähler über der Tabelle und die Liste darunter können jetzt nicht mehr abweichen, das Sortieren nach Benutzername oder E-Mail sortiert jetzt die gesamte Tabelle anstelle der sichtbaren Seite, und der Bildschirm lädt jetzt nicht mehr alle Tokens des Shops in den Speicher, nur um sie zu zählen, was in Geschäften mit Tausenden von gespeicherten Karten bei jeder Seitenladung geschah.