MevvPos — Dokumentacja Mevvsoft

Instalacja

MevvPos wymaga WordPressa 6.0+ i PHP 8.1+. WooCommerce jest opcjonalny. Gdy aktywny jest WooCommerce 9.0 lub nowszy, MevvPos rejestruje się jako metoda płatności przy kasie; bez niego silnik płatności i tak się ładuje i może być obsługiwany przez inną wtyczkę. Wcześniejsze wersje deklarowały WooCommerce jako twardą zależność i WordPress odmawiał aktywacji bez niego — ten wymóg zniknął.

Obie powierzchnie zamówienia WooCommerce są obsłużone. MevvPos rejestruje się zarówno dla klasycznej strony zamówienia opartej na shortcode, jak i dla nowszego bloku Zamówienie. Do wersji 4.7.1 podłączona była tylko strona klasyczna, więc sklep, który przeszedł na blokowe zamówienie, tracił opcję karty całkowicie — bez błędu, bez ostrzeżenia, po prostu brakująca metoda płatności. Nie trzeba ustawiać nic więcej: na stronie blokowej pola karty, tabela rat i dopłata ratalna pojawiają się tak samo.

Wgraj wtyczkę w Wtyczki → Dodaj nową → Wyślij wtyczkę na serwer i włącz ją.
Otwórz pozycję MevvPos w lewym menu administracyjnym. Skrót jest też w sekcji WooCommerce, gdzie sprzedawcy zwykle szukają ustawień płatności.
W zakładce Ogólne należy włączyć metodę płatności i ustawić tytuł, który klient zobaczy przy składaniu zamówienia.
Na karcie Bank API wybierz swojego dostawcę — turecki bankowy wirtualny POS lub jednego z Międzynarodowi dostawcy — i wprowadź dane uwierzytelniające, które od niego otrzymałeś.
Jeśli wybrałeś dostawcę międzynarodowego, skopiuj adres webhooka wydrukowany na tej samej karcie do panelu dostawcy. Bez niego nic się nie zakończy.
W zakładce Raty i prowizja należy wpisać własne stawki ratalne.
Przed uruchomieniem produkcyjnym przetestuj wszystko na testowych danych dostępowych z banku.

The free plugin creates no database tables and registers no scheduled job. Everything lives in WordPress options and in order meta.

Pro to osobna wtyczka, instalowana obok darmowej — nie jest jej zamiennikiem. Darmowa wtyczka jest publikowana na WordPress.org, gdzie wszystko, co opublikowane, może być rozpowszechniane dalej na licencji GPL; pozostawienie płatnego kodu w tej samej paczce sprawiłoby, że każdy, kto usunąłby sprawdzanie licencji, mógłby go legalnie rozpowszechniać. Klucz licencyjny wpisuje się w zakładce Licencja.

Otwarcie WooCommerce → Ustawienia → Płatności → MevvPos przekierowuje na ekran wtyczki MevvPos. To zamierzone: te ustawienia mają jedno miejsce, a nie dwa, które mogłyby się różnić.

Jak to działa

MevvPos mówi dwoma rodzajami protokołu płatności, a to, który z nich otrzymasz, wynika z wybranego dostawcy. Oba przechodzą przez ten sam silnik i tworzą ten sam zapis zamówienia.

Podpisany formularz — Turcja: Siedem tureckich rodzin wirtualnych POS. MevvPos buduje pola płatności, podpisuje je kluczem sklepu i wysyła je do banku metodą POST. Klient uwierzytelnia się przez 3-D Secure, a bank wraca na twoją stronę; to podpis przy tym powrocie kończy zamówienie.
Hostowana strona i webhook — międzynarodowe: Stripe, PayPal, Mollie, Square, Authorize.Net, Checkout.com, Razorpay i Paystack. MevvPos tworzy płatność u dostawcy przez jego API REST i wysyła klienta na własną stronę dostawcy. Zamówienie finalizuje odpowiedź dostawcy: podpisane powiadomienie docierające na twój adres webhooka albo — jeśli klient wróci wcześniej — zapytanie o status serwer-serwer wykonane ze strony powrotu. Tym, co nigdy samo nie finalizuje zamówienia, jest powrót przeglądarki.

Po stronie tureckiej silnik robi coś, czego międzynarodowi dostawcy nigdy nie potrzebują: decyduje, które z twoich kont przyjmie kartę.

Definiuje się jeden lub więcej rekordów POS. Rekord POS to wirtualny POS jednego banku: jego dane dostępowe, adres bramki i stawki rat.
Na stronie zamówienia klient wpisuje dane karty. Pierwsze sześć cyfr — numer BIN — wskazuje bank, który ją wydał.
Wtyczka MevvPos sprawdza numer BIN i wysyła płatność do własnego POS w tym banku, jeżeli taki istnieje. W przeciwnym razie płatność trafia do POS domyślnego.
Raty są proponowane wyłącznie wtedy, gdy karta należy do banku danego POS, ponieważ banki nie udzielają rat na karty innego banku.
Klient przechodzi przez 3-D Secure w banku, a bank wraca pod jeden adres zwrotny w witrynie.
Podpis na powrocie weryfikowany jest kluczem tego POS, którego zamówienie faktycznie użyło, zamówienie zostaje ukończone, a wynik zapisany.

Numer karty, data ważności i kod CVV nigdy nie trafiają do bazy danych witryny ani do sesji WooCommerce. Jedyne zachowywane dane karty to pierwsze sześć cyfr i rozpoznana nazwa banku.

Przy międzynarodowych dostawcach żadne dane karty w ogóle nie docierają do twojej strony: kartę wpisuje się na własnej stronie dostawcy. To właśnie czyni ich najkrótszą drogą do małego zakresu PCI — i to samo tłumaczy, dlaczego nie mają ani routingu BIN, ani rat.

Międzynarodowi dostawcy

