MevvPos — Mevvsoft-documentatie

Installatie

MevvPos vereist WordPress 6.0+ en PHP 8.1+. WooCommerce is optioneel. Met WooCommerce 9.0 of nieuwer actief registreert MevvPos zichzelf als betaalmethode bij het afrekenen; zonder WooCommerce laadt de betaalmotor nog steeds en kan hij door een andere plugin worden aangestuurd. Eerdere versies gaven WooCommerce op als harde afhankelijkheid en WordPress weigerde de activering zonder die plugin — die eis is vervallen.

Beide WooCommerce-afrekenoppervlakken worden ondersteund. MevvPos registreert zich zowel voor de klassieke shortcode-afrekenpagina als voor het nieuwere Checkout-blok. Tot 4.7.1 was alleen de klassieke pagina aangesloten; een winkel die overstapte op het blok-afrekenen verloor de kaartoptie volledig — geen fout, geen waarschuwing, alleen een ontbrekende betaalmethode. Er hoeft niets extra te worden ingesteld: op de blokpagina verschijnen de kaartvelden, de termijnentabel en de termijntoeslag op dezelfde manier.

Upload de plug-in via Plugins → Nieuwe plugin → Plugin uploaden en activeer die.
Open MevvPos in het linker beheermenu. Er is ook een snelkoppeling onder WooCommerce, waar verkopers doorgaans naar betaalinstellingen zoeken.
Zet op het tabblad Algemeen de betaalmethode aan en stel de titel in die de klant bij het afrekenen te zien krijgt.
Kies op Bank API uw provider — een Turkse bancaire virtuele POS of een van de internationale providers — en voer de gegevens in die u van hem hebt gekregen.
Als u een internationale provider hebt gekozen, kopieert u het Webhook-adres dat op datzelfde tabblad staat naar het eigen paneel van de provider. Zonder dat wordt niets voltooid.
Voer bij Termijnen en commissie uw termijntarieven in.
Test met de testgegevens van uw bank voordat u live gaat.

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

Pro is een aparte plugin, die naast de gratis versie wordt geïnstalleerd — geen vervanging ervan. De gratis plugin verschijnt op WordPress.org, waar alles wat gepubliceerd is onder de GPL herverspreid mag worden; de betaalde broncode in hetzelfde pakket houden zou hem juridisch herverspreidbaar hebben gemaakt door iedereen die de licentiecontroles verwijdert. De licentiesleutel wordt op het tabblad Licentie ingevoerd.

Als u WooCommerce → Instellingen → Betalingen → MevvPos opent, wordt u doorgestuurd naar het MevvPos-scherm. Dat is bewust: er is één plek voor deze instellingen, niet twee die elkaar kunnen tegenspreken.

Hoe het werkt

MevvPos spreekt twee soorten betaalprotocollen, en welke u krijgt volgt uit de provider die u hebt gekozen. Beide gaan door dezelfde motor en leveren hetzelfde bestelrecord op.

Ondertekend formulier — Türkiye: De zeven Turkse families van virtuele POS. MevvPos bouwt de betaalvelden, ondertekent ze met uw winkelsleutel en post ze naar de bank. De klant authenticeert met 3-D Secure en de bank keert terug naar uw site; de handtekening op die terugkeer is wat de bestelling voltooit.
Gehoste pagina en webhook — internationaal: Stripe, PayPal, Mollie, Square, Authorize.Net, Checkout.com, Razorpay en Paystack. MevvPos maakt de betaling bij de provider aan via diens REST-API en stuurt de klant naar de eigen pagina van de provider. De bestelling wordt afgerond door een antwoord van de provider: de ondertekende melding die uw webhookadres bereikt, of — als de klant eerder terugkomt — een server-naar-server-statusopvraging vanaf de retourpagina. Wat een bestelling nooit op eigen kracht afrondt, is de terugkeer van de browser.

Aan de Türkiye-kant doet de motor iets waar de internationale providers nooit behoefte aan hebben: hij beslist welk van uw accounts de kaart neemt.

U definieert een of meer POS-records. Een POS-record is de virtuele POS van één bank: de inloggegevens, het gatewayadres en de termijnpercentages ervan.
Bij het afrekenen typt de klant zijn kaart in. De eerste zes cijfers — de BIN — identificeren de bank die haar heeft uitgegeven.
MevvPos zoekt de BIN op en stuurt de betaling naar uw POS bij die bank, als u er een hebt. Anders valt ze terug op uw standaard-POS.
Termijnen worden alleen aangeboden wanneer de kaart bij de eigen bank van die POS hoort, want banken verlenen geen termijnen op kaarten van een andere bank.
De klant doorloopt 3D Secure bij de bank, en de bank keert terug naar één enkel callbackadres op uw site.
De handtekening op de terugweg wordt geverifieerd met de sleutel van de POS die de bestelling werkelijk heeft gebruikt, de bestelling wordt voltooid en het resultaat wordt vastgelegd.

Kaartnummer, vervaldatum en CVV worden nooit naar uw database of naar de WooCommerce-sessie geschreven. De enige kaartgegevens die bewaard worden, zijn de eerste zes cijfers en de herkende banknaam.

Bij de internationale providers bereikt er helemaal geen kaartgegevens uw site: de kaart wordt getypt op de eigen pagina van de provider. Dat maakt ze de kortste weg naar een kleine PCI-scope — en het is ook de reden waarom ze geen BIN-routering en geen termijnbetalingen kennen.

De internationale providers

