MevvPos — Documentation Mevvsoft

Installation

MevvPos nécessite WordPress 6.0+ et PHP 8.1+. WooCommerce est optionnel. Avec WooCommerce 9.0 ou plus récent actif, MevvPos s’enregistre lui-même comme méthode de paiement au moment du paiement ; sans lui, le moteur de paiement se charge quand même et peut être piloté par une autre extension. Les versions antérieures déclaraient WooCommerce comme dépendance obligatoire et WordPress refusait l’activation sans lui — cette exigence a disparu.

Les deux surfaces de paiement de WooCommerce sont couvertes. MevvPos s’enregistre aussi bien pour la page de paiement classique par shortcode que pour le nouveau bloc Paiement. Jusqu’à la 4.7.1, seule la page classique était raccordée : une boutique passée au paiement par blocs perdait purement et simplement l’option carte — sans erreur, sans avertissement, juste un moyen de paiement absent. Rien de plus à régler : sur la page en blocs, les champs de carte, le tableau des échéances et les frais d’échelonnement s’affichent de la même façon.

Téléversez l’extension via Extensions → Ajouter → Téléverser une extension et activez-la.
Ouvrez MevvPos dans le menu d’administration de gauche. Il existe aussi un raccourci sous WooCommerce, là où les marchands ont l’habitude de chercher les réglages de paiement.
Dans l’onglet Général, activez le moyen de paiement et définissez le titre que la clientèle verra au moment de la commande.
Dans Bank API, choisissez votre fournisseur — un POS virtuel bancaire turc ou l’un des fournisseurs internationaux — et saisissez les identifiants qu’il vous a fournis.
Si vous avez choisi un fournisseur international, copiez l’adresse du webhook affichée sur ce même onglet dans le panneau du fournisseur. Rien ne se finalise sans elle.
Dans Mensualités et commission, saisissez vos taux de mensualités.
Testez avec les identifiants de test de votre banque avant de passer en production.

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

Pro est une extension distincte, installée à côté de la version gratuite — elle ne la remplace pas. L’extension gratuite est publiée sur WordPress.org, où tout ce qui est publié peut être redistribué sous la GPL ; garder le code payant dans le même paquet l’aurait rendu légalement redistribuable par quiconque aurait supprimé les vérifications de licence. La clé de licence se saisit dans l’onglet Licence.

Ouvrir WooCommerce → Réglages → Paiements → MevvPos vous redirige vers l’écran MevvPos. C’est délibéré : il y a un seul endroit pour ces réglages, pas deux qui pourraient se contredire.

Comment ça marche

MevvPos parle deux types de protocole de paiement, et celui que vous obtenez découle du fournisseur choisi. Les deux passent par le même moteur et produisent le même enregistrement de commande.

Formulaire signé — Türkiye: Les sept familles de POS virtuels turcs. MevvPos construit les champs de paiement, les signe avec votre clé de magasin et les envoie par POST à la banque. Le client s’authentifie avec 3-D Secure et la banque revient sur votre site ; c’est la signature de ce retour qui finalise la commande.
Page hébergée et webhook — international: Stripe, PayPal, Mollie, Square, Authorize.Net, Checkout.com, Razorpay et Paystack. MevvPos crée le paiement chez le prestataire via son API REST et envoie le client sur la page du prestataire. La commande est finalisée par une réponse du prestataire : la notification signée qui parvient à votre adresse de webhook ou — si le client revient avant qu’elle n’arrive — une interrogation de statut de serveur à serveur effectuée depuis la page de retour. Ce qui ne finalise jamais une commande à soi seul, c’est le retour du navigateur.

Du côté Türkiye, le moteur fait quelque chose dont les fournisseurs internationaux n’ont jamais besoin : il décide lequel de vos comptes prend la carte.

Vous définissez un ou plusieurs enregistrements TPE. Un enregistrement TPE est le TPE virtuel d’une banque : ses identifiants, son adresse de passerelle, ses taux de mensualités.
Au moment du paiement, le client saisit sa carte. Les six premiers chiffres — le BIN — identifient la banque qui l’a émise.
MevvPos recherche le BIN et envoie le paiement vers votre TPE auprès de cette banque, si vous en avez un. Sinon, il retombe sur votre TPE par défaut.
Le paiement en plusieurs fois n’est proposé que si la carte appartient à la banque de ce TPE, car les banques n’accordent pas de mensualités sur les cartes d’une autre banque.
Le client passe par 3-D Secure auprès de la banque, et la banque revient vers une adresse de rappel unique sur votre site.
La signature du retour est vérifiée avec la clé du TPE que la commande a réellement utilisé, la commande est finalisée et le résultat est enregistré.

Le numéro de carte, la date d’expiration et le CVV ne sont jamais écrits dans votre base de données ni dans la session WooCommerce. Les seules données de carte conservées sont les six premiers chiffres et le nom de banque reconnu.

Avec les fournisseurs internationaux, aucune donnée de carte n’atteint jamais votre site : la carte est saisie sur la propre page du fournisseur. C’est ce qui en fait le chemin le plus court vers un périmètre PCI restreint — et c’est aussi pourquoi ils ne comportent ni orientation par BIN ni paiement en plusieurs fois.

Les fournisseurs internationaux

