MevvPos Documentation

Installation

MevvPos benötigt WordPress 6.0+, PHP 8.1+ und WooCommerce 9.0 oder neuer. WooCommerce ist eine harte Abhängigkeit, die im Plugin-Header erklärt ist: Ohne WooCommerce verweigert WordPress die Aktivierung, und auf älteren WordPress-Versionen tut das Plugin einfach nichts.

Laden Sie das Plugin unter Plugins → Installieren → Plugin hochladen hoch und aktivieren Sie es.
Öffnen Sie MevvPos im linken Adminmenü. Es gibt außerdem eine Verknüpfung unter WooCommerce, wo Händler Zahlungseinstellungen zu suchen pflegen.
Schalten Sie im Reiter Allgemein die Zahlungsmethode ein und legen Sie den Titel fest, den die Kundschaft an der Kasse sieht.
Wählen Sie unter Bank-API Ihre Bank und geben Sie die Zugangsdaten ein, die sie Ihnen gegeben hat.
Tragen Sie unter Raten und Provision Ihre Ratensätze ein.
Testen Sie mit den Testzugangsdaten Ihrer Bank, bevor Sie live gehen.

Die kostenlose Edition legt keine Datenbanktabellen an und registriert keine geplante Aufgabe. Alles lebt in WordPress-Optionen und im Bestell-Meta.

Pro ist ein eigenes Plugin, das neben dem kostenlosen installiert wird — kein Ersatz dafür. Das kostenlose Plugin erscheint auf WordPress.org, wo alles Veröffentlichte unter der GPL weiterverbreitet werden darf; hätten wir den bezahlten Quellcode im selben Paket gelassen, wäre er für jeden, der die Lizenzprüfungen löscht, rechtlich weiterverbreitbar gewesen. Der Lizenzschlüssel wird im Reiter Lizenz eingegeben.

Wenn Sie WooCommerce → Einstellungen → Zahlungen → MevvPos öffnen, werden Sie auf den MevvPos-Bildschirm weitergeleitet. Das ist Absicht: Es gibt einen Ort für diese Einstellungen, nicht zwei, die sich widersprechen können.

So funktioniert es

Sie definieren einen oder mehrere POS-Datensätze. Ein POS-Datensatz ist das virtuelle POS einer Bank: ihre Zugangsdaten, ihre Gateway-Adresse, ihre Ratensätze.
An der Kasse gibt der Kunde seine Karte ein. Die ersten sechs Ziffern — die BIN — identifizieren die Bank, die sie ausgegeben hat.
MevvPos schlägt die BIN nach und sendet die Zahlung an Ihr POS bei dieser Bank, sofern Sie eines haben. Andernfalls fällt sie auf Ihr Standard-POS zurück.
Raten werden nur angeboten, wenn die Karte zur eigenen Bank dieses POS gehört, denn Banken gewähren keine Raten auf Karten einer anderen Bank.
Der Kunde durchläuft 3-D Secure bei der Bank, und die Bank kehrt zu einer einzigen Rückrufadresse auf Ihrer Website zurück.
Die Signatur auf dem Rückweg wird mit dem Schlüssel des POS, das die Bestellung tatsächlich benutzt hat, geprüft, die Bestellung wird abgeschlossen und das Ergebnis festgehalten.

Kartennummer, Ablaufdatum und CVV werden nie in Ihre Datenbank oder in die WooCommerce-Sitzung geschrieben. Die einzigen Kartendaten, die aufbewahrt werden, sind die ersten sechs Ziffern und der erkannte Bankname.

POS-Datensätze

Die POS-Leiste sitzt über den Reitern und ist auf jedem von ihnen sichtbar. Jede Karte zeigt die Bank, die Händlernummer und ein Abzeichen, wenn etwas Ihre Aufmerksamkeit braucht.

Standard: Das POS, das die Zahlung übernimmt, wenn keine bessere Übereinstimmung gefunden wird. Es gibt immer genau eines.
Inaktiv: Behalten, aber nicht kassierend. Nutzen Sie das statt des Löschens, wenn ein POS eingerichtet, aber bei der Bank noch nicht live ist — ein Kunde mit einer Karte dieser Bank könnte sonst nicht bezahlen.
Wartet auf eine Lizenz: Der Datensatz existiert, ruht aber, weil die Lizenz nicht aktiv ist. Es wurde nichts gelöscht; er macht dort weiter, wo er aufgehört hat, sobald die Lizenz erneuert wird.
Die API-Daten wurden nicht eingegeben: Der Datensatz hat noch keine Händlernummer.