De internationale providers dekken de wereld buiten Türkiye. Ze gebruiken allemaal de eigen gehoste of doorverwezen pagina van de provider, dus kaartgegevens worden nooit op uw site ingetypt. De authenticatie gebeurt daar ook, maar de uitkomst blijft daar niet: MevvPos legt vast of de betaler is geauthenticeerd, stuurt hem naar de bank wanneer de uitgever een extra verificatie vraagt, en leest de ECI om vast te leggen of de chargeback-aansprakelijkheid is overgegaan. Meldt een provider de uitkomst niet, dan wordt die als onbekend vastgelegd en niet als de uwe. Naast de kaart gaan lokale methoden mee in het eigen veld van elke provider: iDEAL, Bancontact, SEPA-incasso, Klarna, EPS, Przelewy24, BLIK, TWINT, Multibanco en wallets. U kiest welke een account aanbiedt, en een niet gekozen methode wordt nooit verstuurd. Een methode waarvan de valuta niet bij de bestelling past, valt meteen af — iDEAL aanbieden bij een dollarbestelling zou de betaling alleen bij de provider laten mislukken.

Stripe: Een Checkout Session in mode=payment, die achter Stripe's eigen pagina een Payment Intent aanmaakt. De geheime sleutel gaat in de handelaarssleutel en de Webhook signing secret in het extra veld. De bestelling wordt voltooid door een ondertekende payment_intent.succeeded. Elements wordt bewust niet gebruikt: het gebruiken zou de kaartvelden naar uw pagina verplaatsen en uw PCI-scope vergroten.
PayPal: Orders v2, in drie stappen: de bestelling aanmaken, de klant keurt hem goed bij PayPal, en MevvPos vangt hem. De derde stap is degene die het makkelijkst wordt gemist — een goedgekeurde bestelling die nooit wordt gevangen laat het geld ongeïnd terwijl de bestelling er betaald uitziet. De REST-clientId gaat in het handelaarsnummer, het clientgeheim in de handelaarssleutel, en de Webhook ID in het extra veld.
Mollie: Payments API v2. De API-sleutel — live_… of test_… — gaat in de handelaarssleutel en er is geen extra veld, omdat Mollie zijn meldingen niet ondertekent. Zie de webhooksectie hieronder voor wat MevvPos in plaats daarvan doet.
Square: Een Payment Link via de Checkout API. Voer het toegangstoken in als handelaarssleutel, plus de Location ID en de Webhook signature key. Square koppelt elke verkoop aan een locatie: zonder de Location ID kan er helemaal geen betaling worden aangemaakt, en Square's eigen foutmelding zegt dat niet duidelijk.
Authorize.Net: Accept Hosted. De API Login ID gaat in het handelaarsnummer, de Transaction Key in de handelaarssleutel, en de Signature key in het extra veld — een andere waarde dan de Transaction Key en makkelijk ermee te verwarren. Dit is de enige provider die geen doorverwijzingsadres teruggeeft: hij geeft een token terug dat MevvPos als formulier naar de gehoste pagina post.
Checkout.com: De Hosted Payments Page. De geheime sleutel (sk_…) gaat in de handelaarssleutel en de webhook-handtekeningsleutel in het extra veld; de melding wordt met HMAC-SHA256 over de ruwe body ondertekend. Eén gedrag om rekening mee te houden: een terugbetaling wordt asynchroon aanvaard. Checkout.com antwoordt op de terugbetalingsaanroep met 202 en een action-id, wat betekent dat het verzoek is aangenomen — niet dat het geld al terug is.
Razorpay: Een Payment Link, voor winkels die naar India verkopen, waar de kaart alleen niet volstaat en UPI, internetbankieren en wallets op de pagina van de provider samenkomen. De Key ID gaat in het handelaarsnummer, het Key Secret in de handelaarssleutel en het webhook-secret — een andere waarde dan het Key Secret — in het extra veld. Razorpay geeft twee identificatoren terug die niet uitwisselbaar zijn: met het link-id (plink_…) wordt de status opgevraagd, terwijl een terugbetaling alleen mogelijk is met het betaal-id (pay_…) dat de link meldt zodra hij betaald is.
Paystack: Een gehoste transactiepagina, voor winkels die verkopen naar Nigeria, Ghana, Zuid-Afrika, Kenia en Ivoorkust, waar USSD, bankoverschrijving en mobiel geld net zoveel tellen als de kaart. De geheime sleutel (sk_live_… of sk_test_…) gaat in de handelaarssleutel en er is geen extra veld — de melding wordt met HMAC-SHA512 en datzelfde geheim ondertekend. Alles hangt aan één referentie: het starten van de betaling, het opvragen van de status en het terugbetalen gebruiken die alle drie.

Testmodus schakelt bij PayPal, Square en Authorize.Net over naar het eigen sandbox-adres van de provider. Stripe en Mollie scheiden live van test via de sleutel in plaats van via het adres, dus daar bepaalt de sleutel die u plakt.

Bedragen worden van begin tot eind als gehele getallen in de kleinste eenheid van de valuta meegegeven — kuruş, centen — en nooit als decimale breuk. Mollie is de enige provider die een decimale tekenreeks terug wil, en wil precies het juiste aantal cijfers voor de valuta: 10.0 wordt geweigerd waar 10.00 wordt geaccepteerd. Die tekenreeks wordt opgebouwd uit het gehele getal, niet uit een float.

