MevvPos Documentation

Installatie

MevvPos heeft WordPress 6.0+, PHP 8.1+ en WooCommerce 9.0 of nieuwer nodig. WooCommerce is een harde afhankelijkheid, verklaard in de plug-inheader: zonder WooCommerce weigert WordPress de activering, en op oudere WordPress-versies doet de plug-in eenvoudigweg niets.

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 bij Bank-API uw bank en voer de inloggegevens in die zij u heeft gegeven.
Voer bij Termijnen en commissie uw termijntarieven in.
Test met de testgegevens van uw bank voordat u live gaat.

De gratis editie maakt geen databasetabellen aan en registreert geen geplande taak. Alles leeft in WordPress-opties en in de bestelmeta.

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

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.

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.

De gratis editie staat één POS toe. Extra records zijn een Pro-mogelijkheid — en daarmee ook, als gevolg, BIN-routering: met één POS valt er niets te routeren.

Bank-API — inloggegevens en het gateway-adres

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.
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 inloggegevens nodig, en het formulier toont ze alleen voor de bank 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.

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.

BIN-gebaseerde routering

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

Een momentopname van de BIN-tabel wordt met de plug-in meegeleverd — 1.449 BIN's over 36 banken in de huidige build — zodat routering offline werkt, in de gratis editie, vanaf het moment dat u installeert.
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%.

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.

De gratis editie toont de klant hoogstens drie termijnen; Pro tilt het plafond naar twaalf. Het plafond wordt op drie plaatsen toegepast: de lijst die de klant ziet, de waarde die met het formulier binnenkomt, en de waarde die naar de bank gaat. Die laatste doet ertoe, want een waarde die is gekozen toen de licentie nog geldig was, kan in de sessie voortleven.

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 familie gaat door 3D Secure. Er is geen niet-3D-modus en geen instelling om het uit te zetten.

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.

De bank keert altijd terug naar één adres op uw site: ?wc-api=mevvpos_callback. De handtekening van die terugkeer wordt geverifieerd met de sleutel van de POS die de bestelling werkelijk 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.

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.

De gratis editie rapporteert over een vast venster van 30 dagen. Pro voegt bereiken van 7 / 30 / 90 dagen toe en drie uitsplitsingen:

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.

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

De splitsing zit in de hoeveelheid, niet in de mogelijkheden. Alle dertien instellingen, 3D Secure, testmodus, onbeperkt transactievolume en het basisomzetrapport zitten in de gratis editie.

Gratis: Eén POS. Hoogstens drie termijnen getoond aan de klant. Een vaste omzetsamenvatting over 30 dagen. De met de plug-in meegeleverde BIN-tabel.
Pro: Onbeperkt aantal POS-records — en dus BIN-routering. Tot twaalf termijnen. Rapportbereiken en de uitsplitsingen per POS, bank, termijn en afwijzingscode, met CSV-export. Wekelijkse live BIN-verversing. Automatische updates voor de Pro-plug-in zelf.

Wanneer een licentie verloopt of ontbreekt:

Uw winkel blijft betalingen aannemen. Er zit nergens op het betaalpad een licentiecontrole. De omzet van een winkel afsnijden is geen aanvaardbare manier om aan een verlenging te herinneren.
De standaard-POS blijft werken, inclusief 3D Secure en testmodus.
Extra POS-records gaan in de sluimerstand maar worden nooit verwijderd, inclusief de inloggegevens. Ze hervatten bij de verlenging.
Het termijnplafond valt terug naar drie. Percentages die u daarboven hebt ingevoerd, blijven bewaard en worden niet gewist.
De rapporten vallen terug op de samenvatting over 30 dagen. De verzamelde geschiedenis wordt niet verwijderd.
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.

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 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: De testmodus stopt de automatische doorverwijzing en toont u het verzoek; hij herschrijft het gatewayadres voor de NestPay-banken niet. Zet tijdens het testen het testadres van uw bank in Gate URL.
Er verschijnen geen termijnen: Ofwel is het percentage voor dat aantal leeg in plaats van nul, ofwel komt de kaart van een andere bank, ofwel zit u boven het plafond van drie in de gratis editie.
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 of annuleringen vanuit WordPress. De plug-in implementeert de terugbetaal-API van WooCommerce niet en geen enkele aanbieder draagt een terugbetaalaanroep. Betaal terug vanaf het eigen scherm van uw bank.
Alleen Turkse lira. De valutacode ligt bij elke aanbieder vast; er is geen instelling voor meerdere valuta's.
Geen opgeslagen kaarten, geen tokenisatie, geen abonnementen of terugkerende betalingen.
Geen pre-autorisatie. Elke transactie is een directe verkoop.
Geen regelgebaseerde routering. Er wordt uitsluitend gerouteerd op uitgevende bank — niet op bedrag, kaartmerk of land.
Het betaalformulier is geschreven voor de klassieke WooCommerce-afrekenpagina. Voor de blokgebaseerde afrekenpagina zit er geen aparte component in het pakket.
3D Pay Hosting is bewust verworpen. De gehoste pagina haalt de PCI-scope weg, maar ook de BIN en de termijntabel — en de hele waarde van deze plug-in zit in de routering die zij mogelijk maken.
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 wordt opgeslagen: het kaartnummer, de vervaldatum en de beveiligingscode. De enige kaartgegevens die bewaard worden, zijn de eerste zes cijfers en de bank die ze aanwijzen. De beveiligingscode opslaan is onder alle omstandigheden verboden, en zelfs een gemaskeerde verklapt zijn lengte.

Van één virtuele POS naar een kaart die naar de uitgevende bank wordt geleid.