Banken werden mit einem Farbstreifen statt mit einem Logo dargestellt. Banklogos sind Marken, und fünfzehn davon bedeuten sowohl rechtliches Risiko als auch dauerhafte Pflege — Sie wissen ohnehin, welche Bank Ihre ist.

Das letzte POS kann nicht gelöscht und das letzte aktivierte nicht abgeschaltet werden. Um Kartenzahlungen ganz einzustellen, schalten Sie stattdessen die Zahlungsmethode im Reiter Allgemein aus.

Die kostenlose Edition erlaubt ein POS. Weitere Datensätze sind eine Pro-Fähigkeit — und damit folgerichtig auch das BIN-Routing: Mit einem einzigen POS gibt es nichts, wozwischen geleitet werden könnte.

Bank-API — Zugangsdaten und die Gateway-Adresse

Bank: Wählen Sie die Bank, bei der Ihr POS liegt. Die Gateway-Adresse und die für Raten verwendete BIN-Liste folgen beide dieser Wahl. Institute ohne bisherige Umsetzung sind mit „— yakında“ aufgeführt und können nicht ausgewählt werden.
Händlernummer (Client ID): Die Händlernummer, die die Bank Ihnen gegeben hat.
Merchant key (Store key): Der Sicherheitsschlüssel des Händlers. Wird als Passwortfeld gespeichert; nach dem Speichern wird er maskiert angezeigt.
Gate URL: Die Adresse, an die das Zahlungsformular gesendet wird.
Testmodus einschalten: Stoppt die automatische Weiterleitung, damit Sie die Anfrage prüfen können, bevor sie gesendet wird.

Wenn Sie den Store Key beim Speichern leer lassen, heißt das „nicht ändern“. Den leeren Wert zu schreiben würde den Schlüssel löschen, und Ihr Shop würde ohne eine einzige Fehlermeldung aufhören, Zahlungen anzunehmen. Dieselbe Regel gilt für die anderen Geheimfelder.

Manche Familien brauchen zusätzliche Zugangsdaten, und das Formular zeigt sie nur für die von Ihnen gewählte Bank:

Garanti BBVA — Merchant ID, Autorisierungsbenutzername, Autorisierungspasswort.
VakıfBank — Terminal No und eine MPI-Adresse (leer lassen, um die Testadresse zu verwenden).
PayTR — Merchant Salt.
iyzico, Craftgate, Sipay — keine zusätzlichen Felder: der API-Schlüssel kommt in die Händlernummer und das Geheimnis in den Merchant key.

Diese zusätzlichen Zugangsdaten gehen in die Signatur ein. Fehlt eines, wird die Signatur mit einem leeren Wert berechnet und die Bank lehnt die Zahlung stillschweigend ab — kein Fehler, keine Meldung, nur eine Absage.

Für die sieben NestPay-Banken wird die Gateway-Adresse aus Ihrer Bankwahl gefüllt, Sie können Gate URL also leer lassen. Bei den anderen ist das Feld nicht vorausgefüllt: Tragen Sie die Adresse ein, die Ihre Bank oder Ihr Anbieter Ihnen gegeben hat, sonst hat das Zahlungsformular kein Ziel.

Die dreizehn unterstützten Institute

NestPay / Asseco (Payten): İş Bankası, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat Bankası
Garanti GT3D: Garanti BBVA
PayFlex V4: VakıfBank
Zahlungsinstitute: iyzico, PayTR, Craftgate, Sipay

Institute ohne Umsetzung bleiben absichtlich in der Bankliste, markiert mit „— yakında“. Sie zu entfernen würde verbergen, welche Protokollfamilien noch fehlen. Ist Ihre eine davon, sagen Sie es im Reiter Bankanfrage.

Nur die NestPay-Signatur hat einen Golden-Vector-Test gegen das eigene veröffentlichte Beispiel der Bank. Jeder andere Anbieter ist in seinem eigenen Quellcode als beta markiert: Der Ablauf ist nach der Dokumentation umgesetzt, aber noch nicht Ende zu Ende mit einem echten Händlerkonto bei diesem Institut verifiziert. Diese Kennzeichnung bleibt, bis das geschehen ist.