Geen van de acht is van begin tot eind geverifieerd met een echt handelsaccount. Elk providerbestand zegt dat in zijn eigen kop en noemt de documentatiepagina’s waaruit het is geschreven. De stromen volgen de gepubliceerde documentatie van de providers, en de handtekeningalgoritmen en veldnamen zijn daaraan vastgezet — maar dat is niet hetzelfde als een voltooide echte betaling, en zo zullen we het niet beschrijven. Lees ze als klaar om aan te sluiten en te testen tegen uw eigen sandbox, niet als bewezen in productie.

POS-records

De POS-balk staat boven de tabbladen en is op elk daarvan zichtbaar. Elke kaart toont de bank, het handelaarsnummer en een badge wanneer er iets uw aandacht nodig heeft.

Standaard: De POS die de betaling afhandelt wanneer er geen betere match wordt gevonden. Er is er altijd precies één.
Inactief: Bewaard, maar niet innend. Gebruik dit in plaats van verwijderen wanneer een POS is ingesteld maar bij de bank nog niet live is — een klant met een kaart van die bank zou anders niet kunnen betalen.
Wacht op een licentie: Het record bestaat, maar sluimert omdat de licentie niet actief is. Er is niets verwijderd; het gaat verder waar het gebleven was zodra de licentie is verlengd.
De API-gegevens zijn niet ingevuld: Het record heeft nog geen handelaarsnummer.

Banken worden weergegeven met een kleurstreep in plaats van een logo. Banklogo's zijn handelsmerken, en vijftien ervan betekent zowel juridisch risico als permanent onderhoud — u weet toch al welke bank de uwe is.

De laatste POS kan niet worden verwijderd en de laatst ingeschakelde kan niet worden uitgezet. Wilt u helemaal geen kaartbetalingen meer aannemen, zet dan de betaalmethode uit op het tabblad Algemeen.

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.

Als een licentie verloopt, wordt het account dat blijft innen niet willekeurig gekozen: het is het account dat als standaard is gemarkeerd, of anders het eerst geconfigureerde ingeschakelde account. Willekeurig kiezen zou betekenen dat een winkel op een ochtend stilletjes via een andere bank begint te innen.

Bank-API — inloggegevens en het gateway-adres

Provider: De lijst komt in twee groepen: Türkiye — bancaire virtuele POS en Internationale betalingsproviders. Alles wat het formulier u verder vraagt volgt uit deze ene keuze, en instellingen die niet op uw keuze van toepassing kunnen zijn, worden helemaal niet getoond.
Bank: Kies de bank waar uw POS loopt. Het gatewayadres en de voor termijnen gebruikte BIN-lijst volgen beide deze keuze. Instellingen zonder implementatie staan vermeld met '— yakında' en kunnen niet worden geselecteerd.
Merchantnummer (Client ID): Het handelaarsnummer dat de bank u heeft gegeven.
Merchant key (store key): De beveiligingssleutel van de handelaar. Opgeslagen als wachtwoordveld; na het opslaan wordt hij gemaskeerd getoond.
Gate URL: Het adres waarnaar het betaalformulier post.
Stuur de eigen valuta van de bestelling naar de bank: Alleen Turkse virtuele POS, en standaard uitgeschakeld: MevvPos stuurt Turkse lira, wat uw bank verwacht tenzij u een overeenkomst voor meerdere valuta's hebt. De valuta maakt deel uit van de handtekening, dus een waarde die uw bank niet accepteert wordt zonder uitleg geweigerd. De internationale providers nemen de valuta van de bestelling zoals ze is en krijgen deze vraag nooit.
Testmodus inschakelen: Stopt de automatische doorverwijzing zodat u het verzoek kunt inspecteren voordat het wordt verstuurd.

De Store Key leeg laten bij het opslaan betekent 'niet wijzigen'. De lege waarde wegschrijven zou de sleutel wissen en uw winkel zou zonder ook maar één foutmelding stoppen met betalingen aannemen. Dezelfde regel geldt voor de andere geheime velden.

Sommige families hebben extra gegevens nodig, en het formulier toont die alleen voor de provider die u hebt gekozen:

Garanti BBVA — Merchant ID, autorisatiegebruikersnaam, autorisatiewachtwoord.
VakıfBank — Terminal No, en een MPI-adres (laat het leeg om het testadres te gebruiken).
PayTR — Merchant Salt.
iyzico, Craftgate, Sipay — geen extra velden: de API-sleutel gaat in het Merchantnummer en het geheim in de Merchant key.
Stripe — Webhook signing secret.
PayPal — Webhook ID.
Square — Location ID en Webhook signature key.
Authorize.Net — Signature key, alleen gebruikt voor webhooks.
Mollie — geen extra velden: de API-sleutel gaat in Merchant key.

Deze extra inloggegevens gaan de handtekening in. Ontbreekt er een, dan wordt de handtekening met een lege waarde berekend en weigert de bank de betaling in stilte — geen fout, geen bericht, alleen een afwijzing.

Voor de zeven NestPay-banken wordt het gatewayadres ingevuld op basis van uw bankkeuze, dus Gate URL mag leeg blijven. Bij de andere is het veld niet vooringevuld: voer het adres in dat uw bank of aanbieder u heeft gegeven, anders heeft het betaalformulier nergens om naartoe te posten.

De dertien ondersteunde instellingen

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

Instellingen zonder implementatie blijven bewust in de banklijst staan, gemarkeerd met “— yakında”. Ze weghalen zou verbergen welke protocolfamilies nog ontbreken. Is de uwe er een van, dan is het tabblad Bankaanvraag de plek om dat te melden.

