MevvPos — Mevvsoft-Dokumentation

Installation

MevvPos benötigt WordPress 6.0+ und PHP 8.1+. WooCommerce ist optional. Ist WooCommerce 9.0 oder neuer aktiv, registriert sich MevvPos selbst als Zahlungsmethode an der Kasse; ohne WooCommerce lädt die Zahlungs-Engine trotzdem und kann von einem anderen Plugin angesteuert werden. Frühere Versionen erklärten WooCommerce zu einer harten Abhängigkeit, und WordPress verweigerte ohne sie die Aktivierung — diese Anforderung ist entfallen.

Beide WooCommerce-Kassenflächen sind abgedeckt. MevvPos registriert sich sowohl für die klassische Shortcode-Kasse als auch für den neueren Checkout-Block. Bis 4.7.1 war nur die klassische Seite angebunden; ein Shop, der zur Block-Kasse wechselte, verlor die Kartenoption vollständig — keine Fehlermeldung, keine Warnung, nur eine fehlende Zahlungsart. Es ist nichts zusätzlich einzustellen: Auf der Blockseite erscheinen Kartenfelder, Ratentabelle und Ratenaufschlag genauso.

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 Ihren Anbieter — ein türkisches Bank-Virtual-POS oder einen der internationalen Anbieter — und geben Sie die Zugangsdaten ein, die Sie erhalten haben.
Falls Sie einen internationalen Anbieter gewählt haben, kopieren Sie die auf demselben Tab angezeigte Webhook-Adresse in das eigene Panel des Anbieters. Ohne sie wird nichts abgeschlossen.
Tragen Sie unter Raten und Provision Ihre Ratensätze ein.
Testen Sie mit den Testzugangsdaten Ihrer Bank, bevor Sie live gehen.

The free plugin creates no database tables and registers no scheduled job. Everything lives in WordPress options and in order 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

MevvPos spricht zwei Arten von Zahlungsprotokoll, und welche Sie bekommen, ergibt sich aus dem gewählten Anbieter. Beide laufen durch dieselbe Engine und erzeugen denselben Bestelldatensatz.

Signiertes Formular — Türkei: Die sieben türkischen Virtual-POS-Familien. MevvPos baut die Zahlungsfelder, signiert sie mit Ihrem Store-Key und sendet sie per POST an die Bank. Der Kunde authentifiziert sich mit 3-D Secure, und die Bank kehrt zu Ihrer Website zurück; die Signatur bei dieser Rückkehr ist es, die die Bestellung abschließt.
Gehostete Seite und Webhook — international: Stripe, PayPal, Mollie, Square, Authorize.Net, Checkout.com, Razorpay und Paystack. MevvPos erzeugt die Zahlung beim Anbieter über dessen REST-API und schickt den Kunden auf die Seite des Anbieters. Abgeschlossen wird die Bestellung durch eine Antwort des Anbieters: die signierte Benachrichtigung, die Ihre Webhook-Adresse erreicht, oder — falls der Kunde vorher zurückkommt — eine Server-zu-Server-Statusabfrage von der Rückkehrseite aus. Was eine Bestellung nie allein abschließt, ist die Rückkehr des Browsers.

Auf der türkischen Seite tut die Engine etwas, das die internationalen Anbieter nie brauchen: Sie entscheidet, welches Ihrer Konten die Karte übernimmt.

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.

Bei den internationalen Anbietern erreichen überhaupt keine Kartendaten Ihre Website: Die Karte wird auf der eigenen Seite des Anbieters eingegeben. Das macht sie zum kürzesten Weg zu einem kleinen PCI-Geltungsbereich — und auch dem Grund, warum sie weder BIN-Routing noch Raten kennen.

Die internationalen Anbieter