Les prestataires internationaux couvrent le monde hors de Türkiye. Tous utilisent la page hébergée ou redirigée du prestataire, les données de carte ne sont donc jamais saisies sur votre site. L’authentification s’y déroule également, mais le résultat n’y reste pas : MevvPos enregistre si le payeur a été authentifié, l’envoie à la banque lorsque l’émetteur demande une vérification supplémentaire, et lit l’ECI pour enregistrer si la responsabilité en cas de rétrofacturation a été transférée. Lorsqu’un prestataire ne communique pas le résultat, celui-ci est consigné comme inconnu et non comme le vôtre. Au-delà de la carte, les méthodes locales partent dans le champ propre à chaque prestataire : iDEAL, Bancontact, prélèvement SEPA, Klarna, EPS, Przelewy24, BLIK, TWINT, Multibanco et portefeuilles. Vous choisissez celles qu’un compte propose, et une méthode non choisie n’est jamais envoyée. Une méthode dont la devise ne correspond pas à la commande est écartée d’emblée : proposer iDEAL sur une commande en dollars ne ferait qu’échouer le paiement chez le prestataire.

Stripe: Une Checkout Session en mode=payment, qui crée un Payment Intent derrière la propre page de Stripe. La clé secrète va dans la clé de marchand et le Webhook signing secret dans le champ supplémentaire. La commande est finalisée par un payment_intent.succeeded signé. Elements n’est délibérément pas utilisé : l’utiliser déplacerait les champs de carte sur votre page et élargirait votre périmètre PCI.
PayPal: Orders v2, en trois étapes : créer la commande, le client l’approuve chez PayPal, et MevvPos la capture. La troisième étape est celle qu’il est facile de manquer — une commande approuvée mais jamais capturée laisse l’argent non encaissé alors que la commande paraît payée. L’ID client REST va dans le numéro de marchand, le secret client dans la clé de marchand, et le Webhook ID dans le champ supplémentaire.
Mollie: Payments API v2. La clé API — live_… ou test_… — va dans la clé de marchand et il n’y a pas de champ supplémentaire, car Mollie ne signe pas ses notifications. Voir la section webhook ci-dessous pour ce que fait MevvPos à la place.
Square: Un Payment Link via la Checkout API. Saisissez le jeton d’accès comme clé de marchand, ainsi que le Location ID et la Webhook signature key. Square lie chaque vente à un emplacement : sans le Location ID, aucun paiement ne peut être créé, et l’erreur propre à Square ne le dit pas clairement.
Authorize.Net: Accept Hosted. L’API Login ID va dans le numéro de marchand, la Transaction Key dans la clé de marchand, et la Signature key dans le champ supplémentaire — une valeur distincte de la Transaction Key et facile à confondre avec elle. C’est le seul fournisseur qui ne renvoie pas d’adresse de redirection : il renvoie un jeton que MevvPos envoie par POST à la page hébergée sous forme de formulaire.
Checkout.com: La Hosted Payments Page. La clé secrète (sk_…) va dans la clé marchand et la clé de signature du webhook dans le champ supplémentaire ; la notification est signée en HMAC-SHA256 sur le corps brut. Un comportement à anticiper : le remboursement est accepté de façon asynchrone. Checkout.com répond à l’appel de remboursement par un 202 et un identifiant d’action, ce qui signifie que la demande a été prise en compte, et non que l’argent est déjà reparti.
Razorpay: Un Payment Link, pour les boutiques qui vendent en Inde, où la carte seule ne suffit pas et où l’UPI, la banque en ligne et les portefeuilles sont rassemblés sur la page du prestataire. La Key ID va dans le numéro marchand, la Key Secret dans la clé marchand, et le secret du webhook — une valeur distincte de la Key Secret — dans le champ supplémentaire. Razorpay renvoie deux identifiants qui ne sont pas interchangeables : l’identifiant du lien (plink_…) sert à demander le statut, tandis qu’un remboursement n’est possible qu’avec l’identifiant de paiement (pay_…) que le lien communique une fois réglé.
Paystack: Une page de transaction hébergée, pour les boutiques qui vendent au Nigeria, au Ghana, en Afrique du Sud, au Kenya et en Côte d’Ivoire, où l’USSD, le virement bancaire et le mobile money comptent autant que la carte. La clé secrète (sk_live_… ou sk_test_…) va dans la clé marchand et il n’y a pas de champ supplémentaire : la notification est signée en HMAC-SHA512 avec ce même secret. Tout tient à une seule référence : démarrer le paiement, en demander le statut et le rembourser l’utilisent tous.

Le mode test bascule sur la propre adresse de bac à sable du fournisseur pour PayPal, Square et Authorize.Net. Stripe et Mollie séparent le mode réel du test par la clé plutôt que par l’adresse ; là, c’est la clé que vous collez qui décide.

Les montants sont transportés d’un bout à l’autre comme des nombres entiers dans l’unité mineure de la devise — kuruş, centimes — jamais comme une fraction décimale. Mollie est le seul fournisseur qui veut une chaîne décimale en retour, et il veut exactement le bon nombre de chiffres pour la devise : 10.0 est refusé là où 10.00 est accepté. Cette chaîne est construite à partir de l’entier, pas d’un nombre à virgule flottante.