Alleen de NestPay-handtekening heeft een gouden-vectortest tegen het door de bank zelf gepubliceerde voorbeeld. Elke andere aanbieder is in zijn eigen broncode gemarkeerd als beta: de flow is geïmplementeerd volgens de documentatie, maar is nog niet van begin tot eind geverifieerd met een echt handelaarsaccount bij die instelling. Dat label blijft staan tot dat wel het geval is.

Betaalinstellingen geven geen kaarten uit, dus ze dragen geen BIN-lijst. U selecteert ze als uw POS in plaats van ernaartoe te routeren.

Webhooks — waar de bestelling echt wordt voltooid

Elke internationale provider heeft één adres op uw site nodig, en dat heeft bij allemaal dezelfde vorm: ?mevvpos-webhook=<provider> op uw hoofdadres. De exacte waarde staat alleen-lezen op het tabblad Bank API; klikken op het veld selecteert het.

Wat de bestelling voltooit is de webhook, niet de terugkeer van de klant naar uw site. Het terugkeeradres kan geraden worden en een klant kan het bereiken zonder betaald te hebben, dus een browser die daar aankomt bewijst op zichzelf niets. MevvPos leest het resultaat nooit af van de terugkeer: hij wacht ofwel op de ondertekende melding, ofwel vraagt hij het rechtstreeks aan de provider, server-naar-server. Totdat een van beide antwoorden binnenkomt, blijft de bestelling in behandeling en zegt een bestelnotitie dat.

Kopieer het adres van het tabblad Bank API.
Mollie is de uitzondering en vereist dat u nergens iets plakt: MevvPos stuurt het adres mee met elke betaling die het aanmaakt. Het wordt weggelaten als de site op een lokaal adres antwoordt, omdat Mollie het toch niet zou kunnen bereiken — tijdens lokale ontwikkeling komt het resultaat in plaats daarvan uit de statusopvraag.
Plak het precies zoals het verschijnt in het eigen paneel van de provider. Square berekent zijn handtekening over het meldingsadres samen met de body, dus één teken verschil — een afsluitende schuine streep is al genoeg — laat elke gebeurtenis stilletjes de verificatie missen.
Sla het ondertekeningsgeheim dat de provider teruggeeft op in het extra veld van die provider.
Stuur een testgebeurtenis vanuit het paneel van de provider en controleer of een bestelling daadwerkelijk verandert.

Mollie ondertekent zijn melding helemaal niet — de body bevat niets anders dan een betalings-id. Dat lijkt onveilig en is in feite veiliger: MevvPos vertrouwt de melding niet, het behandelt haar als een deurbel. Het neemt de id en vraagt Mollie rechtstreeks wat de status van de betaling is, en alleen een antwoord paid levert een gebeurtenis op. Een aanvaller kan de bel laten rinkelen met een verzonnen id, maar kan Mollie's antwoord niet vervalsen; een vervalste melding kan dus nooit een bestelling als betaald markeren. Als Mollie niet bereikbaar is, luidt het antwoord “ik weet het niet” en verandert er niets.

PayPal's handtekening wordt ook niet lokaal geverifieerd. Het is een certificaatketen, en een stille fout bij het verifiëren van een keten maakt de handtekening betekenisloos; PayPal publiceert daarvoor een eindpunt, en alles behalve SUCCESS betekent dat de gebeurtenis wordt genegeerd.

Voor elke provider gelden drie regels. Het antwoord is altijd een lege 200 — een geverifieerde gebeurtenis, een duplicaat en rommel krijgen allemaal hetzelfde antwoord, omdat een ander antwoord een aanvaller zou vertellen welke gok dichterbij zat, en een foutantwoord zou de provider alleen maar een gebeurtenis laten herhalen die nooit kan worden geverifieerd. PayTR is de enige uitzondering, omdat het de letterlijke tekst OK wil zien en de melding urenlang herhaalt zonder dat. Dezelfde gebeurtenis twee keer afgeleverd heeft geen tweede effect. En tegen welk account een gebeurtenis wordt geverifieerd, wordt gelezen uit uw eigen configuratie, nooit uit het verzoek — anders zou een aanvaller kunnen bepalen met welke sleutel zijn eigen vervalsing wordt gecontroleerd.

De webhook gaat niet via het eindpunt van WooCommerce. Hij heeft zijn eigen queryvariabele en wordt opgevangen voordat het thema, de pagina en de querymachinerie überhaupt draaien — wat ook is waarom hij werkt op een site zonder WooCommerce geïnstalleerd.

BIN-gebaseerde routering

De eerste zes cijfers van een kaart identificeren de bank die haar heeft uitgegeven. MevvPos matcht op precies die zes cijfers.

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 ververst haar wekelijks vanaf onze servers. De verversing legt zich over de meegeleverde tabel heen in plaats van die te vervangen: een gedeeltelijk of leeg antwoord mag een winkel nooit zonder BIN-gegevens achterlaten.
Een antwoord met minder dan honderd BIN's wordt als onaannemelijk afgewezen en niet weggeschreven.
Conflicten — dezelfde BIN geclaimd door twee banken — worden aan onze kant opgelost voordat de lijst wordt verstuurd. Een winkel die ze lokaal zou oplossen, zou een kaart tegelijk als 'de onze' kunnen tellen én ergens anders naartoe routeren.

Een onbekende BIN wordt nooit geweigerd. Die valt door naar uw standaard-POS. Een kaart afwijzen die we simpelweg niet in het bestand hebben, zou betekenen dat u een verkoop verliest om een opzoektabel te beschermen.

Dezelfde tabel beantwoordt bij het afrekenen een tweede, andere vraag: komt deze kaart van de eigen bank van deze POS? Dat bepaalt of er termijnen worden aangeboden — zie hieronder.