Die internationalen Anbieter decken die Welt außerhalb der Türkei ab. Alle nutzen die eigene gehostete oder weitergeleitete Seite des Anbieters, Kartendaten werden also nie auf Ihrer Website eingegeben. Auch die Authentifizierung läuft dort, aber das Ergebnis bleibt nicht dort: MevvPos hält fest, ob der Zahler authentifiziert wurde, schickt ihn zur Bank, wenn der Emittent eine zusätzliche Abfrage verlangt, und liest die ECI aus, um festzuhalten, ob die Rückbuchungshaftung übergegangen ist. Meldet ein Anbieter das Ergebnis nicht, wird es als unbekannt vermerkt und nicht als Ihre Haftung. Über die Karte hinaus gehen lokale Methoden im jeweils eigenen Feld des Anbieters hinaus: iDEAL, Bancontact, SEPA-Lastschrift, Klarna, EPS, Przelewy24, BLIK, TWINT, Multibanco und Wallets. Sie wählen, welche ein Konto anbietet; eine nicht gewählte Methode wird nie gesendet. Eine Methode, deren Währung nicht zur Bestellung passt, wird direkt verworfen — iDEAL bei einer Dollar-Bestellung anzubieten würde die Zahlung nur beim Anbieter scheitern lassen.

Stripe: Eine Checkout Session im mode=payment, die hinter Stripes eigener Seite ein Payment Intent erstellt. Der geheime Schlüssel kommt in den Merchant Key, das Webhook signing secret in das Zusatzfeld. Die Bestellung wird durch ein signiertes payment_intent.succeeded abgeschlossen. Elements wird bewusst nicht verwendet: Der Einsatz würde die Kartenfelder auf Ihre Seite verlagern und Ihren PCI-Geltungsbereich vergrößern.
PayPal: Orders v2, in drei Schritten: die Bestellung wird erstellt, der Kunde genehmigt sie bei PayPal, und MevvPos erfasst sie (Capture). Der dritte Schritt ist der, den man leicht übersieht — eine genehmigte, aber nie erfasste Bestellung lässt das Geld uneingezogen, während die Bestellung bezahlt aussieht. Die REST-Client-ID kommt in die Merchant-Nummer, das Client Secret in den Merchant Key, und die Webhook ID in das Zusatzfeld.
Mollie: Payments API v2. Der API-Key — live_… oder test_… — kommt in den Merchant Key, ein Zusatzfeld gibt es nicht, weil Mollie seine Benachrichtigungen nicht signiert. Was MevvPos stattdessen tut, steht weiter unten im Webhook-Abschnitt.
Square: Ein Payment Link über die Checkout API. Geben Sie den Access Token als Merchant Key ein, dazu die Location ID und den Webhook signature key. Square bindet jeden Verkauf an einen Standort: Ohne die Location ID kann überhaupt keine Zahlung erstellt werden, und Squares eigene Fehlermeldung sagt das nicht klar.
Authorize.Net: Accept Hosted. Die API Login ID kommt in die Merchant-Nummer, der Transaction Key in den Merchant Key, und der Signature key in das Zusatzfeld — ein anderer Wert als der Transaction Key und leicht mit ihm zu verwechseln. Dies ist der einzige Anbieter, der keine Weiterleitungsadresse zurückgibt: Er liefert ein Token, das MevvPos als Formular per POST an die gehostete Seite sendet.
Checkout.com: Die Hosted Payments Page. Der geheime Schlüssel (sk_…) kommt in den Händlerschlüssel und der Webhook-Signaturschlüssel in das Zusatzfeld; die Benachrichtigung wird mit HMAC-SHA256 über den Rohkörper signiert. Ein Verhalten, mit dem zu rechnen ist: Eine Rückerstattung wird asynchron angenommen. Checkout.com antwortet auf den Rückerstattungsaufruf mit 202 und einer Action-ID — das heißt, die Anfrage wurde entgegengenommen, nicht dass das Geld bereits zurück ist.
Razorpay: Ein Payment Link für Shops, die nach Indien verkaufen, wo die Karte allein nicht genügt und UPI, Netbanking und Wallets auf der Seite des Anbieters zusammenkommen. Die Key ID kommt in die Händlernummer, das Key Secret in den Händlerschlüssel und das Webhook-Secret — ein vom Key Secret getrennter Wert — in das Zusatzfeld. Razorpay gibt zwei Kennungen zurück, die nicht austauschbar sind: Mit der Link-ID (plink_…) wird der Status abgefragt, eine Rückerstattung ist dagegen nur mit der Zahlungs-ID (pay_…) möglich, die der Link meldet, sobald er bezahlt wurde.
Paystack: Eine gehostete Transaktionsseite für Shops, die nach Nigeria, Ghana, Südafrika, Kenia und Côte d’Ivoire verkaufen, wo USSD, Banküberweisung und Mobile Money genauso zählen wie die Karte. Der geheime Schlüssel (sk_live_… oder sk_test_…) kommt in den Händlerschlüssel, ein Zusatzfeld gibt es nicht — die Benachrichtigung wird mit HMAC-SHA512 und demselben Geheimnis signiert. Alles hängt an einer einzigen Referenz: das Starten der Zahlung, die Statusabfrage und die Rückerstattung nutzen sie alle.