Dostawcy międzynarodowi obejmują świat poza Türkiye. Wszyscy korzystają z własnej strony dostawcy — hostowanej lub przekierowanej — więc dane karty nigdy nie są wpisywane na Twojej stronie. Uwierzytelnianie również odbywa się tam, ale wynik tam nie zostaje: MevvPos zapisuje, czy płatnik został uwierzytelniony, kieruje go do banku, gdy wydawca zażąda dodatkowej weryfikacji, i odczytuje ECI, aby zapisać, czy odpowiedzialność za obciążenie zwrotne została przeniesiona. Jeśli dostawca nie przekazuje wyniku, zapisujemy go jako nieznany, a nie jako Twój. Poza kartą metody lokalne wychodzą we własnym polu każdego dostawcy: iDEAL, Bancontact, polecenie zapłaty SEPA, Klarna, EPS, Przelewy24, BLIK, TWINT, Multibanco i portfele. To Ty wybierasz, które oferuje dane konto, a metoda niewybrana nigdy nie jest wysyłana. Metoda, której waluta nie pasuje do zamówienia, jest odrzucana od razu — oferowanie iDEAL przy zamówieniu w dolarach sprawiłoby tylko, że płatność nie powiodłaby się u dostawcy.

Stripe: Checkout Session w trybie mode=payment, który tworzy Payment Intent za własną stroną Stripe. Klucz tajny wpisujesz w polu klucza sprzedawcy, a Webhook signing secret w polu dodatkowym. Zamówienie kończy podpisane zdarzenie payment_intent.succeeded. Elements celowo nie jest używany: uruchomienie go przeniosłoby pola karty na twoją stronę i powiększyło twój zakres PCI.
PayPal: Orders v2, w trzech krokach: utworzenie zamówienia, zatwierdzenie go przez klienta w PayPal i przechwycenie go przez MevvPos. Trzeci krok najłatwiej przeoczyć — zatwierdzone, ale nigdy nie przechwycone zamówienie zostawia pieniądze niepobrane, choć zamówienie wygląda na opłacone. Identyfikator klienta REST wpisujesz w numerze sprzedawcy, sekret klienta w kluczu sprzedawcy, a Webhook ID w polu dodatkowym.
Mollie: Payments API v2. Klucz API — live_… lub test_… — wpisujesz w polu klucza sprzedawcy i nie ma pola dodatkowego, ponieważ Mollie nie podpisuje swoich powiadomień. Zobacz sekcję o webhooku poniżej, aby dowiedzieć się, co robi w zamian MevvPos.
Square: Payment Link przez Checkout API. Wprowadź token dostępu jako klucz sprzedawcy oraz Location ID i Webhook signature key. Square wiąże każdą sprzedaż z lokalizacją: bez Location ID żadnej płatności w ogóle nie da się utworzyć, a własny błąd Square nie mówi o tym wprost.
Authorize.Net: Accept Hosted. API Login ID wpisujesz w numerze sprzedawcy, Transaction Key w kluczu sprzedawcy, a Signature key w polu dodatkowym — to wartość inna niż Transaction Key i łatwo ją z nim pomylić. To jedyny dostawca, który nie zwraca adresu przekierowania: zwraca token, który MevvPos wysyła do hostowanej strony jako formularz.
Checkout.com: Hosted Payments Page. Klucz tajny (sk_…) wpisuje się w klucz akceptanta, a klucz podpisu webhooka w pole dodatkowe; powiadomienie jest podpisywane HMAC-SHA256 po surowym ciele. Jedno zachowanie do przewidzenia: zwrot jest przyjmowany asynchronicznie. Checkout.com odpowiada na wywołanie zwrotu kodem 202 i identyfikatorem akcji, co znaczy, że żądanie zostało przyjęte — a nie że pieniądze już wróciły.
Razorpay: Payment Link, dla sklepów sprzedających do Indii, gdzie sama karta nie wystarcza, a UPI, bankowość internetowa i portfele są zebrane na stronie dostawcy. Key ID wpisuje się w numer akceptanta, Key Secret w klucz akceptanta, a sekret webhooka — wartość odrębną od Key Secret — w pole dodatkowe. Razorpay zwraca dwa identyfikatory, których nie można stosować zamiennie: identyfikatorem linku (plink_…) pyta się o status, natomiast zwrot jest możliwy wyłącznie z identyfikatorem płatności (pay_…), który link zgłasza po opłaceniu.
Paystack: Hostowana strona transakcji, dla sklepów sprzedających do Nigerii, Ghany, RPA, Kenii i Wybrzeża Kości Słoniowej, gdzie USSD, przelew bankowy i pieniądz mobilny liczą się tak samo jak karta. Klucz tajny (sk_live_… albo sk_test_…) wpisuje się w klucz akceptanta i nie ma pola dodatkowego — powiadomienie jest podpisywane HMAC-SHA512 tym samym sekretem. Wszystko wisi na jednym numerze referencyjnym: rozpoczęcie płatności, pytanie o jej status i zwrot używają go tak samo.

Tryb testowy podmienia adres na własny adres testowy (sandbox) dostawcy dla PayPal, Square i Authorize.Net. Stripe i Mollie oddzielają tryb produkcyjny od testowego kluczem, a nie adresem, więc tam o wszystkim decyduje wklejony klucz.

Kwoty są przenoszone od początku do końca jako liczby całkowite w najmniejszej jednostce waluty — kuruş, centy — a nigdy jako ułamek dziesiętny. Mollie to jedyny dostawca, który chce z powrotem ciąg dziesiętny, i chce dokładnie właściwej liczby cyfr dla danej waluty: 10.0 jest odrzucane tam, gdzie 10.00 jest akceptowane. Ten ciąg jest budowany z liczby całkowitej, nie z liczby zmiennoprzecinkowej.