BIN-nauwkeurigheid is geen betaalde functie. Waar Pro voor betaalt is versheid, niet juistheid: de meegeleverde lijst is dezelfde lijst, alleen bevroren op het moment van de build.

Termijnen en commissie

De tarieven worden per POS ingesteld, van eenmalige afschrijving tot twaalf termijnen, op het tabblad Termijnen en commissie. Het zijn percentages: schrijf 5.50 voor 5,5%.

Dit werkt op beide afrekenoppervlakken. Op de blokpagina wordt de termijnentabel door het blok zelf getekend en de toeslag wordt als kosten aan de winkelwagen toegevoegd, precies als op de klassieke pagina, zodat het kiezen van een termijn het totaal bijwerkt vóórdat de bestelling wordt geplaatst.

Termijnbetalingen zijn een Turkse instelling en het tabblad weet dat. Terwijl een internationale provider geselecteerd is, wordt het tarievenrooster helemaal niet getoond, en het tabblad zegt dat in plaats daarvan in één zin: twaalf rijen invullen die nooit kunnen gelden, zou een manier zijn om u te misleiden.

0: De optie wordt getoond en er wordt geen commissie toegevoegd.
Leeg: De optie wordt helemaal niet getoond. Leeg en nul zijn niet hetzelfde.

De commissie verschijnt in de winkelwagen als een belastbare vergoeding met de naam 'N Taksit Komisyonu', berekend over het winkelwagentotaal inclusief verzending en belasting.

Termijnen worden alleen aangeboden op kaarten die zijn uitgegeven door de eigen bank van die POS, en dat wordt op de server afgedwongen — niet slechts verborgen in de interface. Een kaart van een andere bank wordt teruggedwongen naar een eenmalige betaling en de vergoeding wordt gewist.

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.

Het instellingenformulier toont altijd alle twaalf velden, welke licentie u ook hebt. Zouden ze verdwijnen wanneer een licentie verloopt, dan zou het opslaan van de pagina stilzwijgend tarieven wissen die u al had ingevoerd. Velden boven uw plafond zijn gemarkeerd met “Ontgrendeld in Pro” en uw getallen blijven bewaard.

Er is geen door de bank geleverde termijntabel. De percentages zijn die u invoert, en de commissie op een eerdere bestelling wordt berekend op basis van het percentage dat op de verkoopdag gold — vandaag een percentage wijzigen herschrijft het rapport van gisteren niet.

De betaalflow en de omgang met de kaart

Elke Turkse familie gaat via 3-D Secure. Er is geen niet-3D-modus en geen instelling om het uit te zetten. Aan de internationale kant spreekt MevvPos EMV 3-D Secure 2: het legt vast of de betaler met of zonder extra verificatie is geauthenticeerd, stuurt de klant naar de bank wanneer de uitgever daarom vraagt, en leest de ECI om vast te leggen of de chargeback-aansprakelijkheid is overgegaan. Twee dingen doet het bewust niet: het claimt nooit een vrijstelling waarvoor een provider geen veld heeft, en het rapporteert de aansprakelijkheid nooit als de uwe wanneer de provider ons de uitkomst niet meldt — “we weten het niet” en “de aansprakelijkheid ligt bij de handelaar” zijn verschillende antwoorden.

Formulierflow: NestPay, Garanti, PayTR en Sipay: de browser post een ondertekend formulier naar de bank, de klant authenticeert zich, en de bank keert terug naar uw site.
Serverflow: VakıfBank, iyzico en Craftgate: uw server praat met de aanbieder, haalt de 3D-pagina op, toont die en rondt de verkoop na de authenticatie server-naar-server af.
Doorverwijzingsstroom: Stripe, PayPal, Mollie, Square, Checkout.com, Razorpay en Paystack: MevvPos maakt de betaling aan via de REST-API van de provider en stuurt de klant naar het adres dat de provider teruggeeft.
Tokenformulierstroom: Authorize.Net: de provider geeft in plaats van een adres een token terug, en het token wordt als formulier naar de gehoste pagina gepost. Het token in een URL schrijven zou het laten lekken in de browsergeschiedenis en serverlogs.

De Turkse banken keren altijd terug naar één adres op uw site: ?wc-api=mevvpos_callback. De handtekening op die terugkeer wordt geverifieerd met de sleutel van de POS die de bestelling daadwerkelijk heeft gebruikt, vastgelegd op de bestelling zelf — met meer dan één POS levert verifiëren met de verkeerde sleutel bij elke betaling een hashfout op.

De kaart bereikt uw database nooit. Ze wordt voor de duur van de doorverwijzing in de browser bewaard en daarna verwijderd. Is ze er niet wanneer de betaalpagina laadt — een nieuw tabblad, een verversing, uitgeschakelde opslag, een terugnavigatie vanaf de bank — dan wordt er een zichtbaar kaartformulier getoond in plaats van lege velden naar de bank te sturen. Het kaartformulier is standaard zichtbaar, met opzet: een betaalflow mag niet afhangen van het feit dat JavaScript heeft gedraaid.

Keurt de bank de betaling goed, dan wordt de bestelling voltooid, ook als de 3D-statuscode onverwacht was — een bestelnotitie legt de afwijking vast en vraagt u die te bevestigen vanaf het scherm van de bank zelf. Zegt de bank goedgekeurd, dan is de klant belast; dat weigeren zou betekenen: 'uw kaart is belast maar uw bestelling is mislukt'.