Der Testmodus schaltet bei PayPal, Square und Authorize.Net auf die eigene Sandbox-Adresse des Anbieters um. Stripe und Mollie trennen live von test über den Key statt über die Adresse, dort entscheidet also der eingefügte Key.

Beträge werden durchgängig als Ganzzahlen in der kleinsten Einheit der Währung geführt — Kuruş, Cent — nie als Dezimalbruch. Mollie ist der einzige Anbieter, der eine Dezimalzeichenkette zurückerwartet, und zwar mit exakt der richtigen Anzahl Stellen für die Währung: 10.0 wird abgelehnt, wo 10.00 akzeptiert wird. Diese Zeichenkette wird aus der Ganzzahl gebildet, nicht aus einer Gleitkommazahl.

Keiner der acht wurde durchgängig mit einem echten Händlerkonto verifiziert. Jede Anbieterdatei sagt das in ihrem eigenen Kopf und nennt die Dokumentationsseiten, aus denen sie geschrieben wurde. Die Abläufe folgen der veröffentlichten Dokumentation der Anbieter, und Signaturalgorithmen wie Feldnamen sind daran festgemacht — das ist aber nicht dasselbe wie eine abgeschlossene Echtzahlung, und wir werden es nicht so darstellen. Lesen Sie sie als bereit zum Anbinden und Testen gegen Ihre eigene Sandbox, nicht als in Produktion bewiesen.

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.

There is no cap on the number of provider accounts, and routing between them — by the card’s issuing bank and by the order’s currency — is part of the free plugin. Earlier releases allowed one account; that limit was removed in 4.9.0.

Läuft eine Lizenz ab, wird das Konto, das weiter Zahlungen einzieht, nicht zufällig gewählt: Es ist das als Standard markierte, sonst das zuerst konfigurierte aktivierte Konto. Eine zufällige Wahl würde bedeuten, dass ein Shop eines Morgens still über eine andere Bank zu kassieren beginnt.

Bank-API — Zugangsdaten und die Gateway-Adresse

Anbieter: Die Liste kommt in zwei Gruppen: Türkei — Bank-Virtual-POS und Internationale Zahlungsanbieter. Alles andere, was das Formular abfragt, ergibt sich aus dieser einen Wahl, und Einstellungen, die auf Ihre Wahl nicht zutreffen können, werden gar nicht erst angezeigt.
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.
Die eigene Währung der Bestellung an die Bank senden: Nur bei türkischem Virtual-POS, standardmäßig aus: MevvPos sendet türkische Lira, was Ihre Bank erwartet, sofern Sie keine Mehrwährungsvereinbarung haben. Die Währung ist Teil der Signatur, daher wird ein von Ihrer Bank nicht akzeptierter Wert ohne Erklärung abgelehnt. Die internationalen Anbieter übernehmen die Währung der Bestellung, wie sie ist, und diese Frage wird ihnen nie gestellt.
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 den von Ihnen gewählten Anbieter:

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.
Stripe — Webhook signing secret.
PayPal — Webhook ID.
Square — Location ID und Webhook signature key.
Authorize.Net — Signature key, nur für Webhooks verwendet.
Mollie — keine Zusatzfelder: Der API-Key kommt in 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.

Webhooks — wo die Bestellung wirklich abgeschlossen wird

Jeder internationale Anbieter braucht eine Adresse auf Ihrer Website, und sie hat bei allen dieselbe Form: ?mevvpos-webhook=<provider> an Ihre Startadresse angehängt. Der genaue Wert wird schreibgeschützt auf dem Tab Bank API angezeigt; ein Klick auf das Feld wählt ihn aus.