Aucun des huit n’a été vérifié de bout en bout avec un compte marchand réel. Chaque fichier de fournisseur le dit dans son propre en-tête et énumère les pages de documentation à partir desquelles il a été écrit. Les flux suivent la documentation publiée des fournisseurs, et les algorithmes de signature comme les noms de champs y sont arrimés ; mais ce n’est pas la même chose qu’un paiement réel abouti, et nous ne le présenterons pas comme tel. Lisez-les comme prêts à être raccordés et testés sur votre propre bac à sable, non comme éprouvés en production.

Enregistrements TPE

La barre des TPE se place au-dessus des onglets et reste visible sur chacun d’eux. Chaque carte affiche la banque, le numéro de commerçant et un badge quand quelque chose demande votre attention.

Par défaut: Le TPE qui prend le paiement quand aucune meilleure correspondance n’est trouvée. Il y en a toujours exactement un.
Inactif: Conservé mais n’encaissant pas. Utilisez cela plutôt que la suppression quand un TPE est configuré mais pas encore actif chez la banque — sans quoi un client porteur d’une carte de cette banque ne pourrait pas payer.
En attente d’une licence: L’enregistrement existe mais reste en sommeil parce que la licence n’est pas active. Rien n’a été supprimé ; il reprend là où il s’était arrêté au renouvellement de la licence.
Les informations de l’API n’ont pas été saisies: L’enregistrement n’a pas encore de numéro de commerçant.

Les banques sont représentées par une bande de couleur plutôt que par un logo. Les logos bancaires sont des marques déposées, et quinze d’entre eux représentent à la fois un risque juridique et une maintenance permanente — vous savez déjà quelle banque est la vôtre.

Le dernier POS ne peut pas être supprimé et le dernier activé ne peut pas être désactivé. Pour cesser complètement d’accepter les paiements par carte, désactivez plutôt le moyen de paiement dans l’onglet Général.

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.

Quand une licence expire, le compte qui continue à encaisser n’est pas choisi au hasard : c’est celui marqué par défaut, ou sinon le premier compte activé configuré. Choisir au hasard signifierait qu’un magasin se met un matin à encaisser silencieusement via une autre banque.

API de la banque — identifiants et adresse de la passerelle

Fournisseur: La liste se présente en deux groupes : Türkiye — POS virtuel bancaire et Fournisseurs de paiement internationaux. Tout ce que le formulaire vous demande ensuite découle de ce seul choix, et les réglages qui ne peuvent s’appliquer à votre choix ne sont pas affichés du tout.
Banque: Choisissez la banque auprès de laquelle se trouve votre TPE. L’adresse de la passerelle et la liste de BIN utilisée pour les mensualités découlent toutes deux de ce choix. Les établissements sans implémentation à ce jour sont listés avec « — yakında » et ne peuvent pas être sélectionnés.
Numéro de commerçant (Client ID): Le numéro de commerçant que la banque vous a fourni.
Merchant key (Store key): La clé de sécurité du commerçant. Stockée dans un champ de mot de passe ; une fois enregistrée, elle s’affiche masquée.
Gate URL: L’adresse vers laquelle le formulaire de paiement est envoyé.
Envoyer la propre devise de la commande à la banque: Réservé au POS virtuel turc, et désactivé par défaut : MevvPos envoie la livre turque, ce que votre banque attend sauf si vous avez un accord multidevise. La devise fait partie de la signature, donc une valeur que votre banque n’accepte pas est refusée sans explication. Les fournisseurs internationaux prennent la devise de la commande telle quelle et cette question ne leur est jamais posée.
Activer le mode test: Arrête la redirection automatique pour que vous puissiez inspecter la requête avant son envoi.

Laisser la Store Key vide au moment d’enregistrer signifie « ne pas la modifier ». Écrire la valeur vide effacerait la clé et votre boutique cesserait d’accepter les paiements sans le moindre message d’erreur. La même règle vaut pour les autres champs secrets.

Certaines familles nécessitent des identifiants supplémentaires, et le formulaire ne les affiche que pour le fournisseur que vous avez choisi :

Garanti BBVA — Merchant ID, nom d’utilisateur d’autorisation, mot de passe d’autorisation.
VakıfBank — Terminal No, et une adresse MPI (laissez-la vide pour utiliser l’adresse de test).
PayTR — Merchant Salt.
iyzico, Craftgate, Sipay — pas de champs supplémentaires : la clé d’API va dans le Numéro de commerçant et le secret dans la Merchant key.
Stripe — Webhook signing secret.
PayPal — Webhook ID.
Square — Location ID et Webhook signature key.
Authorize.Net — Signature key, utilisée uniquement pour les webhooks.
Mollie — pas de champ supplémentaire : la clé API va dans Clé de marchand.

Ces identifiants supplémentaires entrent dans la signature. S’il en manque un, la signature est calculée avec une valeur vide et la banque refuse le paiement en silence — pas d’erreur, pas de message, juste un refus.

Pour les sept banques NestPay, l’adresse de la passerelle est renseignée à partir de votre choix de banque : vous pouvez donc laisser Gate URL vide. Pour les autres, le champ n’est pas prérempli : saisissez l’adresse fournie par votre banque ou votre prestataire, sinon le formulaire de paiement n’a nulle part où être envoyé.

Les treize établissements pris en charge

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

Les établissements sans implémentation restent volontairement dans la liste des banques, marqués « — yakında ». Les retirer masquerait quelles familles de protocoles manquent encore. Si la vôtre en fait partie, l’onglet Requête envoyée à la banque est l’endroit pour le dire.