Żaden z ośmiu nie został zweryfikowany od początku do końca na prawdziwym koncie akceptanta. Każdy plik dostawcy mówi to we własnym nagłówku i wymienia strony dokumentacji, z których powstał. Przepływy podążają za opublikowaną dokumentacją dostawców, a algorytmy podpisu i nazwy pól są do niej przypięte — ale to nie to samo co zakończona prawdziwa płatność i nie będziemy tego tak przedstawiać. Czytaj je jako gotowe do podłączenia i przetestowania we własnej piaskownicy, a nie jako sprawdzone na produkcji.

Rekordy POS

Pasek POS znajduje się nad kartami i jest widoczny na każdej z nich. Każda karta pokazuje bank, numer sprzedawcy oraz plakietkę, gdy coś wymaga uwagi.

Domyślny: POS, który przyjmuje płatność, gdy nie znaleziono lepszego dopasowania. Zawsze jest dokładnie jeden.
Nieaktywny: Zachowany, ale nieprzyjmujący płatności. Z tego stanu należy korzystać zamiast usuwania, gdy POS jest skonfigurowany, ale nie działa jeszcze po stronie banku — inaczej klient z kartą tego banku nie mógłby zapłacić.
Oczekiwanie na licencję: Rekord istnieje, ale jest uśpiony, ponieważ licencja nie jest aktywna. Nic nie zostało usunięte; po odnowieniu licencji podejmuje pracę w tym samym miejscu.
Dane API nie zostały wprowadzone: Rekord nie ma jeszcze numeru sprzedawcy.

Banki oznaczane są kolorowym paskiem, a nie logo. Loga banków to znaki towarowe, a piętnaście z nich to zarówno ryzyko prawne, jak i stałe utrzymanie — i tak wiadomo, który bank jest własny.

Ostatniego POS-a nie można usunąć, a ostatniego włączonego nie można wyłączyć. Aby całkowicie przestać przyjmować płatności kartą, należy zamiast tego wyłączyć metodę płatności w zakładce Ogólne.

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.

Gdy licencja wygasa, konto, które nadal pobiera płatności, nie jest wybierane losowo: to konto oznaczone jako domyślne albo, w braku takiego, pierwsze skonfigurowane i włączone konto. Losowy wybór oznaczałby, że sklep pewnego ranka po cichu zaczyna pobierać płatności przez inny bank.

API banku — dane uwierzytelniające i adres bramki

Dostawca: Lista ma dwie grupy: Turcja — bankowy wirtualny POS i Międzynarodowi dostawcy płatności. Wszystko inne, o co pyta formularz, wynika z tego jednego wyboru, a ustawienia, które nie mogą dotyczyć twojego wyboru, w ogóle się nie pokazują.
Bank: Wybierz bank, w którym prowadzony jest POS. Od tego wyboru zależy adres bramki oraz lista BIN używana do rat. Instytucje bez gotowej implementacji wypisane są z dopiskiem „— yakında” (wkrótce) i nie da się ich wybrać.
Numer akceptanta (Client ID): Numer sprzedawcy otrzymany z banku.
Klucz akceptanta (Store key): Klucz zabezpieczający sprzedawcy. Przechowywany jako pole hasła; po zapisaniu pokazywany w postaci zamaskowanej.
Gate URL: Adres, pod który wysyłany jest formularz płatności.
Wyślij do banku walutę zamówienia: Dotyczy tylko tureckiego wirtualnego POS i jest domyślnie wyłączone: MevvPos wysyła tureckie liry, czego oczekuje twój bank, o ile nie masz umowy wielowalutowej. Waluta jest częścią podpisu, więc wartość, której twój bank nie akceptuje, zostaje odrzucona bez wyjaśnienia. Międzynarodowi dostawcy przyjmują walutę zamówienia taką, jaka jest, i nigdy nie zadaje się im tego pytania.
Włącz tryb testowy: Zatrzymuje automatyczne przekierowanie, aby można było obejrzeć żądanie przed jego wysłaniem.

Pozostawienie pola Store Key pustym przy zapisie oznacza „nie zmieniaj go”. Zapisanie pustej wartości wymazałoby klucz, a sklep przestałby przyjmować płatności bez jednego komunikatu o błędzie. Ta sama zasada dotyczy pozostałych pól tajnych.

Niektóre rodziny wymagają dodatkowych danych uwierzytelniających, a formularz pokazuje je tylko dla wybranego przez ciebie dostawcy:

Garanti BBVA — Merchant ID, nazwa użytkownika autoryzacji, hasło autoryzacji.
VakıfBank — Terminal No oraz adres MPI (pozostawienie pustego pola oznacza użycie adresu testowego).
PayTR — Merchant Salt.
iyzico, Craftgate, Sipay — bez dodatkowych pól: klucz API wpisuje się w Numer akceptanta, a sekret w Klucz akceptanta.
Stripe — Webhook signing secret.
PayPal — Webhook ID.
Square — Location ID i Webhook signature key.
Authorize.Net — Signature key, używany wyłącznie do webhooków.
Mollie — brak dodatkowych pól: klucz API wpisujesz w Merchant key.

Te dodatkowe dane dostępowe wchodzą do podpisu. Gdy brakuje jednego z nich, podpis liczony jest z pustą wartością, a bank odrzuca płatność po cichu — bez błędu, bez komunikatu, po prostu odmowa.

Dla siedmiu banków NestPay adres bramki wypełniany jest na podstawie wyboru banku, więc pole Gate URL można zostawić puste. Dla pozostałych pole nie jest wypełniane z góry: należy wpisać adres otrzymany od banku lub dostawcy, inaczej formularz płatności nie ma dokąd wysyłać danych.

Trzynaście obsługiwanych instytucji

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

Instytucje bez implementacji celowo pozostają na liście banków, oznaczone „— yakında”. Usunięcie ich ukryłoby, których rodzin protokołów wciąż brakuje. Jeśli chodzi o taki właśnie bank, miejscem na zgłoszenie tego jest zakładka Zgłoszenie banku.