Was die Bestellung abschließt, ist der Webhook, nicht die Rückkehr des Kunden auf Ihre Website. Die Rückkehradresse lässt sich erraten, und ein Kunde kann sie erreichen, ohne bezahlt zu haben, sodass ein dort ankommender Browser für sich genommen nichts beweist. MevvPos liest das Ergebnis nie aus der Rückkehr: Es wartet entweder auf die signierte Benachrichtigung oder fragt den Anbieter direkt, Server zu Server. Bis eine dieser beiden Antworten eintrifft, bleibt die Bestellung ausstehend, und eine Bestellnotiz vermerkt das.

Kopieren Sie die Adresse aus dem Tab Bank API.
Mollie ist die Ausnahme und braucht nirgends etwas eingefügt: MevvPos sendet die Adresse mit jeder Zahlung, die es erstellt. Sie wird weggelassen, wenn die Website auf einer lokalen Adresse antwortet, weil Mollie sie ohnehin nicht erreichen könnte — bei der lokalen Entwicklung kommt das Ergebnis stattdessen aus der Statusabfrage.
Fügen Sie sie genau so, wie sie erscheint, in das eigene Panel des Anbieters ein. Square berechnet seine Signatur über die Benachrichtigungsadresse zusammen mit dem Body, sodass schon ein Zeichen Unterschied — ein abschließender Schrägstrich genügt — jedes Event still an der Verifizierung scheitern lässt.
Speichern Sie das vom Anbieter zurückgegebene Signing Secret in dessen Zusatzfeld.
Senden Sie ein Testereignis aus dem Panel des Anbieters und prüfen Sie, ob sich eine Bestellung tatsächlich bewegt.

Mollie signiert seine Benachrichtigung überhaupt nicht — der Body enthält nichts als eine Zahlungs-ID. Das wirkt unsicher, ist aber tatsächlich sicherer: MevvPos vertraut der Benachrichtigung nicht, sondern behandelt sie wie eine Türklingel. Es nimmt die ID und fragt Mollie direkt nach dem Status der Zahlung, und nur eine Antwort von paid erzeugt ein Ereignis. Ein Angreifer kann mit einer erfundenen ID klingeln, aber Mollies Antwort nicht fälschen — eine gefälschte Benachrichtigung kann daher nie eine Bestellung als bezahlt markieren. Ist Mollie nicht erreichbar, lautet die Antwort „ich weiß es nicht“, und nichts ändert sich.

Auch PayPals Signatur wird nicht lokal geprüft. Sie ist eine Zertifikatskette, und ein stiller Fehler bei der Kettenverifizierung macht die Signatur bedeutungslos; PayPal veröffentlicht dafür einen Endpunkt, und alles außer SUCCESS bedeutet, dass das Ereignis ignoriert wird.

Für jeden Anbieter gelten drei Regeln. Die Antwort ist immer ein leeres 200 — ein verifiziertes Ereignis, ein Duplikat und Datenmüll erhalten alle dieselbe Antwort, denn eine andere Antwort würde einem Angreifer verraten, welcher Versuch näher dran war, und eine Fehlerantwort würde den Anbieter nur dazu bringen, ein Ereignis erneut zu senden, das sich nie verifizieren lässt. PayTR ist die eine Ausnahme, weil es wörtlich den Text OK erwartet und die Benachrichtigung sonst stundenlang wiederholt. Dasselbe Ereignis zweimal zugestellt hat keine zweite Wirkung. Und gegen welches Konto ein Ereignis verifiziert wird, wird aus Ihrer eigenen Konfiguration gelesen, nie aus der Anfrage — sonst könnte ein Angreifer selbst bestimmen, mit welchem Schlüssel seine eigene Fälschung geprüft wird.

Der Webhook läuft nicht über den Endpunkt von WooCommerce. Er hat eine eigene Query-Variable und wird abgefangen, bevor Theme, Seite und Query-Mechanik überhaupt laufen — deshalb funktioniert er auch auf einer Website ohne installiertes WooCommerce.

BIN-basiertes Routing

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

A snapshot of the BIN table ships inside the plugin — 1.449 BINs across 36 banks in the current build — so routing works offline, with no account of any kind, from the moment you install it.
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 %.

Das funktioniert auf beiden Kassenflächen. Auf der Blockseite zeichnet der Block selbst die Ratentabelle, und der Aufschlag wird dem Warenkorb als Gebühr hinzugefügt, genau wie auf der klassischen Seite — die Wahl einer Rate aktualisiert also die Summe, bevor die Bestellung abgeschickt wird.