Seule la signature NestPay dispose d’un test à vecteur de référence face à l’exemple publié par la banque elle-même. Tous les autres prestataires sont marqués beta dans leur propre code source : le flux est implémenté conformément à la documentation, mais il n’a pas encore été vérifié de bout en bout avec un compte marchand réel auprès de cet établissement. Cette mention reste tant que ce n’est pas fait.

Les établissements de paiement n’émettent pas de cartes : ils ne portent donc pas de liste de BIN. Vous les sélectionnez comme votre TPE plutôt que d’y router.

Webhooks — où la commande est réellement finalisée

Chaque fournisseur international a besoin d’une adresse sur votre site, et elle a la même forme pour tous : ?mevvpos-webhook=<provider> sur votre adresse d’accueil. La valeur exacte est affichée en lecture seule sur l’onglet Bank API ; cliquer sur le champ le sélectionne.

Ce qui finalise la commande, c’est le webhook, pas le retour du client sur votre site. L’adresse de retour peut être devinée et un client peut y arriver sans avoir payé, donc un navigateur qui y arrive ne prouve rien à lui seul. MevvPos ne lit jamais le résultat depuis le retour : soit il attend la notification signée, soit il interroge directement le fournisseur, serveur à serveur. Tant que l’une de ces deux réponses n’est pas arrivée, la commande reste en attente et une note de commande le précise.

Copiez l’adresse depuis l’onglet Bank API.
Mollie est l’exception et ne nécessite de coller quoi que ce soit nulle part : MevvPos envoie l’adresse avec chaque paiement qu’il crée. Elle est omise lorsque le site répond sur une adresse locale, car Mollie ne pourrait de toute façon pas l’atteindre — en développement local, le résultat vient plutôt de la requête de statut.
Collez-la dans le panneau du fournisseur exactement comme elle apparaît. Square calcule sa signature sur l’adresse de notification conjointement avec le corps, donc un seul caractère de différence — une barre oblique finale suffit — fait échouer silencieusement la vérification de chaque événement.
Enregistrez le secret de signature que le fournisseur vous a rendu dans le champ supplémentaire de ce fournisseur.
Envoyez un événement de test depuis le panneau du fournisseur et vérifiez qu’une commande évolue réellement.

Mollie ne signe pas du tout sa notification — le corps ne porte rien d’autre qu’un identifiant de paiement. Cela paraît peu sûr et c’est en fait plus sûr : MevvPos ne fait pas confiance à la notification, il la traite comme une sonnette. Il prend l’identifiant et demande directement à Mollie quel est le statut du paiement, et seule une réponse paid produit un événement. Un attaquant peut sonner avec un identifiant inventé mais ne peut pas forger la réponse de Mollie ; une notification falsifiée ne peut donc jamais marquer une commande comme payée. Si Mollie ne peut pas être contacté, la réponse est « je ne sais pas » et rien ne change.

La signature de PayPal n’est pas non plus vérifiée localement. C’est une chaîne de certificats, et une erreur silencieuse dans la vérification d’une chaîne rend la signature dénuée de sens ; PayPal publie un point de terminaison pour cela, et toute réponse autre que SUCCESS signifie que l’événement est ignoré.

Trois règles valent pour chaque fournisseur. La réponse est toujours un 200 vide — un événement vérifié, un doublon et du bruit reçoivent tous la même réponse, car une réponse différente indiquerait à un attaquant laquelle de ses tentatives était la plus proche, et une réponse d’erreur pousserait seulement le fournisseur à réessayer un événement qui ne pourra jamais se vérifier. PayTR est la seule exception, car il veut le texte littéral OK et répète la notification pendant des heures sans cela. Le même événement livré deux fois n’a pas de second effet. Et le compte contre lequel un événement est vérifié est lu depuis votre propre configuration, jamais depuis la requête — sinon un attaquant pourrait désigner lui-même la clé avec laquelle sa propre falsification est vérifiée.

Le webhook ne passe pas par le point de terminaison de WooCommerce. Il a sa propre variable de requête et est intercepté avant même que le thème, la page et le mécanisme de requête ne s’exécutent — c’est aussi pourquoi il fonctionne sur un site sans WooCommerce installé.

Routage basé sur le BIN

Les six premiers chiffres d’une carte identifient la banque qui l’a émise. MevvPos établit la correspondance sur exactement ces six chiffres.

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 la rafraîchit chaque semaine depuis nos serveurs. Le rafraîchissement se superpose à la table livrée plutôt que de la remplacer : une réponse partielle ou vide ne doit jamais laisser une boutique sans aucune donnée BIN.
Une réponse comportant moins de cent BIN est rejetée comme invraisemblable et n’est pas écrite.
Les conflits — un même BIN revendiqué par deux banques — sont résolus de notre côté avant l’envoi de la liste. Une boutique qui les résoudrait localement pourrait compter une carte comme « la nôtre » et la router ailleurs en même temps.

Un BIN non reconnu n’est jamais refusé. Il retombe sur votre TPE par défaut. Écarter une carte que nous n’avons simplement pas en fiche reviendrait à perdre une vente pour protéger une table de correspondance.