Elke poging legt de gebruikte POS vast, de bank en de BIN van de kaart, het aantal termijnen en het percentage, het resultaat, de antwoordcode en het bericht van de bank, en de autorisatie- en transactiereferenties.

Pre-autorisatie, betaallinks en risicoregels

Nu autoriseren, later incasseren

Elk POS-record draagt een incassomethode: direct afschrijven, of het bedrag vasthouden en later incasseren. Bij de tweede optie wordt het geld bij het afrekenen op de kaart gereserveerd en krijgt het bestelscherm twee knoppen — incasseren (alles, of een deel) en vrijgeven. Incasseer zodra het pakket vertrekt; geef vrij als je niet kunt leveren.

De instelling verschijnt alleen waar de provider dit echt ondersteunt: de NestPay-bankfamilie (İşbank, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat) plus Stripe, Authorize.Net en Checkout.com. Bij elke andere provider wordt de keuze helemaal niet aangeboden, in plaats van aangeboden en dan mislukkend bij de gateway.

Een betaallink

Het scherm Betaallinks maakt een link aan voor een bedrag en, optioneel, een omschrijving en een vervaldatum. Wie hem opent, komt terecht op de gewone checkout van de winkel met een openstaande bestelling die al is aangemaakt, wat betekent dezelfde BIN-routering, dezelfde termijnentabel en dezelfde 3-D Secure-stap als elke andere betaling. Niets is een sluiproute langs de betaalmotor.

Het token bestaat uit 32 willekeurige bytes; het adres kan niet uit een ander worden geraden.
De link verloopt op de datum die je instelt.
Hij werkt eenmalig. Nadat de bestelling betaald is, opent de link niet meer, zodat een doorgestuurd bericht niet twee keer betaald kan worden.

Risicoregels

Het scherm Risico bevat vijf regels, elk apart aan te zetten en met een eigen drempelwaarde. Ze worden geëvalueerd voordat de kaart naar een provider wordt gestuurd, en elke regel kan de bestelling markeren, voor controle vasthouden of rechtstreeks afwijzen.

Pogingen per adres — hoeveel betaalpogingen één bezoeker binnen een tijdvenster mag doen.
Pogingen per kaart — hetzelfde aantal voor één kaart.
Opeenvolgende mislukkingen — een reeks afwijzingen achter elkaar.
Landmismatch — een in Turkije uitgegeven kaart met een factuuradres buiten Türkiye.
Bedragplafond — een besteltotaal waarboven je eerst wilt kijken.

Er wordt geen adres en geen kaartnummer vastgelegd. Wat de tellers bijhouden is een digest gezouten met je eigen sitesleutel, zodat de regels een herhaling kunnen herkennen zonder dat het scherm ooit een tweede kaartdatabase wordt. Er is geen apparaat-vingerafdruk, geen door machine learning gegenereerde score en geen BIN-blokkeerlijst — vijf regels die je kunt lezen, en niets wat je een klant niet kunt uitleggen.

Terugbetalingen

Bij de internationale providers worden terugbetalingen op de gebruikelijke manier uitgegeven vanuit het WooCommerce-bestelscherm — volledig of gedeeltelijk. MevvPos stuurt de terugbetaling naar de provider op basis van de betalingsreferentie die op de bestelling is vastgelegd.

Terugbetalingen worden nooit door de licentie geblokkeerd. Een klant zijn geld niet kunnen teruggeven is niet iets wat een verlengingsherinnering mag veroorzaken, en in de meeste landen is het bovendien een wettelijke verplichting.

Turkse bancaire virtuele POS kan nog niet vanuit WordPress worden terugbetaald, en MevvPos zegt dat gewoon in plaats van net te doen alsof. Betaal de transactie terug vanuit het eigen scherm van uw bank. Stilletjes succes melden zou WooCommerce de bestelling laten markeren als terugbetaald terwijl het geld nog bij de bank ligt — een verkeerd boekhoudkundig record kost veel meer dan een knop die niet werkt.

Een terugbetaling heeft de betalingsreferentie nodig die de provider heeft teruggegeven. Een bestelling die is geplaatst voordat die referentie werd vastgelegd, of een bestelling waarvan het provideraccount sindsdien is verwijderd, kan niet via de plugin worden terugbetaald.

Rapporten

Het tabblad Rapporten toont de omzet, de geslaagde transacties, het slagingspercentage en de verdeling tussen eenmalige afschrijving en termijnen, met een dagelijkse grafiek. Transacties die nog op antwoord van de bank wachten, worden apart geteld en blijven buiten het slagingspercentage.

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

Termijn- en commissielast — aantal, omzet en commissielast per termijnschijf.
Uitsplitsing per POS en bank — omzet, successen, mislukkingen en slagingspercentage voor elke POS en voor elke uitgevende bank.
Verdeling van afwijzingscodes — met CSV-export. Een terugkerende afwijzingscode wijst op iets dat u kunt verhelpen: onvoldoende saldo is het probleem van de klant, maar fouten in de 3D-verificatie en in de POS-configuratie zijn de uwe.

De gegevens achter de rapporten worden verzameld door de gratis plug-in, dus de geschiedenis blijft groeien of u nu Pro hebt of niet. Dat moet zo zijn: gegevens uit het verleden kunnen bij een upgrade niet met terugwerkende kracht worden gegenereerd.

Een net geïnstalleerde winkel heeft geen grafiek. De registratie begint met de plug-in, en het scherm vult zich na de eerste betaalpoging.

De motor gebruiken zonder WooCommerce