Raten sind eine türkische Institution, und der Tab weiß das. Solange ein internationaler Anbieter gewählt ist, wird das Ratenraster gar nicht erst angezeigt, stattdessen sagt der Tab das in einem Satz: Zwölf Zeilen auszufüllen, die nie zur Anwendung kommen können, wäre eine Art, Sie in die Irre zu führen.

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.

The ceiling is twelve in every installation — that is the limit the banks themselves apply, not a product limit. It is enforced in three places: the list the customer sees, the value that arrives with the form, and the value the engine sends to the provider. A modified form cannot buy more instalments than you offer.

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 türkische Familie läuft über 3-D Secure. Es gibt keinen Nicht-3D-Modus und keine Einstellung zum Abschalten. International spricht MevvPos EMV 3-D Secure 2: Es hält fest, ob der Zahler mit oder ohne zusätzliche Abfrage authentifiziert wurde, schickt den Kunden zur Bank, wenn der Emittent eine verlangt, und liest die ECI aus, um festzuhalten, ob die Rückbuchungshaftung übergegangen ist. Zwei Dinge tut es bewusst nicht: Es beansprucht nie eine Ausnahme, für die ein Anbieter kein Feld hat, und es meldet die Haftung nie als Ihre, wenn der Anbieter uns das Ergebnis nicht mitteilt — „wir wissen es nicht“ und „die Haftung liegt beim Händler“ sind verschiedene Antworten.

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.
Weiterleitungsablauf: Stripe, PayPal, Mollie, Square, Checkout.com, Razorpay und Paystack: MevvPos erzeugt die Zahlung über die REST-API des Anbieters und schickt den Kunden an die Adresse, die der Anbieter zurückgibt.
Token-Formular-Ablauf: Authorize.Net: Der Anbieter gibt statt einer Adresse ein Token zurück, und das Token wird als Formular per POST an dessen gehostete Seite gesendet. Das Token in eine URL zu schreiben würde es im Browserverlauf und in Server-Logs preisgeben.

Die türkischen Banken kehren immer zu einer Adresse auf Ihrer Website zurück: ?wc-api=mevvpos_callback. Die Signatur bei dieser Rückkehr wird mit dem Key des POS geprüft, das die Bestellung tatsächlich verwendet hat, festgehalten an der Bestellung selbst — bei mehr als einem POS erzeugt eine Prüfung mit dem falschen Key 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.

Vorautorisierung, Zahlungslinks und Risikoregeln

Jetzt autorisieren, später einziehen

Jeder POS-Eintrag trägt eine Einzugsmethode: sofort abbuchen oder den Betrag reservieren und später einziehen. Beim zweiten wird das Geld an der Kasse auf der Karte reserviert, und der Bestellbildschirm bekommt zwei Schaltflächen — einziehen (ganz oder zum Teil) und freigeben. Ziehen Sie ein, wenn das Paket rausgeht; geben Sie frei, wenn Sie nicht liefern können.

Die Einstellung erscheint nur dort, wo der Anbieter sie wirklich trägt: die NestPay-Bankenfamilie (İşbank, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat) sowie Stripe, Authorize.Net und Checkout.com. Bei jedem anderen Anbieter wird die Wahl gar nicht erst angeboten, statt angeboten zu werden und dann am Gateway zu scheitern.

Ein Zahlungslink

Der Bildschirm Zahlungslinks erstellt einen Link über einen Betrag und, wahlweise, eine Beschreibung und ein Ablaufdatum. Wer ihn öffnet, landet auf der gewöhnlichen Kasse des Shops mit einer bereits angelegten offenen Bestellung, das heißt dasselbe BIN-Routing, dieselbe Ratentabelle und derselbe Schritt mit 3-D Secure wie bei jeder anderen Zahlung. Nichts ist eine Abkürzung um die Zahlungs-Engine herum.

Das Token besteht aus 32 zufälligen Bytes; die Adresse lässt sich nicht aus einer anderen erraten.
Der Link läuft an dem Datum ab, das Sie festlegen.
Er funktioniert einmal. Nachdem die Bestellung bezahlt ist, öffnet der Link nicht mehr, eine weitergeleitete Nachricht kann also nicht zweimal bezahlt werden.