Tylko podpis NestPay ma test na wzorcowym wektorze zgodny z opublikowanym przykładem samego banku. Każdy inny dostawca oznaczony jest w swoim kodzie źródłowym jako beta: przepływ jest zaimplementowany zgodnie z dokumentacją, ale nie został jeszcze zweryfikowany od początku do końca na działającym koncie sprzedawcy w tej instytucji. Ta etykieta zostaje, dopóki tak się nie stanie.

Instytucje płatnicze nie wydają kart, więc nie mają listy BIN. Wybiera się je jako własny POS, a nie kieruje się do nich kart.

Webhooki — gdzie zamówienie naprawdę się kończy

Każdy międzynarodowy dostawca potrzebuje jednego adresu na twojej stronie i ma on tę samą postać dla wszystkich: ?mevvpos-webhook=<provider> dopisane do twojego adresu głównego. Dokładna wartość jest wyświetlana jako pole tylko do odczytu na karcie Bank API; kliknięcie pola zaznacza je.

To webhook kończy zamówienie, a nie powrót klienta na twoją stronę. Adres powrotny można odgadnąć, a klient może na niego trafić, nawet nie zapłaciwszy, więc sama przeglądarka docierająca tam niczego nie dowodzi. MevvPos nigdy nie odczytuje wyniku z powrotu: albo czeka na podpisane powiadomienie, albo pyta dostawcę bezpośrednio, między serwerami. Dopóki nie nadejdzie jedna z tych dwóch odpowiedzi, zamówienie pozostaje oczekujące, a notatka zamówienia to potwierdza.

Skopiuj adres z karty Bank API.
Mollie stanowi wyjątek i nie wymaga niczego wklejania nigdzie: MevvPos wysyła adres wraz z każdą tworzoną płatnością. Jest on pomijany, gdy strona odpowiada pod adresem lokalnym, ponieważ Mollie i tak nie mogłoby go osiągnąć — w trakcie lokalnego programowania wynik pochodzi zamiast tego z zapytania o status.
Wklej go do panelu dostawcy dokładnie tak, jak się wyświetla. Square oblicza swój podpis na podstawie adresu powiadomienia razem z treścią, więc różnica choćby o jeden znak — wystarczy końcowy ukośnik — sprawia, że każde zdarzenie po cichu nie przechodzi weryfikacji.
Zapisz sekret podpisujący zwrócony przez dostawcę w dodatkowym polu tego dostawcy.
Wyślij zdarzenie testowe z panelu dostawcy i sprawdź, czy zamówienie rzeczywiście się przesuwa.

Mollie w ogóle nie podpisuje swojego powiadomienia — treść nie niesie nic poza identyfikatorem płatności. Wygląda to niebezpiecznie, a w rzeczywistości jest bezpieczniejsze: MevvPos nie ufa powiadomieniu, traktuje je jak dzwonek do drzwi. Bierze identyfikator i pyta bezpośrednio Mollie o status płatności, a zdarzenie powstaje tylko przy odpowiedzi paid. Napastnik może zadzwonić wymyślonym identyfikatorem, ale nie potrafi sfałszować odpowiedzi Mollie, więc sfałszowane powiadomienie nigdy nie może oznaczyć zamówienia jako opłacone. Jeśli nie można połączyć się z Mollie, odpowiedź brzmi „nie wiem” i nic się nie zmienia.

Podpis PayPal również nie jest weryfikowany lokalnie. To łańcuch certyfikatów, a cicha pomyłka przy weryfikacji łańcucha czyni podpis bezwartościowym; PayPal publikuje do tego celu punkt końcowy, a każda odpowiedź inna niż SUCCESS oznacza, że zdarzenie jest ignorowane.

Trzy zasady obowiązują dla każdego dostawcy. Odpowiedź to zawsze puste 200 — zweryfikowane zdarzenie, duplikat i śmieć dostają tę samą odpowiedź, bo inna odpowiedź powiedziałaby napastnikowi, która próba była bliższa, a odpowiedź błędu tylko skłoniłaby dostawcę do ponawiania zdarzenia, które nigdy się nie zweryfikuje. Jedynym wyjątkiem jest PayTR, który chce dosłownego tekstu OK i bez niego powtarza powiadomienie przez wiele godzin. To samo zdarzenie dostarczone dwukrotnie nie ma drugiego skutku. A to, wobec którego konta weryfikowane jest zdarzenie, odczytuje się z twojej własnej konfiguracji, nigdy z żądania — inaczej napastnik mógłby sam wskazać klucz, którym sprawdzana jest jego własna fałszywka.

Webhook nie przechodzi przez punkt końcowy WooCommerce. Ma własną zmienną zapytania i jest przechwytywany, zanim w ogóle zadziała motyw, strona i mechanizm zapytań — dlatego działa też na stronie bez zainstalowanego WooCommerce.

Kierowanie na podstawie BIN

Pierwsze sześć cyfr karty wskazuje bank, który ją wydał. Wtyczka MevvPos dopasowuje dokładnie po tych sześciu cyfrach.

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.
Wersja Pro odświeża ją co tydzień z naszych serwerów. Odświeżenie nakłada się na tabelę dostarczoną w pakiecie, zamiast ją zastępować: częściowa albo pusta odpowiedź nigdy nie może zostawić sklepu zupełnie bez danych BIN.
Odpowiedź niosąca mniej niż sto numerów BIN jest odrzucana jako niewiarygodna i nie zostaje zapisana.
Konflikty — ten sam numer BIN przypisywany przez dwa banki — rozstrzygane są po naszej stronie, zanim lista zostanie wysłana. Sklep rozstrzygający je lokalnie mógłby jednocześnie uznać kartę za „naszą” i skierować ją gdzie indziej.