De WooCommerce-gateway is nu één afnemer van de betaalmotor in plaats van de motor zelf. De motor weet niets van bestellingen, winkelwagens of sessies: u geeft hem een betalingsintentie — een bedrag als geheel getal in kleinste eenheden, een valuta, een referentie en de terugkeeradressen — en hij geeft terug ofwel een te posten formulier ofwel een adres om naartoe door te verwijzen. Een formulierplugin, een boekingsplugin of uw eigen code kan hem op dezelfde manier aansturen als de checkout doet.

MevvPos_Payment_Engine::start() start een betaling en geeft terug wat de browser vervolgens moet doen.
MevvPos_Payment_Engine::handle_webhook() is het enige pad dat de status van een betaling verandert. Een gebeurtenis waarvan de handtekening niet klopt, verandert niets en wordt vastgelegd.
MevvPos_Payment_Engine::webhook_url() bouwt het adres dat u in het paneel van de provider plakt.
Het termijnplafond wordt ook binnen de motor toegepast, als laatste verdedigingslinie — het aanroepende scherm kan al zijn weergegeven voordat de licentie verliep.

Als u vóór versie 4.0.0 uw eigen provider hebt geregistreerd via het mevvpos_providers-filter, ontvangt die nu een betalingsintentie in plaats van een WC_Order. De verzoeken en handtekeningen voor de zeven Turkse families zijn ongewijzigd, dus bestaande POS-opstellingen blijven ongewijzigd werken.

Bankverzoeken en ondersteuning

Bankaanvraag: Somt elke instelling op die nog niet is geïmplementeerd, met de reden: ofwel is de protocolfamilie niet vastgesteld, ofwel is de familie bekend en wachten we op documentatie. U kunt een verzoek openen voor er een, of een instelling noemen die helemaal niet in de lijst staat.
Ondersteuning: Een onderwerp, de betrokken POS of bank, wat er gebeurt wanneer u wat doet, en de foutmelding die de bank toonde.

Het ondersteuningsformulier vraagt u geen kaartnummer of beveiligingscode op te nemen. Die zijn nooit nodig om een betaalprobleem vast te stellen, en met geen van beide formulieren worden betaal- of kaartgegevens meegestuurd.

De gratis plug-in neemt alleen contact op met onze servers wanneer u op een van deze knoppen drukt. Er wordt niets volgens een schema verstuurd en in de gratis editie is er helemaal geen licentieoproep.

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

Gratis: 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.

Wanneer een licentie verloopt of ontbreekt:

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.
Terugbetalingen blijven werken, omdat ze helemaal niet worden geblokkeerd.
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.
De live BIN-verversing stopt; de meegeleverde tabel blijft werken.

Zijn onze servers onbereikbaar, dan blijft een actieve licentie zeven dagen werken op grond van de laatste geslaagde controle. Maar een licentie waarvan de eigen vervaldatum is verstreken, geldt hoe dan ook als verlopen — anders zou ons adres blokkeren een manier zijn om een licentie met een week te verlengen.

Updates

De Pro-plugin heeft een updater die aan uw licentie is gekoppeld. Dat moet ook: Pro wordt niet op WordPress.org gepubliceerd, dus er is nergens waar WordPress kan leren dat er een nieuwe versie bestaat. Met een actieve licentie verschijnt een Pro-update op het pluginscherm zoals elke andere.

De gratis plugin kondigt nu ook zijn eigen updates aan. Hij vraagt onze server of er een nieuwere versie bestaat en geeft het antwoord door aan WordPress’ eigen updatestroom, zodat een nieuwe versie op het pluginscherm verschijnt met een gewone Bijwerken-knop in plaats van te wachten tot iemand handmatig een zip ophaalt. Het verzoek draagt alleen de pakketnaam en de geïnstalleerde versie — geen siteadres, geen e-mailadres, geen licentiesleutel, geen plugin-inventaris. Omdat niets erin u identificeert, rust het vertrouwen volledig op de handtekening: het antwoord is ondertekend met onze Ed25519-sleutel, en een antwoord dat niet is ondertekend, verkeerd is ondertekend, opnieuw is afgespeeld vanaf een oud tijdstempel of de download naar een andere host dan de onze wijst, wordt weggegooid zonder de site aan te raken. Uw POS-records, inloggegevens en verzamelde geschiedenis staan in WordPress-opties en bestelmetadata, en een update raakt ze nooit aan.

Wanneer iets niet werkt