La même table répond au moment du paiement à une seconde question, différente : cette carte vient-elle de la banque de ce TPE ? C’est ce qui décide si le paiement en plusieurs fois est proposé — voir plus bas.

L’exactitude des BIN n’est pas une fonctionnalité payante. Ce que Pro achète, c’est la fraîcheur, pas la justesse : la liste livrée est la même liste, simplement figée au moment de la compilation.

Mensualités et commission

Les taux se règlent par POS, du paiement comptant jusqu’à douze mensualités, dans l’onglet Mensualités et commission. Ce sont des pourcentages : écrivez 5.50 pour 5,5 %.

Cela fonctionne sur les deux surfaces de paiement. Sur la page en blocs, le tableau des échéances est dessiné par le bloc lui-même et le supplément est ajouté au panier comme des frais, exactement comme sur la page classique : choisir une échéance met donc à jour le total avant la validation de la commande.

Le paiement en plusieurs fois est une institution turque et l’onglet le sait. Tant qu’un fournisseur international est sélectionné, la grille des taux n’est pas affichée du tout, et l’onglet le dit par une phrase à la place : remplir douze lignes qui ne pourront jamais s’appliquer serait une façon de vous induire en erreur.

0: L’option est affichée et aucune commission n’est ajoutée.
Vide: L’option n’est pas affichée du tout. Vide et zéro ne sont pas la même chose.

La commission apparaît dans le panier sous la forme d’un frais taxable nommé « N Taksit Komisyonu », calculé sur le total du panier, frais de livraison et taxes compris.

Le paiement en plusieurs fois n’est proposé que sur les cartes émises par la banque de ce TPE, et c’est appliqué côté serveur — pas seulement masqué dans l’interface. Une carte d’une autre banque est ramenée de force à un paiement en une fois et les frais sont annulés.

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.

Le formulaire de réglages affiche toujours les douze champs, quelle que soit votre licence. S’ils disparaissaient à l’expiration d’une licence, enregistrer la page supprimerait silencieusement des taux que vous aviez déjà saisis. Les champs au-delà de votre plafond sont marqués « Débloqué dans Pro » et vos chiffres sont conservés.

Il n’existe pas de table de mensualités fournie par la banque. Les taux sont ceux que vous saisissez, et la commission d’une commande passée est calculée à partir du taux en vigueur le jour de la vente — modifier un taux aujourd’hui ne réécrit pas le rapport d’hier.

Le flux de paiement et la gestion de la carte

Toutes les familles turques passent par 3-D Secure. Il n’y a pas de mode sans 3D ni de réglage pour le désactiver. Côté international, MevvPos parle EMV 3-D Secure 2 : il enregistre si le payeur a été authentifié avec ou sans vérification supplémentaire, envoie le client à la banque lorsque l’émetteur en demande une, et lit l’ECI pour enregistrer si la responsabilité en cas de rétrofacturation a été transférée. Deux choses qu’il ne fait délibérément pas : il ne revendique jamais une exemption pour laquelle un prestataire n’a pas de champ, et il n’indique jamais que la responsabilité vous incombe lorsque le prestataire ne nous communique pas le résultat — « nous ne savons pas » et « la responsabilité est celle du commerçant » sont deux réponses différentes.

Flux par formulaire: NestPay, Garanti, PayTR et Sipay : le navigateur envoie un formulaire signé à la banque, le client s’authentifie, et la banque revient sur votre site.
Flux serveur: VakıfBank, iyzico et Craftgate : votre serveur dialogue avec le prestataire, récupère la page 3-D, l’affiche, et finalise la vente de serveur à serveur après l’authentification.
Flux de redirection: Stripe, PayPal, Mollie, Square, Checkout.com, Razorpay et Paystack : MevvPos crée le paiement via l’API REST du prestataire et envoie le client à l’adresse renvoyée par celui-ci.
Flux de formulaire par jeton: Authorize.Net : le fournisseur renvoie un jeton au lieu d’une adresse, et le jeton est envoyé par POST à sa page hébergée sous forme de formulaire. Écrire le jeton dans une URL le ferait fuiter dans l’historique du navigateur et les journaux du serveur.

Les banques turques reviennent toujours vers une seule adresse sur votre site : ?wc-api=mevvpos_callback. La signature de ce retour est vérifiée avec la clé du POS réellement utilisé par la commande, enregistrée sur la commande elle-même — avec plus d’un POS, vérifier avec la mauvaise clé produit une erreur de hachage sur chaque paiement.

La carte n’atteint jamais votre base de données. Elle est conservée dans le navigateur le temps de la redirection puis effacée. Si elle n’y est pas au chargement de la page de paiement — un nouvel onglet, un rafraîchissement, un stockage désactivé, un retour arrière depuis la banque —, un formulaire de carte visible est affiché plutôt que d’envoyer des champs vides à la banque. Le formulaire de carte est visible par défaut, à dessein : un parcours de paiement ne peut pas dépendre du fait que JavaScript se soit exécuté.

Quand la banque approuve le paiement, la commande est finalisée même si le code d’état 3-D était inattendu — une note de commande consigne l’anomalie et vous demande de la confirmer depuis l’écran de la banque. Si la banque dit approuvé, le client a été débité ; refuser reviendrait à dire « votre carte a été débitée mais votre commande a échoué ».