Risikoregeln

Der Bildschirm Risiko enthält fünf Regeln, jede einzeln zuschaltbar und mit einem eigenen Schwellwert. Sie werden ausgewertet, bevor die Karte an irgendeinen Anbieter geht, und jede kann die Bestellung markieren, zur Prüfung zurückhalten oder rundweg ablehnen.

Versuche pro Adresse — wie viele Zahlungsversuche ein Besucher in einem Zeitfenster machen darf.
Versuche pro Karte — dieselbe Zählung für eine einzelne Karte.
Aufeinanderfolgende Fehlschläge — eine Reihe von Ablehnungen hintereinander.
Länderabweichung — eine in Türkiye ausgegebene Karte mit einer Rechnungsadresse außerhalb von Türkiye.
Betragsobergrenze — eine Bestellsumme, oberhalb derer Sie erst hinsehen wollen.

Es wird keine Adresse und keine Kartennummer festgehalten. Was die Zähler halten, ist ein mit Ihrem eigenen Site-Schlüssel gesalzener Hashwert, die Regeln können eine Wiederholung also erkennen, ohne dass der Bildschirm je zu einer zweiten Kartendatenbank wird. Es gibt keinen Geräte-Fingerabdruck, keinen maschinell gelernten Score und keine BIN-Sperrliste — fünf Regeln, die Sie lesen können, und nichts, was Sie einem Kunden nicht erklären könnten.

Erstattungen

Bei den internationalen Anbietern werden Erstattungen wie üblich vom WooCommerce-Bestellbildschirm aus ausgelöst — vollständig oder teilweise. MevvPos sendet die Erstattung anhand der an der Bestellung hinterlegten Zahlungsreferenz an den Anbieter.

Erstattungen werden nie durch die Lizenz gesperrt. Dass man einem Kunden sein Geld nicht zurückgeben kann, darf keine Folge einer Verlängerungserinnerung sein, und in den meisten Ländern ist es außerdem eine rechtliche Pflicht.

Türkisches Bank-Virtual-POS kann noch nicht aus WordPress heraus erstattet werden, und MevvPos sagt das, statt so zu tun als ob. Erstatten Sie die Transaktion über den eigenen Bildschirm Ihrer Bank. Still einen Erfolg zu melden, würde WooCommerce dazu bringen, die Bestellung als erstattet zu markieren, während das Geld bei der Bank liegen bleibt — ein falscher Buchungseintrag kostet weit mehr als ein Button, der nicht funktioniert.

Eine Erstattung braucht die vom Anbieter zurückgegebene Zahlungsreferenz. Eine Bestellung, die vor der Erfassung dieser Referenz aufgegeben wurde, oder eine, deren Anbieterkonto inzwischen gelöscht wurde, kann nicht über das Plugin erstattet werden.

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.

The revenue summary covers 7, 30 or 90 days in every installation. The Pro add-on adds three breakdowns on top of it:

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.

Die Engine ohne WooCommerce verwenden

Das WooCommerce-Gateway ist jetzt ein Verbraucher der Zahlungs-Engine, nicht mehr die Engine selbst. Die Engine weiß nichts von Bestellungen, Warenkörben oder Sitzungen: Sie übergeben ihr eine Zahlungsabsicht (Payment Intent) — einen Betrag als Ganzzahl in kleinsten Einheiten, eine Währung, eine Referenz und die Rückkehradressen — und sie liefert entweder ein Formular zum Absenden oder eine Adresse zum Weiterleiten zurück. Ein Formular-Plugin, ein Buchungs-Plugin oder Ihr eigener Code können sie genauso ansteuern wie die Kasse.

MevvPos_Payment_Engine::start() beginnt eine Zahlung und gibt zurück, was der Browser als Nächstes tun soll.
MevvPos_Payment_Engine::handle_webhook() ist der einzige Weg, der den Status einer Zahlung ändert. Ein Ereignis, dessen Signatur nicht verifiziert, ändert nichts und wird protokolliert.
MevvPos_Payment_Engine::webhook_url() baut die Adresse, die Sie in das Panel des Anbieters einfügen.
Die Ratenobergrenze wird als letzte Verteidigungslinie auch innerhalb der Engine angewendet — der aufrufende Bildschirm könnte gerendert worden sein, bevor die Lizenz ablief.