Nierozpoznany numer BIN nigdy nie powoduje odmowy. Karta trafia wtedy do POS domyślnego. Odprawienie z kwitkiem karty, której po prostu nie ma w kartotece, byłoby utratą sprzedaży w obronie tabeli wyszukiwania.

Ta sama tabela odpowiada na stronie zamówienia na drugie, inne pytanie: czy ta karta pochodzi z banku tego POS? To właśnie decyduje o tym, czy proponowane są raty — patrz niżej.

Dokładność danych BIN nie jest funkcją płatną. Wersja Pro płaci za świeżość, a nie za poprawność: lista w pakiecie to ta sama lista, tyle że zamrożona w chwili kompilacji.

Raty i prowizja

Stawki ustawia się osobno dla każdego POS-a, od płatności jednorazowej po dwanaście rat, w zakładce Raty i prowizja. Są to wartości procentowe: dla 5,5% należy wpisać 5.50.

Działa to na obu powierzchniach zamówienia. Na stronie blokowej tabelę rat rysuje sam blok, a dopłata jest dodawana do koszyka jako opłata, dokładnie tak jak na stronie klasycznej, więc wybór raty aktualizuje sumę jeszcze przed złożeniem zamówienia.

Raty to turecka instytucja i karta o tym wie. Gdy wybrany jest dostawca międzynarodowy, siatka oprocentowania w ogóle się nie pokazuje, a karta zamiast tego mówi o tym jednym zdaniem: wypełnianie dwunastu wierszy, które nigdy nie mają zastosowania, byłoby sposobem na wprowadzenie cię w błąd.

0: Opcja jest pokazywana i nie dolicza się prowizji.
Puste: Opcja w ogóle nie jest pokazywana. Pusta wartość i zero to nie to samo.

Prowizja pojawia się w koszyku jako opłata podlegająca opodatkowaniu o nazwie „N Taksit Komisyonu”, liczona od sumy koszyka wraz z wysyłką i podatkiem.

Raty proponowane są wyłącznie na kartach wydanych przez bank danego POS, a pilnuje tego serwer — nie jest to jedynie ukryte w interfejsie. Karta z innego banku zostaje przymusowo sprowadzona do płatności jednorazowej, a opłata wyzerowana.

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.

Formularz ustawień zawsze pokazuje wszystkie dwanaście pól, niezależnie od licencji. Gdyby znikały po wygaśnięciu licencji, zapisanie strony po cichu usunęłoby już wprowadzone stawki. Pola powyżej limitu są oznaczone jako „Odblokowane w Pro”, a wpisane liczby zostają zachowane.

Nie ma tabeli rat dostarczanej przez bank. Stawki są tymi, które wpisze sprzedawca, a prowizja dla dawnego zamówienia liczona jest ze stawki obowiązującej w dniu sprzedaży — zmiana stawki dziś nie przepisuje wczorajszego raportu.

Przepływ płatności i obsługa karty

Każda turecka rodzina przechodzi przez 3-D Secure. Nie ma trybu bez 3D ani ustawienia, które by go wyłączało. Po stronie międzynarodowej MevvPos mówi w EMV 3-D Secure 2: zapisuje, czy płatnik został uwierzytelniony z dodatkową weryfikacją czy bez niej, kieruje klienta do banku, gdy wydawca jej zażąda, i odczytuje ECI, aby zapisać, czy odpowiedzialność za obciążenie zwrotne została przeniesiona. Dwóch rzeczy świadomie nie robi: nigdy nie występuje o wyłączenie, dla którego dostawca nie ma pola, i nigdy nie zapisuje odpowiedzialności jako Twojej, gdy dostawca nie przekazuje nam wyniku — „nie wiemy” i „odpowiedzialność spoczywa na akceptancie” to różne odpowiedzi.

Przepływ formularzowy: NestPay, Garanti, PayTR i Sipay: przeglądarka wysyła do banku podpisany formularz, klient się uwierzytelnia, a bank wraca do witryny.
Przepływ serwerowy: VakıfBank, iyzico i Craftgate: serwer witryny rozmawia z dostawcą, pobiera stronę 3-D, pokazuje ją i po uwierzytelnieniu domyka sprzedaż w komunikacji serwer–serwer.
Przepływ przekierowania: Stripe, PayPal, Mollie, Square, Checkout.com, Razorpay i Paystack: MevvPos tworzy płatność przez API REST dostawcy i wysyła klienta pod adres, który dostawca zwraca.
Przepływ formularza tokenu: Authorize.Net: dostawca zwraca token zamiast adresu, a token jest wysyłany metodą POST do jego hostowanej strony jako formularz. Zapisanie tokenu w adresie URL ujawniłoby go w historii przeglądarki i w logach serwera.

Tureckie banki zawsze wracają pod jeden adres na twojej stronie: ?wc-api=mevvpos_callback. Podpis przy tym powrocie jest weryfikowany kluczem POS-u, którego rzeczywiście użyło zamówienie, zapisanym w samym zamówieniu — przy więcej niż jednym POS weryfikacja niewłaściwym kluczem powoduje błąd hasha przy każdej płatności.

Karta nigdy nie trafia do bazy danych. Jest przechowywana w przeglądarce na czas przekierowania i usuwana później. Jeżeli nie ma jej tam w chwili wczytania strony płatności — nowa karta przeglądarki, odświeżenie, wyłączone przechowywanie, powrót z banku przyciskiem wstecz — pokazywany jest widoczny formularz karty, zamiast wysyłać do banku puste pola. Formularz karty jest domyślnie widoczny, i to celowo: przepływ płatności nie może zależeć od tego, czy JavaScript się wykonał.

Gdy bank zatwierdzi płatność, zamówienie zostaje ukończone nawet wtedy, gdy kod statusu 3-D był nieoczekiwany — notatka do zamówienia odnotowuje anomalię i prosi o potwierdzenie jej na ekranie samego banku. Skoro bank mówi „zatwierdzone”, klient został obciążony; odmowa oznaczałaby „karta została obciążona, ale zamówienie się nie powiodło”.