Chaque tentative enregistre le TPE utilisé, la banque et le BIN de la carte, le nombre de mensualités et le taux, le résultat, le code de réponse et le message de la banque, ainsi que les références d’autorisation et de transaction.

Pré-autorisation, liens de paiement et règles de risque

Autorisez maintenant, capturez plus tard

Chaque fiche POS porte une méthode d’encaissement : débiter tout de suite, ou retenir le montant et l’encaisser plus tard. Avec la seconde, l’argent est réservé sur la carte au paiement et l’écran de commande gagne deux boutons — capturer (tout, ou une partie) et libérer. Capturez quand le colis part ; libérez quand vous ne pouvez pas fournir.

Le réglage n’apparaît que là où le fournisseur le porte vraiment : la famille de banques NestPay (İşbank, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat) plus Stripe, Authorize.Net et Checkout.com. Pour tous les autres fournisseurs le choix n’est pas proposé du tout, plutôt que proposé puis mis en échec à la passerelle.

Un lien de paiement

L’écran Liens de paiement crée un lien pour un montant et, si vous voulez, une description et une date d’expiration. Celui qui l’ouvre atterrit sur la page de paiement ordinaire de la boutique avec une commande en attente déjà créée, ce qui veut dire le même routage BIN, le même tableau d’échéances et la même étape 3-D Secure que pour n’importe quel autre paiement. Rien n’est un raccourci qui contourne le moteur de paiement.

Le jeton fait 32 octets aléatoires ; l’adresse ne se devine pas à partir d’une autre.
Le lien expire à la date que vous fixez.
Il fonctionne une fois. Une fois la commande payée, le lien ne s’ouvre plus, donc un message transféré ne peut pas être payé deux fois.

Règles de risque

L’écran Risque contient cinq règles, chacune activée et dotée de son propre seuil séparément. Elles sont évaluées avant que la carte parte chez le moindre fournisseur, et chacune peut signaler la commande, la mettre en attente d’examen ou la refuser d’emblée.

Tentatives par adresse — combien de tentatives de paiement un visiteur peut faire dans une fenêtre de temps.
Tentatives par carte — le même compte pour une seule carte.
Échecs consécutifs — une série de refus à la suite.
Non-concordance de pays — une carte émise en Türkiye avec une adresse de facturation hors de Türkiye.
Plafond de montant — un total de commande au-dessus duquel vous voulez regarder d’abord.

Aucune adresse et aucun numéro de carte n’est noté. Ce que les compteurs gardent, c’est une empreinte salée avec la clé de votre propre site, donc les règles reconnaissent une répétition sans que l’écran devienne jamais une seconde base de données de cartes. Il n’y a pas d’empreinte d’appareil, pas de score appris par machine et pas de liste noire de BIN — cinq règles que vous pouvez lire, et rien que vous ne puissiez expliquer à un client.

Remboursements

Pour les fournisseurs internationaux, les remboursements se font depuis l’écran de commande WooCommerce de la manière habituelle — total ou partiel. MevvPos envoie le remboursement au fournisseur en se basant sur la référence de paiement enregistrée sur la commande.

Les remboursements ne sont jamais conditionnés par la licence. Ne pas pouvoir rendre son argent à un client n’est pas quelque chose qu’un rappel de renouvellement est autorisé à provoquer, et dans la plupart des pays c’est en outre une obligation légale.

Le POS virtuel bancaire turc ne peut pas encore être remboursé depuis WordPress, et MevvPos le dit au lieu de faire semblant. Remboursez la transaction depuis l’écran propre à votre banque. Signaler silencieusement un succès ferait marquer la commande comme remboursée par WooCommerce alors que l’argent resterait à la banque — un enregistrement comptable erroné coûte bien plus cher qu’un bouton qui ne fonctionne pas.

Un remboursement nécessite la référence de paiement renvoyée par le fournisseur. Une commande passée avant que cette référence ne soit enregistrée, ou dont le compte fournisseur a depuis été supprimé, ne peut pas être remboursée via l’extension.

Rapports

L’onglet Rapports affiche le chiffre d’affaires, les transactions réussies, le taux de réussite et la répartition entre paiement comptant et mensualités, avec un graphique quotidien. Les transactions qui attendent encore la réponse de la banque sont comptées à part et exclues du taux de réussite.

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

Charge des mensualités et des commissions — nombre, chiffre d’affaires et charge de commission par palier de mensualités.
Ventilation par TPE et par banque — chiffre d’affaires, réussites, échecs et taux de réussite pour chaque TPE et pour chaque banque émettrice.
Répartition des codes de refus — avec export CSV. Un code de refus qui revient pointe vers quelque chose que vous pouvez corriger : un solde insuffisant est le problème du client, mais les erreurs de vérification 3-D et de configuration du TPE sont les vôtres.

Les données derrière les rapports sont collectées par l’extension gratuite : l’historique continue donc de s’accumuler que vous ayez Pro ou non. Il faut qu’il en soit ainsi : les données passées ne peuvent pas être générées rétroactivement au moment de la mise à niveau.

Une boutique fraîchement installée n’a pas de graphique. L’enregistrement commence avec l’extension, et l’écran se remplit après la première tentative de paiement.

Utiliser le moteur sans WooCommerce