Zahlungsinstitute geben keine Karten aus, sie führen also keine BIN-Liste. Sie wählen sie als Ihr POS, statt zu ihnen zu routen.

BIN-basiertes Routing

Die ersten sechs Ziffern einer Karte identifizieren die Bank, die sie ausgegeben hat. MevvPos gleicht genau auf diese sechs Ziffern ab.

Eine Momentaufnahme der BIN-Tabelle liegt dem Plugin bei — 1.449 BINs über 36 Banken im aktuellen Build —, sodass das Routing offline funktioniert, in der kostenlosen Edition, vom Moment der Installation an.
Pro aktualisiert sie wöchentlich von unseren Servern. Die Aktualisierung legt sich über die mitgelieferte Tabelle, statt sie zu ersetzen: Eine unvollständige oder leere Antwort darf einen Shop niemals ganz ohne BIN-Daten zurücklassen.
Eine Antwort mit weniger als hundert BINs wird als unplausibel abgelehnt und nicht geschrieben.
Konflikte — dieselbe BIN, die von zwei Banken beansprucht wird — werden auf unserer Seite aufgelöst, bevor die Liste versendet wird. Ein Shop, der sie lokal auflöste, könnte eine Karte gleichzeitig als „unsere“ zählen und woanders hin routen.

Eine unbekannte BIN wird nie abgelehnt. Sie fällt auf Ihr Standard-POS durch. Eine Karte abzuweisen, die wir schlicht nicht erfasst haben, hieße, einen Verkauf zu verlieren, um eine Nachschlagetabelle zu schützen.

Dieselbe Tabelle beantwortet an der Kasse eine zweite, andere Frage: Stammt diese Karte von der eigenen Bank dieses POS? Das entscheidet, ob Raten angeboten werden — siehe unten.

Die Genauigkeit der BINs ist keine kostenpflichtige Funktion. Wofür Pro bezahlt wird, ist Aktualität, nicht Richtigkeit: Die mitgelieferte Liste ist dieselbe Liste, nur zum Build-Zeitpunkt eingefroren.

Raten und Kommission

Die Sätze werden je POS festgelegt, von der Einmalzahlung bis zu zwölf Raten, im Reiter Raten und Provision. Es sind Prozentwerte: Schreiben Sie 5.50 für 5,5 %.

0: Die Option wird angezeigt und es wird keine Kommission aufgeschlagen.
Leer: Die Option wird überhaupt nicht angezeigt. Leer und null sind nicht dasselbe.

Die Kommission erscheint im Warenkorb als steuerpflichtige Gebühr mit dem Namen „N Taksit Komisyonu“, berechnet auf die Warenkorbsumme einschließlich Versand und Steuer.

Raten werden nur auf Karten angeboten, die von der eigenen Bank dieses POS ausgegeben wurden, und das wird auf dem Server durchgesetzt — nicht nur in der Oberfläche versteckt. Eine Karte einer anderen Bank wird auf eine Einmalzahlung zurückgezwungen und die Gebühr wird entfernt.

Die kostenlose Edition zeigt dem Kunden höchstens drei Raten; Pro hebt die Grenze auf zwölf. Die Grenze wird an drei Stellen angewendet: in der Liste, die der Kunde sieht, im Wert, der mit dem Formular ankommt, und im Wert, der an die Bank gesendet wird. Der letzte ist wichtig, weil ein Wert, der bei noch gültiger Lizenz gewählt wurde, in der Sitzung überleben kann.

Das Einstellungsformular zeigt immer alle zwölf Felder, unabhängig von Ihrer Lizenz. Würden sie beim Ablauf einer Lizenz verschwinden, würde das Speichern der Seite stillschweigend Sätze löschen, die Sie bereits eingetragen haben. Felder oberhalb Ihrer Obergrenze sind mit „In Pro freigeschaltet“ markiert, und Ihre Zahlen bleiben erhalten.

Es gibt keine von der Bank gelieferte Ratentabelle. Die Sätze sind die, die Sie eintragen, und die Kommission einer vergangenen Bestellung wird aus dem Satz berechnet, der am Verkaufstag galt — einen Satz heute zu ändern schreibt den gestrigen Bericht nicht um.

Der Zahlungsablauf und der Umgang mit der Karte