Falls Sie vor Version 4.0.0 über den Filter mevvpos_providers einen eigenen Anbieter registriert haben, erhält er nun eine Zahlungsabsicht statt einer WC_Order. Anfragen und Signaturen für die sieben türkischen Familien sind unverändert, sodass bestehende POS-Einrichtungen unangetastet weiterlaufen.

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

Nothing in the free plugin is locked, limited or counted. Every Turkish institution, every international provider, 3-D Secure, hosted-page checkout, wallets, multi-currency, currency and BIN routing, as many POS accounts as you have merchant agreements, instalments to twelve, test mode, refunds, pre-authorisation, payment links, the risk rules and the 7 / 30 / 90 day revenue report all work with no key and no account. Pro is a separate plugin whose code is not in the free package at all — it adds capabilities rather than raising a ceiling.

Kostenlos: Everything on this page unless it says otherwise: unlimited provider and POS accounts with BIN and currency routing, instalments to twelve, the 7 / 30 / 90 day revenue report, the packaged BIN table, pre-authorisation, payment links, risk rules, refunds and unlimited transaction volume. Apple Pay and Google Pay too, because they appear on the provider’s hosted page by themselves.
Pro: Recurring payments and subscription billing, the mandate store, stored payment authorisations in My Account, SCA exemption requests, the POS / bank / instalment / decline-code breakdowns with CSV export, and a weekly live BIN refresh. A separate plugin, downloaded from your account here — it is not on WordPress.org.

Multi-currency and routing by currency are both free. They were briefly sold with Pro; charging for the ability to point a euro order at the euro account was pricing a limitation rather than a capability, and it is gone.

Wenn eine Lizenz abläuft oder fehlt:

Nothing in the free plugin changes. It does not ask about licences at all — the question was removed from that package in 4.9.1 — so every account, every instalment plan, every route and the whole revenue report keep working exactly as before.
Your store keeps taking payments. There is no licence check anywhere on the payment path. Cutting off a shop’s revenue is not an acceptable way to send a renewal reminder.
Erstattungen funktionieren weiter, weil sie überhaupt nicht gesperrt sind.
Recurring charges already scheduled stop being taken, and the subscription screens go quiet. Mandates and stored authorisations are never deleted; they resume on renewal.
The breakdowns and CSV export stop. The 7 / 30 / 90 day report underneath them is in the free plugin and stays. Collected history is not deleted.
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.

Updates

Das Pro-Plugin führt einen an Ihre Lizenz gebundenen Updater mit sich. Das muss es: Pro wird nicht auf WordPress.org veröffentlicht, es gibt also keine Stelle, an der WordPress erfahren könnte, dass eine neue Version existiert. Mit einer aktiven Lizenz erscheint ein Pro-Update auf dem Plugin-Bildschirm wie jedes andere.