Każda próba zapisuje użyty POS, bank i numer BIN karty, liczbę rat i stawkę, wynik, kod i komunikat odpowiedzi banku oraz numery referencyjne autoryzacji i transakcji.

Preautoryzacja, linki płatności i reguły ryzyka

Autoryzuj teraz, pobierz później

Każdy rekord POS niesie metodę pobrania: natychmiastowe obciążenie albo zablokowanie kwoty i pobranie jej później. Przy drugiej opcji pieniądze są rezerwowane na karcie przy kasie, a ekran zamówienia zyskuje dwa przyciski — pobierz (całość albo część) i zwolnij. Pobierz, gdy paczka wychodzi; zwolnij, gdy nie możesz dostarczyć.

Ustawienie pojawia się tylko tam, gdzie dostawca rzeczywiście je obsługuje: rodzina banków NestPay (İşbank, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat) oraz Stripe, Authorize.Net i Checkout.com. Dla każdego innego dostawcy ten wybór w ogóle nie jest oferowany, zamiast być oferowanym i potem zawodzić na bramce.

Link do płatności

Ekran Linki płatności tworzy link na określoną kwotę i, opcjonalnie, opis oraz termin ważności. Osoba, która go otwiera, trafia na zwykłą stronę kasy sklepu z już utworzonym oczekującym zamówieniem, co oznacza to samo trasowanie BIN, tę samą tabelę rat i ten sam krok 3-D Secure co przy każdej innej płatności. Nic nie jest obejściem silnika płatności.

Token to 32 losowe bajty; adresu nie da się odgadnąć na podstawie innego.
Link wygasa w ustalonym przez ciebie terminie.
Działa jednorazowo. Po opłaceniu zamówienia link przestaje się otwierać, więc przekazana dalej wiadomość nie może zostać opłacona dwukrotnie.

Reguły ryzyka

Ekran Ryzyko zawiera pięć reguł, z których każda jest włączana osobno i ma własny próg. Są oceniane, zanim karta zostanie wysłana do jakiegokolwiek dostawcy, i każda z nich może oznaczyć zamówienie, wstrzymać je do weryfikacji albo od razu odrzucić.

Próby na adres — ile prób płatności może wykonać jeden odwiedzający w danym oknie czasowym.
Próby na kartę — ta sama liczba dla jednej karty.
Kolejne niepowodzenia — seria odrzuceń z rzędu.
Niezgodność kraju — karta wydana w Turcji z adresem rozliczeniowym poza Türkiye.
Pułap kwoty — suma zamówienia, powyżej której chcesz przyjrzeć się sprawie jako pierwszej.

Nie jest zapisywany żaden adres ani numer karty. To, co przechowują liczniki, to skrót solony własnym kluczem witryny, dzięki czemu reguły mogą rozpoznać powtórzenie bez zamieniania ekranu w drugą bazę danych kart. Nie ma odcisku urządzenia, wyniku wyuczonego maszynowo ani listy blokowanych BIN-ów — pięć reguł, które możesz przeczytać, i nic, czego nie mógłbyś wytłumaczyć klientowi.

Zwroty

Dla Międzynarodowi dostawcy zwroty wystawia się z ekranu zamówienia WooCommerce w zwykły sposób — w całości lub częściowo. MevvPos wysyła zwrot do dostawcy na podstawie referencji płatności zapisanej w zamówieniu.

Zwroty nigdy nie są ograniczane licencją. Niemożność oddania klientowi jego pieniędzy nie jest czymś, co może spowodować przypomnienie o odnowieniu, a w większości krajów jest to poza tym obowiązek prawny.

Tureckiego bankowego wirtualnego POS nie da się jeszcze zwrócić z poziomu WordPressa, a MevvPos mówi to wprost zamiast udawać. Zwróć transakcję z własnego ekranu swojego banku. Ciche zgłoszenie sukcesu sprawiłoby, że WooCommerce oznaczyłoby zamówienie jako zwrócone, podczas gdy pieniądze wciąż leżałyby w banku — błędny zapis księgowy kosztuje o wiele więcej niż niedziałający przycisk.

Zwrot wymaga referencji płatności zwróconej przez dostawcę. Zamówienia złożonego, zanim ta referencja została zapisana, albo takiego, którego konto dostawcy zostało od tego czasu usunięte, nie da się zwrócić przez wtyczkę.

Raporty

Zakładka Raporty pokazuje przychód, udane transakcje, wskaźnik skuteczności oraz podział na płatności jednorazowe i ratalne, wraz z wykresem dziennym. Transakcje wciąż czekające na odpowiedź banku liczone są osobno i nie wchodzą do wskaźnika skuteczności.

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

Obciążenie ratami i prowizją — liczba, przychód i obciążenie prowizją dla każdego progu rat.
Rozbicie na POS i banki — przychód, sukcesy, niepowodzenia i skuteczność dla każdego POS i każdego banku wydającego kartę.
Rozkład kodów odmowy — z eksportem CSV. Powtarzający się kod odmowy wskazuje na coś, co da się naprawić: brak środków to problem klienta, ale błędy weryfikacji 3-D i konfiguracji POS należą do sprzedawcy.

Dane stojące za raportami zbiera wtyczka darmowa, więc historia narasta niezależnie od tego, czy wersja Pro jest posiadana. Tak musi być: danych z przeszłości nie da się wygenerować wstecz w chwili przejścia na wyższą wersję.

Świeżo zainstalowany sklep nie ma wykresu. Zapisywanie zaczyna się wraz z wtyczką, a ekran zapełnia się po pierwszej próbie płatności.

Używanie silnika bez WooCommerce