Jede Familie durchläuft 3-D Secure. Es gibt keinen Nicht-3D-Modus und keine Einstellung, um ihn abzuschalten.

Formularablauf: NestPay, Garanti, PayTR und Sipay: Der Browser sendet ein signiertes Formular an die Bank, der Kunde authentifiziert sich, und die Bank kehrt zu Ihrer Website zurück.
Serverablauf: VakıfBank, iyzico und Craftgate: Ihr Server spricht mit dem Anbieter, holt die 3-D-Seite, zeigt sie an und schließt den Verkauf nach der Authentifizierung von Server zu Server ab.

Die Bank kehrt immer zu einer Adresse auf Ihrer Website zurück: ?wc-api=mevvpos_callback. Die Signatur dieses Rückwegs wird mit dem Schlüssel des POS geprüft, das die Bestellung tatsächlich benutzt hat und das auf der Bestellung selbst festgehalten ist — bei mehr als einem POS erzeugt eine Prüfung gegen den falschen Schlüssel bei jeder einzelnen Zahlung einen Hash-Fehler.

Die Karte erreicht Ihre Datenbank nie. Sie wird für die Dauer der Weiterleitung im Browser gehalten und danach entfernt. Ist sie beim Laden der Zahlseite nicht da — ein neuer Tab, ein Neuladen, deaktivierter Speicher, ein Zurück von der Bank —, wird ein sichtbares Kartenformular gezeigt, statt leere Felder an die Bank zu senden. Das Kartenformular ist standardmäßig sichtbar, mit Absicht: Ein Zahlungsablauf darf nicht davon abhängen, dass JavaScript gelaufen ist.

Genehmigt die Bank die Zahlung, wird die Bestellung auch dann abgeschlossen, wenn der 3-D-Statuscode unerwartet war — eine Bestellnotiz hält die Auffälligkeit fest und bittet Sie, sie auf dem Bildschirm der Bank zu bestätigen. Sagt die Bank genehmigt, wurde der Kunde belastet; das abzulehnen hieße „Ihre Karte wurde belastet, aber Ihre Bestellung ist fehlgeschlagen“.

Jeder Versuch hält das verwendete POS fest, die Bank und die BIN der Karte, die Ratenzahl und den Satz, das Ergebnis, den Antwortcode und die Meldung der Bank sowie die Autorisierungs- und Transaktionsreferenzen.

Berichte

Der Reiter Berichte zeigt Umsatz, erfolgreiche Transaktionen, die Erfolgsquote und die Aufteilung zwischen Einmalzahlung und Ratenzahlung, mit einem Tagesdiagramm. Transaktionen, die noch auf die Rückmeldung der Bank warten, werden getrennt gezählt und aus der Erfolgsquote herausgehalten.

Die kostenlose Edition berichtet über ein festes Fenster von 30 Tagen. Pro ergänzt Zeiträume von 7 / 30 / 90 Tagen und drei Aufschlüsselungen:

Raten- und Kommissionslast — Anzahl, Umsatz und Kommissionslast je Ratenstufe.
Aufschlüsselung nach POS und Bank — Umsatz, Erfolge, Fehlschläge und Erfolgsquote für jedes POS und für jede ausgebende Bank.
Verteilung der Ablehnungscodes — mit CSV-Export. Ein wiederkehrender Ablehnungscode weist auf etwas hin, das Sie beheben können: Unzureichende Deckung ist das Problem des Kunden, aber Fehler bei der 3-D-Prüfung und in der POS-Konfiguration sind Ihre.

Die Daten hinter den Berichten sammelt das kostenlose Plugin, die Historie wächst also weiter, ob Sie Pro haben oder nicht. Das muss so sein: Vergangene Daten lassen sich beim Upgrade nicht rückwirkend erzeugen.

Ein frisch installierter Shop hat kein Diagramm. Die Aufzeichnung beginnt mit dem Plugin, und der Bildschirm füllt sich nach dem ersten Zahlungsversuch.

Bankanfragen und Support

Bankanfrage: Listet jedes Institut auf, das noch nicht umgesetzt ist, mit dem Grund: Entweder ist die Protokollfamilie nicht bestimmt, oder die Familie ist bekannt und wir warten auf die Dokumentation. Sie können eine Anfrage für eines davon eröffnen oder ein Institut nennen, das überhaupt nicht in der Liste steht.
Support: Ein Betreff, das betroffene POS oder die betroffene Bank, was passiert, wenn Sie was tun, und die Fehlermeldung, die die Bank angezeigt hat.