Das kostenlose Plugin kündigt jetzt auch seine eigenen Updates an. Es fragt unseren Server, ob eine neuere Version existiert, und übergibt die Antwort dem eigenen Update-Ablauf von WordPress, sodass eine neue Version auf der Plugin-Seite mit einem gewöhnlichen Aktualisieren-Button erscheint, statt darauf zu warten, dass jemand von Hand ein ZIP herunterlädt. Die Anfrage trägt nur den Paketnamen und die installierte Version — keine Website-Adresse, keine E-Mail-Adresse, keinen Lizenzschlüssel, kein Plugin-Inventar. Da nichts darin Sie identifiziert, ruht das Vertrauen vollständig auf der Signatur: Die Antwort ist mit unserem Ed25519-Schlüssel signiert, und eine unsignierte, falsch signierte, aus einem alten Zeitstempel wiedereingespielte oder auf einen fremden Host zeigende Antwort wird verworfen, ohne die Website zu berühren. Ihre POS-Datensätze, Zugangsdaten und die gesammelte Historie liegen in WordPress-Optionen und Bestell-Metadaten, und ein Update rührt sie nie an.

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 bezahlt bei Stripe oder PayPal, aber die Bestellung bleibt ausstehend: Die Webhook-Adresse ist nicht erreichbar oder nicht registriert. Die Bestellung wird durch die Benachrichtigung abgeschlossen, nicht durch die Rückkehr des Kunden, sodass ein fehlender Webhook genau wie ein Kunde aussieht, der nie bezahlt hat. Prüfen Sie, ob die Adresse im Tab Bank API mit der im Panel des Anbieters gespeicherten übereinstimmt und ob das Testereignis des Anbieters ankommt.
Alle Square-Ereignisse werden abgelehnt: Square signiert die Benachrichtigungsadresse zusammen mit dem Body. Die bei Square registrierte Adresse muss zeichengenau mit der im Tab Bank API übereinstimmen — ein abschließender Schrägstrich, http statt https, oder ein www, das die eine Seite hat und die andere nicht, genügt bereits.
Authorize.Net-Ereignisse verifizieren nie: Der Signature key ist ein eigener Wert, getrennt vom Transaction Key, und die beiden lassen sich leicht vertauschen. Webhooks werden ausschließlich mit dem Signature key verifiziert.
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 bei den NestPay-Banken die Gateway-Adresse nicht um. Tragen Sie beim Testen die Testadresse Ihrer Bank in Gate URL ein. Bei Stripe und Mollie ändert der Schalter die Adresse ebenfalls nicht — dort wählt der Test-Key die Sandbox aus.
Es erscheinen keine Raten: Either the rate for that count is empty rather than zero, the card is from another bank, or the selected provider is an international one and has no instalments at all.
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 für türkische Bank-Virtual-POS. Keine türkische Familie kennt einen Erstattungsaufruf; erstatten Sie über den eigenen Bildschirm Ihrer Bank. Die internationalen Anbieter können es, und WooCommerce zeigt für sie die Erstattungsschaltfläche.
The updater depends on where you got the plugin. The build downloaded from mevvsoft.com updates itself from our servers. The build published on WordPress.org does not carry that code at all — a plugin hosted there must be updated through WordPress.org, so the two packages differ in exactly this one file.
Wiederkehrende Zahlungen funktionieren nur mit den internationalen Anbietern, und es gibt keine Auswahl gespeicherter Karten. Eine gespeicherte Einzugsermächtigung wird angelegt, erneuert, wiederholt und als überfällig markiert, und ein WooCommerce-Subscriptions-Produkt richtet sie ohne Code ein. Was fehlt: Die türkischen Bank-Virtual-POS-Familien können keine tragen, Käufer können an der Kasse keine gespeicherte Karte wählen, und es gibt weder einen Mahnplan noch eine Stornofunktion im Admin.
Vorautorisierung gibt es, aber nicht überall. Ein POS kann den Betrag reservieren und ihn später — ganz oder teilweise — vom Bestellbildschirm einziehen oder ihn freigeben. Nur die NestPay-Bankenfamilie, Stripe, Authorize.Net und Checkout.com tragen das; jeder andere Anbieter ist ein direkter Verkauf, und die Einstellung wird dort nicht angezeigt.
No rule-based routing. Routing is by currency and issuing bank only — not by amount, card brand or country.
Routing asks the currency first and the issuing bank second, in every installation. What is still missing is everything past that: no failover to a second account, no cascading retry, and no routing by amount, card brand or country.
Beide Kassen werden unterstützt. Sowohl das klassische Zahlungsformular als auch der WooCommerce-Checkout-Block werden bedient, und die Ratentabelle und ihr Aufschlag verhalten sich bei beiden gleich. Der Block schreibt die gewählte BIN und Rate über die Store API, der Aufschlag wird also vom selben Code berechnet wie auf der klassischen Seite.
3D Pay Hosting wurde bewusst verworfen. Die gehostete Seite beseitigt den PCI-Geltungsbereich, entfernt aber auch die BIN und die Ratentabelle — und der gesamte Wert der türkischen Seite liegt im Routing, das sie ermöglichen. Die internationalen Anbieter sind gerade deshalb gehostet, weil es dort nichts zu routen gibt.
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. Auf der türkischen Seite werden nur die ersten sechs Ziffern und die von ihnen bezeichnete Bank behalten; bei den internationalen Anbietern nicht einmal das, weil die Karte nie auf Ihrer Website eingegeben wird. Den Sicherheitscode zu speichern ist unter allen Umständen verboten, und selbst ein maskierter verrät noch seine Länge.

Eine Engine: türkische Bank-Virtual-POS und die internationalen Anbieter.