De bank weigert elke betaling zonder bruikbaar bericht: Bijna altijd de handtekening. Een verkeerde handtekening veroorzaakt nergens een fout — de bank weigert gewoon. Controleer het handelaarsnummer, de store key en alle extra inloggegevens van die familie: ze gaan allemaal de handtekening in. Een nuttige test is dat banken een handtekeningfout en een ongeldige kaart verschillend beantwoorden; krijgt u een melding 'ongeldige kaart', dan klopt uw handtekening.
'Hashfout' op de terugweg, met meer dan één POS: De terugkeer is een apart verzoek zonder sessie. MevvPos legt vast welke POS een bestelling heeft gebruikt en verifieert met die sleutel. Hebt u het POS-record verwijderd waarmee een bestelling is betaald, dan valt de verificatie terug op de standaard-POS en kan ze mislukken.
De klant betaalt bij Stripe of PayPal maar de bestelling blijft in behandeling: Het webhookadres is niet bereikbaar of niet geregistreerd. De bestelling wordt voltooid door de melding, niet door de terugkeer van de klant, dus een ontbrekende webhook ziet er precies zo uit als een klant die nooit heeft betaald. Controleer of het adres op het tabblad Bank API hetzelfde is als het adres dat is opgeslagen in het paneel van de provider, en of de testgebeurtenis van de provider aankomt.
Alle Square-gebeurtenissen worden geweigerd: Square ondertekent het meldingsadres samen met de body. Het bij Square geregistreerde adres moet karakter voor karakter overeenkomen met dat op het tabblad Bank API — een afsluitende schuine streep, http in plaats van https, of een www die de ene kant wel en de andere niet heeft, is al genoeg.
Authorize.Net-gebeurtenissen worden nooit geverifieerd: De Signature key is een aparte waarde ten opzichte van de Transaction Key en de twee worden makkelijk verwisseld. Webhooks worden alleen met de Signature key geverifieerd.
De klant komt op een lege betaalpagina, of de Öde-knop doet niets: Een cache- of optimalisatieplug-in stelt scripts uit. Sluit bij LiteSpeed mevvpos, jquery en de WooCommerce-front-endscripts uit van de vertragingslijst. Het kaartformulier wordt standaard getoond zodat de flow toch werkt, maar de automatische doorverwijzing werkt niet.
De bestelling blijft 'in afwachting' na een geslaagde betaling: De bank of de aanbieder heeft het callbackadres niet bereikt. Controleer of ?wc-api=mevvpos_callback van buitenaf bereikbaar is — een onderhoudsmodus, een IP-beperking of een inlogmuur vóór de site blokkeert dat.
Het betaalformulier post terug naar dezelfde pagina: Het veld Gate URL is leeg voor een bank waarvan het adres niet vooringevuld is. Voer het adres in dat uw bank of aanbieder u heeft gegeven.
De testmodus staat aan maar de betaling gaat toch naar de echte bank: Testmodus stopt de automatische doorverwijzing en toont u het verzoek; hij herschrijft niet het gateway-adres voor de NestPay-banken. Zet het testadres van uw bank tijdens het testen in Gate URL. Bij Stripe en Mollie verandert de schakelaar het adres ook niet — daar is het de testsleutel die de sandbox selecteert.
Er verschijnen geen termijnen: 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.
Kaarten gaan na een upgrade naar de verkeerde POS: Oudere versies droegen handgeschreven BIN-reeksen die deels onjuist waren. Controleer of elke POS is ondergebracht bij de bank waar hij werkelijk loopt.
Het beheerscherm ziet er ongestyled uit, of een oplossing verschijnt niet: Een verouderde browsercache. Herlaad de pagina met omzeiling van de cache.

Grenzen

De onderstaande lijst is bewust zo. Niets daarvan is een bug.

Geen terugbetalingen voor Turkse bank-virtual-POS. Geen Turkse familie kent een terugbetalingsaanroep; betaal terug via het scherm van je eigen bank. De de internationale providers doen dat wel, en WooCommerce toont voor hen de terugbetaalknop.
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.
Terugkerende betalingen werken alleen met de internationale providers, en er is geen keuze voor opgeslagen kaarten. Een opgeslagen incassomachtiging wordt aangemaakt, vernieuwd, opnieuw geprobeerd en als achterstallig gemarkeerd, en een WooCommerce Subscriptions-product zet er zonder code een op. Wat ontbreekt: de Turkse bank-virtual-POS-families kunnen er geen dragen, een klant kan bij het afrekenen geen opgeslagen kaart kiezen, en er is geen aanmaanschema of annuleren vanuit de beheerder.
Pre-autorisatie bestaat, maar niet overal. Een POS kan het bedrag vasthouden en het later — geheel of gedeeltelijk — vanuit het bestelscherm incasseren, of vrijgeven. Alleen de NestPay-bankfamilie, Stripe, Authorize.Net en Checkout.com ondersteunen dit; bij elke andere provider is het een directe verkoop en wordt de instelling niet getoond.
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 checkouts worden ondersteund. Zowel het klassieke betaalformulier als het WooCommerce Checkout-blok worden bediend, en de termijnentabel en het toeslagbedrag gedragen zich bij beide hetzelfde. Het blok schrijft de gekozen BIN en het termijnaantal via de Store API weg, zodat de toeslag door dezelfde code wordt berekend als op de klassieke pagina.
3D Pay Hosting is bewust afgewezen. De gehoste pagina verwijdert de PCI-scope, maar verwijdert ook de BIN- en termijntabel — en de hele waarde van de Türkiye-kant zit in de routering die ze mogelijk maken. De internationale providers zijn juist gehost omdat daar niets te routeren valt.
Geen BIN-editor. De tabel wordt door ons beheerd en samengevoegd met de live verversing; er is geen scherm om die met de hand te bewerken.
Zesentwintig instellingen staan vermeld maar zijn niet geïmplementeerd. Ze blijven zichtbaar zodat het gat zichtbaar blijft.
Elke aanbieder behalve NestPay is zelfverklaard beta tot hij van begin tot eind is geverifieerd met een echt handelaarsaccount.
De tabbladen zitten in de pagina. De items in de zijbalk openen het MevvPos-scherm; van tabblad wisselt u op de pagina zelf.

Wat in geen enkele vorm ooit wordt opgeslagen: het kaartnummer, de vervaldatum en de beveiligingscode. Aan de Türkiye-kant zijn de enige bewaarde kaartgegevens de eerste zes cijfers en de bank die ze aanduiden; bij de internationale providers zelfs dat niet, omdat de kaart nooit op uw site wordt getypt. De beveiligingscode opslaan is onder alle omstandigheden verboden, en zelfs een gemaskeerde versie lekt de lengte ervan.

Eén motor: Turkse bancaire virtuele POS en de internationale providers.