Das Support-Formular bittet Sie ausdrücklich, keine Kartennummer und keinen Sicherheitscode anzugeben. Sie werden nie gebraucht, um ein Zahlungsproblem zu diagnostizieren, und mit keinem der beiden Formulare werden Zahlungs- oder Kartendaten gesendet.

Das kostenlose Plugin nimmt nur dann Kontakt zu unseren Servern auf, wenn Sie eine dieser Schaltflächen drücken. Es wird nichts nach Zeitplan gesendet, und in der kostenlosen Edition gibt es überhaupt keinen Lizenzabruf.

Free und Pro

Die Aufteilung betrifft die Menge, nicht die Fähigkeit. Alle dreizehn Institute, 3-D Secure, der Testmodus, unbegrenztes Transaktionsvolumen und der einfache Umsatzbericht sind in der kostenlosen Edition enthalten.

Kostenlos: Ein POS. Höchstens drei Raten, die dem Kunden gezeigt werden. Eine feste Umsatzübersicht über 30 Tage. Die dem Plugin beigelegte BIN-Tabelle.
Pro: Unbegrenzte POS-Datensätze — und damit BIN-Routing. Bis zu zwölf Raten. Berichtszeiträume und die Aufschlüsselungen nach POS, Bank, Raten und Ablehnungscode, mit CSV-Export. Wöchentliche Live-Aktualisierung der BINs. Automatische Updates für das Pro-Plugin selbst.

Wenn eine Lizenz abläuft oder fehlt:

Ihr Shop nimmt weiter Zahlungen an. Auf dem Zahlungspfad gibt es nirgends eine Lizenzprüfung. Einem Shop den Umsatz abzudrehen ist keine akzeptable Art, an eine Verlängerung zu erinnern.
Das Standard-POS funktioniert weiter, 3-D Secure und Testmodus inbegriffen.
Zusätzliche POS-Datensätze gehen in den Ruhezustand, werden aber nie gelöscht, Zugangsdaten inbegriffen. Sie nehmen bei der Verlängerung den Betrieb wieder auf.
Die Ratengrenze fällt auf drei zurück. Sätze, die Sie darüber eingetragen haben, bleiben erhalten und werden nicht gelöscht.
Die Berichte fallen auf die 30-Tage-Übersicht zurück. Die gesammelte Historie wird nicht gelöscht.
Die Live-Aktualisierung der BINs hört auf; die beigelegte Tabelle funktioniert weiter.

Sind unsere Server nicht erreichbar, funktioniert eine aktive Lizenz auf Basis der letzten erfolgreichen Prüfung noch sieben Tage weiter. Eine Lizenz, deren eigenes Ablaufdatum vorbei ist, gilt aber trotzdem als abgelaufen — sonst wäre das Blockieren unserer Adresse eine Möglichkeit, eine Lizenz um eine Woche zu verlängern.

Wenn etwas nicht funktioniert