Bramka WooCommerce jest teraz jednym z konsumentów silnika płatności, a nie samym silnikiem. Silnik nic nie wie o zamówieniach, koszykach ani sesjach: przekazujesz mu zamiar płatności — kwotę jako liczbę całkowitą w jednostkach podrzędnych, walutę, referencję i adresy powrotu — a on zwraca albo formularz do wysłania metodą POST, albo adres do przekierowania. Wtyczka formularzy, wtyczka rezerwacji albo twój własny kod może go obsługiwać w taki sam sposób, w jaki robi to kasa.

MevvPos_Payment_Engine::start() rozpoczyna płatność i zwraca informację, co przeglądarka powinna zrobić dalej.
MevvPos_Payment_Engine::handle_webhook() to jedyna ścieżka, która zmienia stan płatności. Zdarzenie, którego podpis się nie weryfikuje, niczego nie zmienia i zostaje zapisane.
MevvPos_Payment_Engine::webhook_url() buduje adres, który wklejasz do panelu dostawcy.
Limit rat jest stosowany również wewnątrz silnika, jako ostatnia linia obrony — wywołujący ekran mógł zostać wyrenderowany, zanim licencja wygasła.

Jeśli zarejestrowałeś własnego dostawcę przez filtr mevvpos_providers przed wersją 4.0.0, teraz otrzymuje on zamiar płatności zamiast WC_Order. Żądania i podpisy dla siedmiu tureckich rodzin pozostały niezmienione, więc istniejące konfiguracje POS działają dalej bez żadnych zmian.

Wnioski o banki i wsparcie

Zgłoszenie banku: Wymienia każdą instytucję, która nie została jeszcze zaimplementowana, wraz z powodem: albo nie ustalono rodziny protokołu, albo rodzina jest znana i czekamy na dokumentację. Można otworzyć wniosek dotyczący jednej z nich albo wskazać instytucję, której na liście w ogóle nie ma.
Wsparcie: Temat, którego POS lub banku dotyczy sprawa, co się dzieje przy jakim działaniu oraz komunikat o błędzie pokazany przez bank.

Formularz wsparcia prosi, aby nie podawać numeru karty ani kodu zabezpieczającego. Nigdy nie są one potrzebne do zdiagnozowania problemu z płatnością, a żaden z tych formularzy nie wysyła danych płatności ani danych karty.

Darmowa wtyczka kontaktuje się z naszymi serwerami tylko po naciśnięciu jednego z tych przycisków. Nic nie jest wysyłane według harmonogramu, a w edycji darmowej nie ma w ogóle żadnego wywołania licencji.

Free i 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.

Za darmo: 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.

Gdy licencja wygaśnie albo jej nie ma:

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.
Zwroty nadal działają, ponieważ w ogóle nie są ograniczane.
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.
Odświeżanie danych BIN na żywo zatrzymuje się; tabela z pakietu działa dalej.

Jeżeli nasze serwery są nieosiągalne, aktywna licencja działa jeszcze przez siedem dni na podstawie ostatniego udanego sprawdzenia. Licencja, której własna data ważności minęła, i tak czytana jest jako wygasła — inaczej zablokowanie naszego adresu byłoby sposobem na przedłużenie licencji o tydzień.

Aktualizacje

Wtyczka Pro niesie ze sobą aktualizator powiązany z twoją licencją. Musi tak być: Pro nie jest publikowana na WordPress.org, więc nie ma skąd WordPress mógłby dowiedzieć się, że istnieje nowa wersja. Przy aktywnej licencji aktualizacja Pro pojawia się na ekranie wtyczek jak każda inna.

Darmowa wtyczka ogłasza teraz również własne aktualizacje. Pyta nasz serwer, czy istnieje nowsza wersja, i przekazuje odpowiedź własnemu przepływowi aktualizacji WordPressa, więc nowe wydanie pojawia się na ekranie wtyczek ze zwykłym przyciskiem Aktualizuj, zamiast czekać, aż ktoś ręcznie pobierze zip. Żądanie niesie wyłącznie nazwę pakietu i zainstalowaną wersję — bez adresu witryny, bez adresu e-mail, bez klucza licencji, bez spisu wtyczek. Ponieważ nic w nim cię nie identyfikuje, zaufanie opiera się wyłącznie na podpisie: odpowiedź jest podpisana naszym kluczem Ed25519, a odpowiedź niepodpisana, źle podpisana, odtworzona ze starego znacznika czasu albo kierująca pobranie na host inny niż nasz zostaje odrzucona bez dotykania witryny. Twoje rekordy POS, poświadczenia i zebrana historia mieszkają w opcjach WordPressa i metadanych zamówień, a aktualizacja nigdy ich nie dotyka.

Gdy coś nie działa