La passerelle WooCommerce est désormais un simple consommateur du moteur de paiement plutôt que le moteur lui-même. Le moteur ne sait rien des commandes, des paniers ni des sessions : vous lui remettez une intention de paiement — un montant en nombre entier d’unités mineures, une devise, une référence et les adresses de retour — et il vous rend soit un formulaire à envoyer par POST, soit une adresse vers laquelle rediriger. Une extension de formulaires, une extension de réservation ou votre propre code peuvent le piloter de la même manière que le paiement.

MevvPos_Payment_Engine::start() démarre un paiement et renvoie ce que le navigateur doit faire ensuite.
MevvPos_Payment_Engine::handle_webhook() est le seul chemin qui change l’état d’un paiement. Un événement dont la signature ne se vérifie pas ne change rien et est consigné.
MevvPos_Payment_Engine::webhook_url() construit l’adresse que vous collez dans le panneau du fournisseur.
Le plafond d’échéances est également appliqué à l’intérieur du moteur, comme dernière ligne de défense — l’écran appelant peut avoir été affiché avant l’expiration de la licence.

Si vous avez enregistré votre propre fournisseur via le filtre mevvpos_providers avant la version 4.0.0, il reçoit désormais une intention de paiement au lieu d’un WC_Order. Les requêtes et signatures des sept familles turques restent inchangées, donc les configurations POS existantes continuent de fonctionner sans y toucher.

Demandes bancaires et assistance

Requête envoyée à la banque: Liste chaque établissement pas encore implémenté, avec la raison : soit la famille de protocoles n’a pas été déterminée, soit la famille est connue et nous attendons la documentation. Vous pouvez ouvrir une demande pour l’un d’eux, ou nommer un établissement qui ne figure pas du tout dans la liste.
Assistance: Un objet, le TPE ou la banque concernés, ce qui se passe quand vous faites quoi, et le message d’erreur affiché par la banque.

Le formulaire d’assistance vous demande de ne pas inclure de numéro de carte ni de code de sécurité. Ils ne sont jamais nécessaires pour diagnostiquer un problème de paiement, et aucune donnée de paiement ou de carte n’est envoyée avec l’un ou l’autre formulaire.

L’extension gratuite ne contacte nos serveurs que lorsque vous appuyez sur l’un de ces boutons. Rien n’est envoyé selon un calendrier et il n’y a aucun appel de licence dans l’édition gratuite.

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

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

Quand une licence expire ou est absente :

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.
Les remboursements continuent de fonctionner, car ils ne sont jamais conditionnés.
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.
Le rafraîchissement BIN en direct s’arrête ; la table livrée continue de fonctionner.

Si nos serveurs sont injoignables, une licence active continue de fonctionner pendant sept jours sur la foi de la dernière vérification réussie. Mais une licence dont la date d’expiration est passée est lue comme expirée quoi qu’il arrive — sinon, bloquer notre adresse serait un moyen de prolonger une licence d’une semaine.

Mises à jour

L’extension Pro embarque un système de mise à jour lié à votre licence. Elle y est obligée : Pro n’est pas publiée sur WordPress.org, donc il n’existe nulle part où WordPress pourrait apprendre qu’une nouvelle version existe. Avec une licence active, une mise à jour Pro apparaît sur l’écran des extensions comme n’importe quelle autre.

L’extension gratuite annonce désormais aussi ses propres mises à jour. Elle demande à notre serveur s’il existe une version plus récente et remet la réponse au flux de mise à jour propre à WordPress : une nouvelle version apparaît donc sur l’écran des extensions avec un bouton Mettre à jour ordinaire, au lieu d’attendre que quelqu’un télécharge un zip à la main. La requête ne porte que le nom du paquet et la version installée — aucune adresse de site, aucune adresse e-mail, aucune clé de licence, aucun inventaire d’extensions. Comme rien n’y permet de vous identifier, la confiance repose entièrement sur la signature : la réponse est signée avec notre clé Ed25519, et une réponse non signée, mal signée, rejouée depuis un horodatage ancien ou pointant le téléchargement vers un autre hôte que le nôtre est écartée sans toucher au site. Vos enregistrements de TPE, vos identifiants et l’historique collecté résident dans les options WordPress et les métadonnées de commande, et une mise à jour n’y touche jamais.

Quand quelque chose ne fonctionne pas