Die Bank lehnt jede Zahlung ohne brauchbare Meldung ab: Fast immer die Signatur. Eine falsche Signatur löst nirgends einen Fehler aus — die Bank lehnt einfach ab. Prüfen Sie die Händlernummer, den Store Key und alle zusätzlichen Zugangsdaten dieser Familie: Sie gehen alle in die Signatur ein. Ein nützlicher Test: Banken beantworten einen Signaturfehler und eine ungültige Karte unterschiedlich; erhalten Sie eine Meldung „ungültige Karte“, stimmt Ihre Signatur.
„Hash-Fehler“ auf dem Rückweg, mit mehr als einem POS: Der Rückweg ist eine eigene Anfrage ohne Sitzung. MevvPos hält fest, welches POS eine Bestellung benutzt hat, und prüft mit diesem Schlüssel. Haben Sie den POS-Datensatz gelöscht, über den eine Bestellung bezahlt wurde, fällt die Prüfung auf das Standard-POS zurück und kann scheitern.
Der Kunde landet auf einer leeren Zahlseite, oder die Öde-Schaltfläche tut nichts: Ein Cache- oder Optimierungs-Plugin verzögert Skripte. Schließen Sie bei LiteSpeed mevvpos, jquery und die WooCommerce-Frontend-Skripte von der Verzögerungsliste aus. Das Kartenformular wird standardmäßig gezeigt, damit der Ablauf trotzdem funktioniert, aber die automatische Weiterleitung nicht.
Die Bestellung bleibt nach einer erfolgreichen Zahlung „ausstehend“: Die Bank oder der Anbieter hat die Rückrufadresse nicht erreicht. Prüfen Sie, ob ?wc-api=mevvpos_callback von außen erreichbar ist — ein Wartungsmodus, eine IP-Beschränkung oder eine Anmeldeschranke vor der Website blockiert sie.
Das Zahlungsformular sendet zurück auf dieselbe Seite: Das Feld Gate URL ist leer, für eine Bank, deren Adresse nicht vorausgefüllt ist. Tragen Sie die Adresse ein, die Ihre Bank oder Ihr Anbieter Ihnen gegeben hat.
Der Testmodus ist an, aber die Zahlung geht trotzdem an die echte Bank: Der Testmodus stoppt die automatische Weiterleitung und zeigt Ihnen die Anfrage; er schreibt für die NestPay-Banken nicht die Gateway-Adresse um. Tragen Sie während des Testens die Testadresse Ihrer Bank in Gate URL ein.
Es erscheinen keine Raten: Entweder ist der Satz für diese Anzahl leer statt null, die Karte stammt von einer anderen Bank, oder Sie liegen über der Grenze von drei in der kostenlosen Edition.
Karten gehen nach einem Upgrade an das falsche POS: Ältere Versionen trugen handgeschriebene BIN-Bereiche, die teilweise falsch waren. Prüfen Sie, ob jedes POS unter der Bank abgelegt ist, bei der es wirklich liegt.
Der Adminbildschirm sieht ungestylt aus, oder eine Korrektur erscheint nicht: Ein veralteter Browser-Cache. Laden Sie die Seite neu und umgehen Sie dabei den Cache.

Grenzen

Die folgende Liste ist Absicht. Nichts davon ist ein Fehler.

Keine Erstattungen oder Stornierungen aus WordPress. Das Plugin setzt die Erstattungs-API von WooCommerce nicht um, und kein Anbieter trägt einen Erstattungsaufruf. Erstatten Sie über den eigenen Bildschirm Ihrer Bank.
Nur türkische Lira. Der Währungscode ist bei jedem Anbieter fest; es gibt keine Einstellung für mehrere Währungen.
Keine gespeicherten Karten, keine Tokenisierung, keine Abonnements oder wiederkehrenden Zahlungen.
Keine Vorautorisierung. Jede Transaktion ist ein direkter Verkauf.
Kein regelbasiertes Routing. Geleitet wird ausschließlich nach ausgebender Bank — nicht nach Betrag, Kartenmarke oder Land.
Das Zahlungsformular ist für die klassische WooCommerce-Kasse geschrieben. Für die blockbasierte Kasse liegt dem Paket keine eigene Komponente bei.
3D Pay Hosting wurde bewusst verworfen. Die gehostete Seite nimmt den PCI-Geltungsbereich weg, aber auch die BIN und die Ratentabelle — und der gesamte Wert dieses Plugins liegt im Routing, das sie erst möglich machen.
Kein BIN-Editor. Die Tabelle wird von uns gepflegt und mit der Live-Aktualisierung zusammengeführt; es gibt keinen Bildschirm, um sie von Hand zu bearbeiten.
Sechsundzwanzig Institute sind gelistet, aber nicht umgesetzt. Sie bleiben sichtbar, damit die Lücke sichtbar bleibt.
Jeder Anbieter außer NestPay ist selbsterklärt beta, bis er Ende zu Ende mit einem echten Händlerkonto verifiziert wurde.
Die Reiter liegen auf der Seite. Die Einträge in der Seitenleiste öffnen den MevvPos-Bildschirm; die Reiter wechseln Sie auf der Seite selbst.

Was in keiner Form gespeichert wird: die Kartennummer, das Ablaufdatum und der Sicherheitscode. Die einzigen Kartendaten, die aufbewahrt werden, sind die ersten sechs Ziffern und die Bank, die sie identifizieren. Den Sicherheitscode zu speichern ist unter allen Umständen verboten, und selbst ein maskierter verrät seine Länge.

Von einem einzigen virtuellen POS zu einer Karte, die an die ausgebende Bank geleitet wird.