Bank odrzuca każdą płatność bez użytecznego komunikatu: Prawie zawsze chodzi o podpis. Błędny podpis nigdzie nie wywołuje błędu — bank po prostu odmawia. Należy sprawdzić numer sprzedawcy, klucz sklepu oraz wszelkie dodatkowe dane dostępowe tej rodziny protokołów: wszystkie wchodzą do podpisu. Przydatny test polega na tym, że banki inaczej odpowiadają na błąd podpisu, a inaczej na nieprawidłową kartę; komunikat o „nieprawidłowej karcie” oznacza, że podpis jest poprawny.
„Hash error” przy powrocie, gdy POS jest więcej niż jeden: Powrót to osobne żądanie bez sesji. Wtyczka MevvPos zapisuje, którego POS użyło zamówienie, i weryfikuje właśnie tym kluczem. Jeżeli rekord POS, przez który opłacono zamówienie, został usunięty, weryfikacja spada na POS domyślny i może się nie powieść.
Klient płaci w Stripe lub PayPal, ale zamówienie pozostaje oczekujące: Adres webhooka jest nieosiągalny albo nie został zarejestrowany. Zamówienie kończy powiadomienie, a nie powrót klienta, więc brakujący webhook wygląda dokładnie tak samo jak klient, który nigdy nie zapłacił. Sprawdź, czy adres na karcie Bank API jest tym samym, który zapisano w panelu dostawcy, i czy dociera testowe zdarzenie dostawcy.
Wszystkie zdarzenia Square są odrzucane: Square podpisuje adres powiadomienia razem z treścią. Adres zarejestrowany w Square musi zgadzać się znak po znaku z tym na karcie Bank API — wystarczy końcowy ukośnik, http zamiast https albo www, które jedna strona ma, a druga nie.
Zdarzenia Authorize.Net nigdy się nie weryfikują: Signature key to wartość odrębna od Transaction Key i łatwo je ze sobą pomylić. Webhooki są weryfikowane wyłącznie kluczem Signature key.
Klient trafia na pustą stronę płatności albo przycisk Öde („Zapłać”) nic nie robi: Wtyczka pamięci podręcznej lub optymalizacji odracza skrypty. W LiteSpeed należy wyłączyć mevvpos, jquery i skrypty frontu WooCommerce z listy opóźnień. Formularz karty pokazywany jest domyślnie, więc przepływ nadal działa, ale automatyczne przekierowanie już nie.
Zamówienie pozostaje w stanie „oczekujące” po udanej płatności: Bank albo dostawca nie dotarł do adresu zwrotnego. Należy sprawdzić, czy ?wc-api=mevvpos_callback jest osiągalny z zewnątrz — tryb konserwacji, ograniczenie po adresie IP albo ściana logowania przed witryną go zablokują.
Formularz płatności wysyła dane z powrotem na tę samą stronę: Pole Gate URL jest puste dla banku, którego adres nie jest wypełniany z góry. Należy wpisać adres otrzymany od banku lub dostawcy.
Tryb testowy jest włączony, ale płatność i tak idzie do banku produkcyjnego: Tryb testowy zatrzymuje automatyczne przekierowanie i pokazuje ci żądanie; nie zmienia adresu bramki dla banków NestPay. Podczas testowania wpisz testowy adres swojego banku w polu Gate URL. W Stripe i Mollie ten przełącznik również nie zmienia adresu — tam to klucz testowy wybiera środowisko testowe (sandbox).
Raty się nie pojawiają: 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.
Po aktualizacji karty trafiają do niewłaściwego POS: Starsze wersje niosły ręcznie pisane zakresy BIN, które były częściowo błędne. Należy sprawdzić, czy każdy POS jest przypisany do banku, w którym naprawdę działa.
Ekran administracyjny wygląda na pozbawiony stylów albo poprawka się nie pojawia: Nieaktualna pamięć podręczna przeglądarki. Należy przeładować stronę z pominięciem bufora.

Ograniczenia

Poniższa lista jest zamierzona. Nic z tego nie jest błędem.

Brak zwrotów dla tureckiego bankowego wirtualnego POS. Żadna turecka rodzina nie ma wywołania zwrotu; zwróć z ekranu własnego banku. Międzynarodowi dostawcy to potrafi, a WooCommerce pokazuje dla nich przycisk zwrotu.
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.
Płatności cykliczne działają tylko z dostawcami międzynarodowymi i nie ma wyboru zapisanej karty. Zapisana zgoda na obciążenie jest tworzona, odnawiana, ponawiana i oznaczana jako zaległa, a produkt WooCommerce Subscriptions ustawia ją bez pisania kodu. Czego brakuje: tureckie rodziny bankowych wirtualnych POS nie mogą jej obsłużyć, kupujący nie wybierze zapisanej karty przy kasie, i nie ma ani harmonogramu monitów, ani anulowania z panelu.
Preautoryzacja istnieje, ale nie wszędzie. Terminal POS może zablokować kwotę i pobrać ją później — w całości lub części — z ekranu zamówienia, albo ją zwolnić. Obsługuje to tylko rodzina banków NestPay, Stripe, Authorize.Net i Checkout.com; u każdego innego dostawcy jest to sprzedaż bezpośrednia, a ustawienie w ogóle się dla nich nie pojawia.
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.
Obsługiwane są obie strony kasy. Zarówno klasyczny formularz płatności, jak i blok WooCommerce Checkout są obsługiwane, a tabela rat i jej dopłata zachowują się tak samo w obu przypadkach. Blok zapisuje wybrany BIN i liczbę rat przez Store API, więc dopłata jest obliczana przez ten sam kod co na klasycznej stronie.
3D Pay Hosting został celowo odrzucony. Hostowana strona usuwa zakres PCI, ale usuwa też BIN i tabelę rat — a cała wartość tureckiej strony leży w routingu, który one umożliwiają. Międzynarodowi dostawcy są hostowani właśnie dlatego, że tam nie ma czego kierować.
Brak edytora BIN. Tabelą zarządzamy my i jest ona łączona z odświeżeniem na żywo; nie ma ekranu do ręcznej edycji.
Dwadzieścia sześć instytucji jest wypisanych, ale niezaimplementowanych. Zostają widoczne, aby widoczna była luka.
Każdy dostawca poza NestPay ma samodzielnie zadeklarowany status beta, dopóki nie zostanie zweryfikowany od początku do końca na działającym koncie sprzedawcy.
Karty znajdują się wewnątrz strony. Pozycje z paska bocznego otwierają ekran wtyczki MevvPos; karty przełącza się na samej stronie.

To, co nigdy nie jest przechowywane w żadnej formie: numer karty, data ważności i kod bezpieczeństwa. Po stronie tureckiej jedyne przechowywane dane karty to pierwsze sześć cyfr i bank, który wskazują; przy międzynarodowych dostawcach nawet tego nie ma, ponieważ karta nigdy nie jest wpisywana na twojej stronie. Przechowywanie kodu bezpieczeństwa jest zabronione w każdych okolicznościach, a nawet zamaskowany ujawnia swoją długość.

Jeden silnik: turecki bankowy wirtualny POS i międzynarodowi dostawcy.