La banque refuse tous les paiements sans message utile: Presque toujours la signature. Une mauvaise signature ne déclenche d’erreur nulle part — la banque refuse, tout simplement. Vérifiez le numéro de commerçant, la store key et tous les identifiants supplémentaires de cette famille : ils entrent tous dans la signature. Un test utile : les banques répondent différemment à une erreur de signature et à une carte invalide ; recevoir un message « carte invalide » signifie que votre signature est bonne.
« Erreur de hachage » au retour, avec plus d’un TPE: Le retour est une requête distincte, sans session. MevvPos consigne quel TPE une commande a utilisé et vérifie avec cette clé. Si vous avez supprimé l’enregistrement TPE par lequel une commande a été payée, la vérification retombe sur le TPE par défaut et peut échouer.
Le client paie chez Stripe ou PayPal mais la commande reste en attente: L’adresse du webhook n’est pas joignable ou n’est pas enregistrée. La commande est finalisée par la notification, pas par le retour du client, donc un webhook manquant ressemble exactement à un client qui n’a jamais payé. Vérifiez que l’adresse sur l’onglet Bank API est bien celle enregistrée dans le panneau du fournisseur, et que l’événement de test du fournisseur arrive.
Tous les événements Square sont rejetés: Square signe l’adresse de notification conjointement avec le corps. L’adresse enregistrée chez Square doit correspondre caractère pour caractère à celle de l’onglet Bank API — une barre oblique finale, http au lieu de https, ou un www présent d’un côté et pas de l’autre suffit.
Les événements Authorize.Net ne se vérifient jamais: La Signature key est une valeur distincte de la Transaction Key et les deux sont faciles à intervertir. Les webhooks ne sont vérifiés qu’avec la Signature key.
Le client atteint une page de paiement vide, ou le bouton Öde ne fait rien: Une extension de cache ou d’optimisation diffère les scripts. Sur LiteSpeed, excluez mevvpos, jquery et les scripts front-end de WooCommerce de la liste de délai. Le formulaire de carte est affiché par défaut pour que le parcours fonctionne quand même, mais pas la redirection automatique.
La commande reste « en attente » après un paiement réussi: La banque ou le prestataire n’a pas atteint l’adresse de rappel. Vérifiez que ?wc-api=mevvpos_callback est joignable depuis l’extérieur — un mode maintenance, une restriction d’IP ou un mur de connexion devant le site la bloquera.
Le formulaire de paiement se renvoie vers la même page: Le champ Gate URL est vide pour une banque dont l’adresse n’est pas préremplie. Saisissez l’adresse fournie par votre banque ou votre prestataire.
Le mode test est activé mais le paiement part quand même vers la banque en production: Le mode test arrête la redirection automatique et vous montre la requête ; il ne réécrit pas l’adresse de passerelle pour les banques NestPay. Mettez l’adresse de test de votre banque dans Gate URL pendant vos tests. Sur Stripe et Mollie non plus le commutateur ne change l’adresse — là, c’est la clé de test qui sélectionne le bac à sable.
Les mensualités n’apparaissent pas: 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.
Les cartes vont vers le mauvais TPE après une mise à niveau: Les versions plus anciennes portaient des plages de BIN écrites à la main, en partie erronées. Vérifiez que chaque TPE est bien classé sous la banque auprès de laquelle il se trouve réellement.
L’écran d’administration semble sans style, ou un correctif n’apparaît pas: Un cache de navigateur périmé. Rechargez la page en contournant le cache.

Limites

La liste ci-dessous est délibérée. Rien de tout cela n’est un bug.

Pas de remboursement pour le POS virtuel des banques turques. Aucune famille turque ne porte d'appel de remboursement ; remboursez depuis l'écran de votre propre banque. Les fournisseurs internationaux le font, et WooCommerce affiche le bouton de remboursement pour eux.
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.
Les paiements récurrents ne fonctionnent qu'avec les fournisseurs internationaux, et il n'y a pas de sélecteur de carte enregistrée. Une autorisation de prélèvement est créée, renouvelée, réessayée et marquée en retard, et un produit WooCommerce Subscriptions la met en place sans écrire de code. Ce qui manque : les familles de POS virtuel des banques turques n'en portent pas, l'acheteur ne peut pas choisir une carte enregistrée à la caisse, et il n'y a ni calendrier de relance ni annulation depuis l'administration.
La pré-autorisation existe, mais pas partout. Un POS peut retenir le montant et le capturer plus tard — en totalité ou en partie — depuis l’écran de commande, ou le libérer. Seuls la famille de banques NestPay, Stripe, Authorize.Net et Checkout.com le portent ; tout autre fournisseur est une vente directe et le réglage ne leur est pas montré.
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.
Les deux pages de paiement sont prises en charge. Le formulaire de paiement classique et le bloc Checkout de WooCommerce sont servis tous les deux, et le tableau d’échéances et sa majoration se comportent pareil sur l’un comme sur l’autre. Le bloc écrit le BIN et l’échéance choisis via la Store API, donc la majoration est calculée par le même code que sur la page classique.
3D Pay Hosting a été rejeté délibérément. La page hébergée supprime le périmètre PCI mais supprime aussi le BIN et la table d’échéances — or toute la valeur du côté Türkiye réside dans l’orientation qu’ils rendent possible. Les fournisseurs internationaux sont hébergés précisément parce qu’il n’y a rien à orienter là-bas.
Pas d’éditeur de BIN. La table est gérée par nos soins et fusionnée avec le rafraîchissement en direct ; il n’existe aucun écran pour la modifier à la main.
Vingt-six établissements sont listés mais non implémentés. Ils restent visibles pour que le manque reste visible.
Tous les prestataires, sauf NestPay, sont auto-déclarés beta tant qu’ils n’ont pas été vérifiés de bout en bout avec un compte marchand réel.
Les onglets sont dans la page. Les entrées de la barre latérale ouvrent l’écran MevvPos ; le changement d’onglet se fait sur la page elle-même.

Ce qui n’est jamais stocké, sous aucune forme : le numéro de carte, la date d’expiration et le code de sécurité. Du côté Türkiye, la seule donnée de carte conservée est les six premiers chiffres et la banque qu’ils identifient ; chez les fournisseurs internationaux, même pas cela, car la carte n’est jamais saisie sur votre site. Stocker le code de sécurité est interdit en toute circonstance, et même masqué il en révèle la longueur.

Un seul moteur : le POS virtuel des banques turques et les fournisseurs internationaux.