MevvPos — Documentazione Mevvsoft

Installazione

MevvPos richiede WordPress 6.0+ e PHP 8.1+. WooCommerce è facoltativo. Con WooCommerce 9.0 o versioni successive attivo, MevvPos si registra come metodo di pagamento al checkout; senza di esso il motore di pagamento si carica comunque e può essere pilotato da un altro plugin. Le versioni precedenti dichiaravano WooCommerce come dipendenza obbligatoria e WordPress rifiutava l'attivazione senza di esso — quel requisito non c'è più.

Entrambe le superfici di pagamento di WooCommerce sono coperte. MevvPos si registra sia per il checkout classico a shortcode sia per il più recente blocco Checkout. Fino alla 4.7.1 era collegata solo la pagina classica: un negozio passato al checkout a blocchi perdeva del tutto l’opzione carta — nessun errore, nessun avviso, solo un metodo di pagamento mancante. Non serve impostare altro: nella pagina a blocchi i campi carta, la tabella delle rate e la maggiorazione per rate compaiono allo stesso modo.

Carichi il plugin da Plugin → Aggiungi nuovo → Carica plugin e lo attivi.
Apra MevvPos nel menu di amministrazione a sinistra. C’è anche una scorciatoia sotto WooCommerce, dove i commercianti tendono a cercare le impostazioni di pagamento.
Nella scheda Generale, attivi il metodo di pagamento e imposti il titolo che il cliente vedrà al momento del pagamento.
Nella scheda Bank API, scegliete il vostro fornitore — un POS virtuale bancario turco o uno dei fornitori internazionali — e inserite le credenziali che vi ha fornito.
Se avete scelto un fornitore internazionale, copiate l'indirizzo Webhook stampato nella stessa scheda nel pannello del fornitore. Senza di esso nulla si completa.
In Rate e commissioni, inserisca i Suoi tassi di rateizzazione.
Provi con le credenziali di test della Sua banca prima di andare in produzione.

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

Pro è un plugin a parte, installato accanto a quello gratuito — non lo sostituisce. Il plugin gratuito è pubblicato su WordPress.org, dove tutto ciò che è pubblicato può essere ridistribuito sotto GPL; tenere il codice a pagamento nello stesso pacchetto lo avrebbe reso legalmente ridistribuibile da chiunque avesse cancellato i controlli di licenza. La chiave di licenza si inserisce nella scheda Licenza.

Aprire WooCommerce → Impostazioni → Pagamenti → MevvPos La reindirizza alla schermata di MevvPos. È deliberato: c’è un solo posto per queste impostazioni, non due che possano contraddirsi.

Come funziona

MevvPos parla due tipi di protocollo di pagamento, e quale dei due ottenete dipende dal fornitore scelto. Entrambi passano dallo stesso motore e producono lo stesso record d'ordine.

Modulo firmato — Türkiye: Le sette famiglie di POS virtuali turchi. MevvPos costruisce i campi di pagamento, li firma con la vostra chiave negozio e li invia alla banca tramite POST. Il cliente si autentica con 3-D Secure e la banca torna sul vostro sito; è la firma su quel ritorno a completare l'ordine.
Pagina ospitata e webhook — internazionale: Stripe, PayPal, Mollie, Square, Authorize.Net, Checkout.com, Razorpay e Paystack. MevvPos crea il pagamento presso il provider tramite la sua API REST e manda il cliente sulla pagina del provider. L’ordine viene completato da una risposta del provider: la notifica firmata che raggiunge il vostro indirizzo webhook oppure — se il cliente torna prima che arrivi — un’interrogazione di stato da server a server fatta dalla pagina di ritorno. Ciò che non completa mai un ordine da solo è il ritorno del browser.

Sul lato Türkiye il motore fa qualcosa di cui i fornitori internazionali non hanno mai bisogno: decide quale dei vostri conti prende la carta.

Lei definisce uno o più record POS. Un record POS è il POS virtuale di una banca: le sue credenziali, l’indirizzo del gateway, le sue percentuali per le rate.
Al checkout il cliente digita la sua carta. Le prime sei cifre — il BIN — identificano la banca che l’ha emessa.
MevvPos cerca il BIN e invia il pagamento al Suo POS presso quella banca, se ne ha uno. Altrimenti ripiega sul Suo POS predefinito.
Le rate vengono offerte solo quando la carta appartiene alla banca di quel POS, perché le banche non concedono rateizzazioni sulle carte di un’altra banca.
Il cliente passa dal 3-D Secure della banca, e la banca torna a un unico indirizzo di callback sul Suo sito.
La firma del ritorno viene verificata con la chiave del POS che l’ordine ha effettivamente usato, l’ordine viene completato e l’esito registrato.

Numero della carta, scadenza e CVV non vengono mai scritti nel Suo database né nella sessione di WooCommerce. Gli unici dati di carta conservati sono le prime sei cifre e il nome della banca riconosciuta.

Con i fornitori internazionali nessun dato della carta raggiunge mai il vostro sito: la carta viene digitata sulla pagina del fornitore. È questo che li rende la via più breve verso un ambito PCI ridotto — ed è anche per questo che non portano né instradamento BIN né rate.

I fornitori internazionali

I fornitori internazionali coprono il mondo fuori dalla Türkiye. Tutti usano la pagina ospitata o reindirizzata del fornitore stesso, quindi i dati della carta non vengono mai digitati sul tuo sito. Anche l’autenticazione avviene lì, ma l’esito non resta lì: MevvPos registra se il pagante è stato autenticato, lo invia alla banca quando l’emittente richiede una verifica aggiuntiva e legge l’ECI per registrare se la responsabilità per lo storno è stata trasferita. Se un fornitore non comunica l’esito, questo viene registrato come sconosciuto e non come tuo. Oltre alla carta, i metodi locali partono nel campo proprio di ogni fornitore: iDEAL, Bancontact, addebito diretto SEPA, Klarna, EPS, Przelewy24, BLIK, TWINT, Multibanco e wallet. Scegli tu quali offre un account, e un metodo non scelto non viene mai inviato. Un metodo la cui valuta non corrisponde all’ordine viene scartato subito: offrire iDEAL su un ordine in dollari farebbe solo fallire il pagamento presso il fornitore.

Stripe: Una Checkout Session in mode=payment, che crea un Payment Intent dietro la pagina di Stripe. La chiave segreta va nella chiave dell'esercente e il Webhook signing secret nel campo aggiuntivo. L'ordine viene completato da un payment_intent.succeeded firmato. Elements non viene usato deliberatamente: usarlo sposterebbe i campi della carta sulla vostra pagina e allargherebbe il vostro ambito PCI.
PayPal: Orders v2, in tre passaggi: creare l'ordine, il cliente lo approva su PayPal, e MevvPos lo cattura. Il terzo passaggio è quello più facile da trascurare — un ordine approvato ma mai catturato lascia il denaro non riscosso mentre l'ordine sembra pagato. L'ID client REST va nel numero dell'esercente, il client secret nella chiave dell'esercente, e il Webhook ID nel campo aggiuntivo.
Mollie: Payments API v2. La chiave API — live_… o test_… — va nella chiave dell'esercente e non c'è un campo aggiuntivo, perché Mollie non firma le sue notifiche. Vedete la sezione webhook più sotto per capire cosa fa MevvPos al suo posto.
Square: Un Payment Link tramite la Checkout API. Inserite il token di accesso come chiave dell'esercente, insieme a Location ID e Webhook signature key. Square lega ogni vendita a una location: senza il Location ID non è possibile creare alcun pagamento, e l'errore restituito da Square non lo dice chiaramente.
Authorize.Net: Accept Hosted. L'API Login ID va nel numero dell'esercente, la Transaction Key nella chiave dell'esercente, e la Signature key nel campo aggiuntivo — un valore diverso dalla Transaction Key e facile da confondere con essa. È l'unico fornitore che non restituisce un indirizzo di reindirizzamento: restituisce un token che MevvPos invia tramite form alla pagina ospitata.
Checkout.com: La Hosted Payments Page. La chiave segreta (sk_…) va nella chiave esercente e la chiave di firma del webhook nel campo extra; la notifica è firmata con HMAC-SHA256 sul corpo grezzo. Un comportamento da mettere in conto: il rimborso è accettato in modo asincrono. Checkout.com risponde alla chiamata di rimborso con un 202 e un id di azione, il che significa che la richiesta è stata presa in carico, non che il denaro sia già tornato.
Razorpay: Un Payment Link, per i negozi che vendono in India, dove la carta da sola non basta e UPI, netbanking e wallet sono raccolti nella pagina del provider. La Key ID va nel numero esercente, la Key Secret nella chiave esercente e il segreto del webhook — un valore distinto dalla Key Secret — nel campo extra. Razorpay restituisce due identificativi non intercambiabili: con l’id del link (plink_…) si chiede lo stato, mentre un rimborso è possibile solo con l’id del pagamento (pay_…) che il link riporta una volta pagato.
Paystack: Una pagina di transazione ospitata, per i negozi che vendono in Nigeria, Ghana, Sudafrica, Kenya e Costa d’Avorio, dove USSD, bonifico bancario e mobile money contano quanto la carta. La chiave segreta (sk_live_… o sk_test_…) va nella chiave esercente e non c’è campo extra: la notifica è firmata con HMAC-SHA512 usando lo stesso segreto. Tutto pende da un unico riferimento: avviare il pagamento, chiederne lo stato e rimborsarlo lo usano tutti.

La modalità test sostituisce l'indirizzo con quello sandbox del fornitore per PayPal, Square e Authorize.Net. Stripe e Mollie separano il live dal test tramite la chiave piuttosto che tramite l'indirizzo, quindi lì è la chiave che incollate a decidere.

Gli importi vengono trasportati come numeri interi nell'unità minore della valuta da un capo all'altro — kuruş, centesimi — e mai come frazione decimale. Mollie è l'unico fornitore che vuole indietro una stringa decimale, e vuole esattamente il numero giusto di cifre per la valuta: 10.0 viene rifiutato dove 10.00 viene accettato. Quella stringa è costruita a partire dall'intero, non da un numero in virgola mobile.

Nessuno degli otto è stato verificato da capo a fondo con un conto esercente reale. Ogni file di provider lo dichiara nella propria intestazione ed elenca le pagine di documentazione da cui è stato scritto. I flussi seguono la documentazione pubblicata dei provider, e gli algoritmi di firma e i nomi dei campi vi sono ancorati; ma questo non equivale a un pagamento reale portato a termine e non lo descriveremo come se lo fosse. Leggeteli come pronti da collegare e provare contro la vostra sandbox, non come provati in produzione.

Record POS

La barra dei POS sta sopra le schede ed è visibile in tutte. Ogni scheda mostra la banca, il numero esercente e un contrassegno quando qualcosa richiede la Sua attenzione.

Predefinito: Il POS che incassa quando non si trova una corrispondenza migliore. Ce n’è sempre esattamente uno.
Inattivo: Conservato ma non attivo negli incassi. Usi questo invece di eliminare quando un POS è configurato ma non è ancora operativo presso la banca — altrimenti un cliente con la carta di quella banca non potrebbe pagare.
In attesa di una licenza: Il record esiste ma è inattivo perché la licenza non è attiva. Non è stato eliminato nulla; riprende da dove si era fermato quando la licenza viene rinnovata.
I dati API non sono stati inseriti: Il record non ha ancora un numero esercente.

Le banche sono indicate da una fascia di colore invece che da un logo. I loghi bancari sono marchi registrati, e quindici di essi sono insieme un’esposizione legale e una manutenzione perpetua — Lei sa già qual è la Sua banca.

L’ultimo POS non può essere eliminato e l’ultimo abilitato non può essere disattivato. Per smettere del tutto di accettare pagamenti con carta, disattivi invece il metodo di pagamento nella scheda Generale.

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.

Quando una licenza scade, il conto che continua a incassare non viene scelto a caso: è quello contrassegnato come predefinito, oppure il primo conto abilitato configurato. Scegliere a caso significherebbe che un negozio, una mattina, comincia silenziosamente a incassare tramite una banca diversa.

API della banca — credenziali e indirizzo del gateway

Fornitore: L'elenco arriva in due gruppi: Türkiye — POS virtuale bancario e Fornitori di pagamento internazionali. Tutto il resto che il modulo vi chiede discende da questa unica scelta, e le impostazioni che non possono applicarsi alla vostra scelta non vengono mostrate affatto.
Banca: Scelga la banca presso cui si trova il Suo POS. Sia l’indirizzo del gateway sia l’elenco dei BIN usato per le rate dipendono da questa scelta. Gli istituti ancora privi di implementazione sono elencati con “— yakında” (in arrivo) e non sono selezionabili.
Numero esercente (Client ID): Il numero esercente che Le ha assegnato la banca.
Chiave esercente (store key): La chiave di sicurezza dell’esercente. Salvata come campo password; una volta salvata viene mostrata mascherata.
Gate URL: L’indirizzo a cui il modulo di pagamento invia i dati.
Inviare alla banca la valuta propria dell'ordine: Solo per il POS virtuale turco, e disattivato per impostazione predefinita: MevvPos invia lire turche, che è ciò che la vostra banca si aspetta a meno che non abbiate un accordo multivaluta. La valuta fa parte della firma, quindi un valore che la vostra banca non accetta viene rifiutato senza spiegazioni. I fornitori internazionali prendono la valuta dell'ordine così com'è e a loro questa domanda non viene mai posta.
Attiva la modalità test: Blocca il reindirizzamento automatico così può ispezionare la richiesta prima che venga inviata.

Lasciare vuota la Store Key al salvataggio significa “non modificarla”. Scrivere il valore vuoto cancellerebbe la chiave e il Suo negozio smetterebbe di incassare senza un solo messaggio di errore. La stessa regola vale per gli altri campi segreti.

Alcune famiglie richiedono credenziali aggiuntive, e il modulo le mostra solo per il fornitore scelto:

Garanti BBVA — Merchant ID, nome utente di autorizzazione, password di autorizzazione.
VakıfBank — Terminal No, e un indirizzo MPI (lo lasci vuoto per usare l’indirizzo di prova).
PayTR — Merchant Salt.
iyzico, Craftgate, Sipay — nessun campo aggiuntivo: la chiave API va nel Numero esercente e il segreto nella Chiave esercente.
Stripe — Webhook signing secret.
PayPal — Webhook ID.
Square — Location ID e Webhook signature key.
Authorize.Net — Signature key, usata solo per i webhook.
Mollie — nessun campo aggiuntivo: la chiave API va in Merchant key.

Queste credenziali aggiuntive entrano nella firma. Se una manca, la firma viene calcolata con un valore vuoto e la banca rifiuta il pagamento in silenzio — nessun errore, nessun messaggio, solo un rifiuto.

Per le sette banche NestPay l’indirizzo del gateway viene compilato dalla scelta della banca, quindi può lasciare Gate URL vuoto. Per le altre il campo non è precompilato: inserisca l’indirizzo che Le ha dato la banca o il provider, altrimenti il modulo di pagamento non ha dove inviare i dati.

I tredici istituti supportati

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

Gli istituti privi di implementazione restano di proposito nell’elenco delle banche, contrassegnati con “— yakında”. Rimuoverli nasconderebbe quali famiglie di protocollo mancano ancora. Se la Sua è tra queste, la scheda Richiesta banca è il posto in cui segnalarlo.

Solo la firma NestPay ha un test su vettore di riferimento rispetto all’esempio pubblicato dalla banca stessa. Ogni altro provider è contrassegnato come beta nel proprio codice: il flusso è implementato secondo la documentazione, ma non è ancora stato verificato end-to-end con un conto esercente reale presso quell’istituto. Quell’etichetta resta finché non lo sarà.

Gli istituti di pagamento non emettono carte, quindi non hanno un elenco di BIN. Li seleziona come Suo POS invece di instradarvi le carte.

Webhook — dove l'ordine viene davvero completato

Ogni fornitore internazionale richiede un indirizzo sul vostro sito, e ha la stessa forma per tutti: ?mevvpos-webhook=<provider> aggiunto al vostro indirizzo principale. Il valore esatto è stampato in sola lettura nella scheda Bank API; cliccando sul campo lo si seleziona.

Ciò che completa l'ordine è il webhook, non il ritorno del cliente sul vostro sito. L'indirizzo di ritorno può essere indovinato e un cliente può raggiungerlo senza aver pagato, quindi un browser che vi arriva non dimostra nulla da solo. MevvPos non legge mai l'esito dal ritorno: aspetta la notifica firmata oppure chiede direttamente al fornitore, server a server. Finché non arriva una di queste due risposte, l'ordine resta in sospeso e una nota d'ordine lo segnala.

Copiate l'indirizzo dalla scheda Bank API.
Mollie è l'eccezione e non richiede di incollare nulla da nessuna parte: MevvPos invia l'indirizzo con ogni pagamento che crea. Viene omesso quando il sito risponde su un indirizzo locale, perché Mollie comunque non potrebbe raggiungerlo — durante lo sviluppo locale il risultato arriva invece dalla richiesta di stato.
Incollatelo nel pannello del fornitore esattamente come appare. Square calcola la propria firma sull'indirizzo di notifica insieme al corpo, quindi un solo carattere di differenza — basta una barra finale — fa fallire silenziosamente la verifica di ogni evento.
Salvate il signing secret restituito dal fornitore nel campo aggiuntivo di quel fornitore.
Inviate un evento di test dal pannello del fornitore e verificate che un ordine si muova davvero.

Mollie non firma affatto la propria notifica — il corpo non porta altro che un id di pagamento. Sembra poco sicuro ed è in realtà più sicuro: MevvPos non si fida della notifica, la tratta come un campanello. Prende l'id e chiede direttamente a Mollie qual è lo stato del pagamento, e solo una risposta paid produce un evento. Un aggressore può suonare il campanello con un id inventato ma non può falsificare la risposta di Mollie, quindi una notifica falsa non può mai segnare un ordine come pagato. Se Mollie non è raggiungibile, la risposta è “non lo so” e nulla cambia.

Anche la firma di PayPal non viene verificata localmente. È una catena di certificati, e un errore silenzioso nella verifica di una catena rende la firma priva di senso; PayPal pubblica un endpoint apposito, e qualsiasi risposta diversa da SUCCESS significa che l'evento viene ignorato.

Tre regole valgono per ogni fornitore. La risposta è sempre un 200 vuoto — un evento verificato, un duplicato e uno scarto ottengono tutti la stessa risposta, perché una risposta diversa direbbe a un aggressore quale tentativo si è avvicinato di più, e una risposta di errore spingerebbe soltanto il fornitore a ritentare un evento che non potrà mai verificarsi. PayTR è l'unica eccezione, perché vuole il testo letterale OK e senza di esso ripete la notifica per ore. Lo stesso evento consegnato due volte non ha un secondo effetto. E il conto rispetto al quale un evento viene verificato viene letto dalla vostra configurazione, mai dalla richiesta — altrimenti un aggressore potrebbe indicare da sé la chiave con cui viene controllata la propria falsificazione.

Il webhook non passa attraverso l'endpoint di WooCommerce. Ha una propria variabile di query e viene intercettato prima ancora che il tema, la pagina e il motore delle query entrino in funzione — ed è anche per questo che funziona su un sito senza WooCommerce installato.

Instradamento basato su BIN

Le prime sei cifre di una carta identificano la banca che l’ha emessa. MevvPos confronta esattamente quelle sei cifre.

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 aggiorna ogni settimana dai nostri server. L’aggiornamento viene fuso sopra la tabella inclusa invece di sostituirla: una risposta parziale o vuota non deve mai lasciare un negozio del tutto privo di dati BIN.
Una risposta che porta meno di cento BIN viene rifiutata perché non plausibile e non viene scritta.
I conflitti — lo stesso BIN rivendicato da due banche — vengono risolti dalla nostra parte prima che l’elenco venga inviato. Un negozio che li risolvesse in locale potrebbe considerare una carta come “nostra” e allo stesso tempo instradarla altrove.

Un BIN non riconosciuto non viene mai rifiutato. Ricade sul Suo POS predefinito. Respingere una carta che semplicemente non abbiamo in archivio significherebbe perdere una vendita per proteggere una tabella di consultazione.

La stessa tabella risponde a una seconda domanda, diversa, al checkout: questa carta è della banca di questo POS? È ciò che decide se offrire le rate — vedi sotto.

L’accuratezza dei BIN non è una funzione a pagamento. Ciò che Pro paga è l’aggiornamento, non la correttezza: l’elenco incluso è lo stesso elenco, solo congelato al momento della build.

Rate e commissione

I tassi si impostano per POS, dal pagamento in un’unica soluzione fino a dodici rate, nella scheda Rate e commissioni. Sono percentuali: scriva 5.50 per 5,5%.

Questo funziona su entrambe le superfici di checkout. Nella pagina a blocchi la tabella delle rate è disegnata dal blocco stesso e la maggiorazione viene aggiunta al carrello come costo, esattamente come nella pagina classica: scegliere una rata aggiorna quindi il totale prima che l’ordine venga inviato.

Le rate sono un'istituzione turca e la scheda lo sa. Mentre è selezionato un fornitore internazionale la griglia dei tassi non viene mostrata affatto, e la scheda lo dice invece con una frase: compilare dodici righe che non potranno mai applicarsi sarebbe un modo di ingannarvi.

0: L’opzione viene mostrata e non viene aggiunta alcuna commissione.
Vuoto: L’opzione non viene mostrata affatto. Vuoto e zero non sono la stessa cosa.

La commissione compare nel carrello come una voce imponibile denominata “N Taksit Komisyonu” (commissione per N rate), calcolata sul totale del carrello comprensivo di spedizione e imposte.

Le rate vengono offerte solo sulle carte emesse dalla banca di quel POS, e questo viene imposto sul server — non semplicemente nascosto nell’interfaccia. Una carta di un’altra banca viene riportata al pagamento unico e la commissione viene azzerata.

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.

Il modulo delle impostazioni mostra sempre tutti e dodici i campi, qualunque sia la Sua licenza. Se sparissero alla scadenza di una licenza, salvare la pagina cancellerebbe in silenzio tassi già inseriti. I campi oltre il Suo limite sono contrassegnati come “Sbloccato in Pro” e i Suoi numeri vengono conservati.

Non esiste una tabella delle rate fornita dalla banca. Le percentuali sono quelle che inserisce Lei, e la commissione di un ordine passato viene calcolata con la percentuale in vigore il giorno della vendita — cambiare una percentuale oggi non riscrive il report di ieri.

Il flusso di pagamento e la gestione della carta

Ogni famiglia turca passa da 3-D Secure. Non esiste una modalità senza 3D né un’impostazione per disattivarla. Sul lato internazionale MevvPos parla EMV 3-D Secure 2: registra se il pagante è stato autenticato con o senza verifica aggiuntiva, invia il cliente alla banca quando l’emittente la richiede e legge l’ECI per registrare se la responsabilità per lo storno è stata trasferita. Due cose che deliberatamente non fa: non richiede mai un’esenzione per cui un fornitore non ha un campo, e non riporta mai la responsabilità come tua quando il fornitore non ci comunica l’esito — «non lo sappiamo» e «la responsabilità è dell’esercente» sono risposte diverse.

Flusso a modulo: NestPay, Garanti, PayTR e Sipay: il browser invia un modulo firmato alla banca, il cliente si autentica e la banca torna al Suo sito.
Flusso da server: VakıfBank, iyzico e Craftgate: il Suo server dialoga con il provider, ottiene la pagina 3-D, la mostra e completa la vendita da server a server dopo l’autenticazione.
Flusso di reindirizzamento: Stripe, PayPal, Mollie, Square, Checkout.com, Razorpay e Paystack: MevvPos crea il pagamento tramite l’API REST del provider e manda il cliente all’indirizzo che il provider restituisce.
Flusso a form con token: Authorize.Net: il fornitore restituisce un token invece di un indirizzo, e il token viene inviato tramite form alla sua pagina ospitata. Scrivere il token in un URL lo farebbe trapelare nella cronologia del browser e nei log del server.

Le banche turche tornano sempre a un unico indirizzo sul vostro sito: ?wc-api=mevvpos_callback. La firma su quel ritorno viene verificata usando la chiave del POS che l'ordine ha effettivamente usato, registrata sull'ordine stesso — con più di un POS, verificare con la chiave sbagliata produce un errore di hash su ogni singolo pagamento.

La carta non arriva mai al Suo database. Resta nel browser per la durata del reindirizzamento e viene poi rimossa. Se non c’è quando la pagina di pagamento si carica — una nuova scheda, un ricaricamento, l’archiviazione disattivata, un ritorno indietro dalla banca — viene mostrato un modulo carta visibile invece di inviare campi vuoti alla banca. Il modulo carta è visibile per impostazione predefinita, di proposito: un flusso di pagamento non può dipendere dall’esecuzione di JavaScript.

Quando la banca approva il pagamento, l’ordine viene completato anche se il codice di stato 3-D era inatteso — una nota d’ordine registra l’anomalia e Le chiede di confermarla dalla schermata della banca. Se la banca dice approvato, il cliente è già stato addebitato; rifiutare significherebbe “la Sua carta è stata addebitata ma il Suo ordine è fallito”.

Ogni tentativo registra il POS usato, la banca e il BIN della carta, il numero di rate e la percentuale, l’esito, il codice e il messaggio di risposta della banca, e i riferimenti di autorizzazione e di transazione.

Pre-autorizzazione, link di pagamento e regole di rischio

Autorizza ora, incassa dopo

Ogni scheda POS porta un metodo di incasso: addebito immediato, oppure blocco dell’importo e incasso successivo. Con il secondo, il denaro viene riservato sulla carta al checkout e la schermata dell’ordine acquisisce due pulsanti — incassa (tutto, o in parte) e rilascia. Incassa quando il pacco parte; rilascia quando non puoi fornirlo.

L’impostazione compare solo dove il fornitore la supporta davvero: la famiglia di banche NestPay (İşbank, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat) più Stripe, Authorize.Net e Checkout.com. Per ogni altro fornitore la scelta non viene proposta affatto, invece di proporla e poi fallire al gateway.

Un link di pagamento

La schermata Link di pagamento crea un link per un importo e, facoltativamente, una descrizione e una scadenza. Chi lo apre atterra sul normale checkout del negozio con un ordine in sospeso già creato, il che significa lo stesso instradamento BIN, la stessa tabella rate e lo stesso passaggio 3-D Secure di qualsiasi altro pagamento. Nulla è una scorciatoia intorno al motore di pagamento.

Il token è di 32 byte casuali; l’indirizzo non può essere indovinato a partire da un altro.
Il link scade alla data che imposti.
Funziona una sola volta. Dopo che l’ordine è pagato il link smette di aprirsi, così un messaggio inoltrato non può essere pagato due volte.

Regole di rischio

La schermata Rischio contiene cinque regole, ciascuna attivabile e con una propria soglia separata. Vengono valutate prima che la carta venga inviata a qualsiasi provider, e ognuna può segnalare l’ordine, metterlo in revisione o rifiutarlo direttamente.

Tentativi per indirizzo — quanti tentativi di pagamento può fare un visitatore in una finestra di tempo.
Tentativi per carta — lo stesso conteggio per una singola carta.
Fallimenti consecutivi — una serie di rifiuti di seguito.
Incoerenza di paese — una carta emessa in Turchia con indirizzo di fatturazione fuori dalla Türkiye.
Tetto di importo — un totale ordine oltre il quale vuoi guardare per primo.

Non viene scritto né l’indirizzo né il numero della carta. Ciò che i contatori conservano è un digest salato con la chiave del tuo sito, così le regole possono riconoscere una ripetizione senza che lo schermo diventi mai un secondo database di carte. Non c’è impronta del dispositivo, nessun punteggio da apprendimento automatico e nessuna lista di blocco BIN — cinque regole che puoi leggere, e niente che tu non possa spiegare a un cliente.

Rimborsi

Per i fornitori internazionali, i rimborsi vengono emessi dalla schermata ordine di WooCommerce nel modo consueto — totali o parziali. MevvPos invia il rimborso al fornitore in base al riferimento di pagamento registrato sull'ordine.

I rimborsi non sono mai vincolati alla licenza. Non poter restituire a un cliente il proprio denaro non è qualcosa che un promemoria di rinnovo possa causare, e nella maggior parte dei paesi è anche un obbligo di legge.

Il POS virtuale bancario turco non può ancora essere rimborsato da WordPress, e MevvPos lo dice apertamente invece di far finta di niente. Rimborsate la transazione dalla schermata della vostra banca. Segnalare silenziosamente un successo farebbe sì che WooCommerce contrassegni l'ordine come rimborsato mentre il denaro resta in banca — un record contabile sbagliato costa molto più di un pulsante che non funziona.

Un rimborso richiede il riferimento di pagamento restituito dal fornitore. Un ordine effettuato prima che quel riferimento venisse registrato, o uno il cui conto fornitore è stato nel frattempo eliminato, non può essere rimborsato tramite il plugin.

Report

La scheda Report mostra il fatturato, le transazioni riuscite, il tasso di successo e la ripartizione tra pagamento unico e rateizzato, con un grafico giornaliero. Le transazioni ancora in attesa della risposta della banca sono conteggiate a parte e restano fuori dal tasso di successo.

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

Carico di rate e commissioni — numero, ricavi e onere delle commissioni per fascia di rate.
Dettaglio per POS e banca — ricavi, successi, fallimenti e tasso di successo per ogni POS e per ogni banca emittente.
Distribuzione dei codici di rifiuto — con esportazione CSV. Un codice di rifiuto che si ripete indica qualcosa che può correggere: fondi insufficienti è un problema del cliente, ma gli errori di verifica 3-D e di configurazione del POS sono Suoi.

I dati alla base dei report sono raccolti dal plugin gratuito, quindi lo storico continua ad accumularsi che abbia Pro o no. Deve essere così: i dati passati non si possono generare retroattivamente al momento dell’aggiornamento.

Un negozio appena installato non ha alcun grafico. La registrazione comincia con il plugin, e la schermata si riempie dopo il primo tentativo di pagamento.

Usare il motore senza WooCommerce

Il gateway WooCommerce è ora un consumatore del motore di pagamento, non il motore stesso. Il motore non sa nulla di ordini, carrelli o sessioni: gli passate un intento di pagamento — un importo come numero intero di unità minori, una valuta, un riferimento e gli indirizzi di ritorno — e lui restituisce o un form da inviare o un indirizzo a cui reindirizzare. Un plugin di form, un plugin di prenotazione o il vostro stesso codice possono pilotarlo nello stesso modo in cui lo fa il checkout.

MevvPos_Payment_Engine::start() avvia un pagamento e restituisce cosa deve fare il browser successivamente.
MevvPos_Payment_Engine::handle_webhook() è l'unico percorso che modifica lo stato di un pagamento. Un evento la cui firma non si verifica non cambia nulla e viene registrato.
MevvPos_Payment_Engine::webhook_url() costruisce l'indirizzo da incollare nel pannello del fornitore.
Il tetto delle rate viene applicato anche all'interno del motore, come ultima linea di difesa — la schermata chiamante potrebbe essere stata renderizzata prima che la licenza scadesse.

Se avete registrato il vostro fornitore tramite il filtro mevvpos_providers prima della versione 4.0.0, ora riceve un intento di pagamento invece di un WC_Order. Le richieste e le firme per le sette famiglie turche sono invariate, quindi le configurazioni POS esistenti continuano a funzionare senza modifiche.

Richieste bancarie e assistenza

Richiesta banca: Elenca ogni istituto non ancora implementato, con il motivo: o la famiglia di protocollo non è stata determinata, oppure la famiglia è nota e stiamo aspettando la documentazione. Può aprire una richiesta per uno di essi, o segnalare un istituto che non compare affatto nell’elenco.
Assistenza: Un oggetto, il POS o la banca interessata, che cosa succede quando fa che cosa, e il messaggio di errore mostrato dalla banca.

Il modulo di assistenza Le chiede di non includere numeri di carta o codici di sicurezza. Non servono mai per diagnosticare un problema di pagamento, e con nessuno dei due moduli viene inviato alcun dato di pagamento o di carta.

Il plugin gratuito contatta i nostri server solo quando preme uno di questi pulsanti. Non viene inviato nulla in modo pianificato e nell’edizione gratuita non c’è alcuna chiamata di licenza.

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

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

Quando una licenza scade o manca:

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.
I rimborsi continuano a funzionare, perché non sono affatto vincolati.
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.
L’aggiornamento dei BIN dal vivo si ferma; la tabella inclusa continua a funzionare.

Se i nostri server non sono raggiungibili, una licenza attiva continua a funzionare per sette giorni sulla base dell’ultimo controllo riuscito. Ma una licenza la cui data di scadenza è già passata risulta comunque scaduta — altrimenti bloccare il nostro indirizzo sarebbe un modo per prolungare una licenza di una settimana.

Aggiornamenti

Il plugin Pro porta con sé un aggiornatore legato alla vostra licenza. Deve farlo: Pro non è pubblicato su WordPress.org, quindi non c'è modo per WordPress di sapere che esiste una nuova versione. Con una licenza attiva un aggiornamento Pro appare nella schermata dei plugin come qualsiasi altro.

Il plugin gratuito ora annuncia anche i propri aggiornamenti. Chiede al nostro server se esiste una versione più recente e consegna la risposta al flusso di aggiornamento proprio di WordPress, così una nuova versione compare nella schermata dei plugin con un normale pulsante Aggiorna invece di attendere che qualcuno scarichi uno zip a mano. La richiesta porta solo il nome del pacchetto e la versione installata: nessun indirizzo del sito, nessun indirizzo e-mail, nessuna chiave di licenza, nessun inventario di plugin. Poiché nulla in essa vi identifica, la fiducia poggia interamente sulla firma: la risposta è firmata con la nostra chiave Ed25519, e una risposta non firmata, firmata male, riprodotta da un timestamp vecchio o che punti il download a un host diverso dal nostro viene scartata senza toccare il sito. I vostri record POS, le credenziali e lo storico raccolto risiedono nelle opzioni di WordPress e nei metadati dell’ordine, e un aggiornamento non li tocca mai.

Quando qualcosa non funziona

La banca rifiuta ogni pagamento senza alcun messaggio utile: Quasi sempre è la firma. Una firma sbagliata non genera errori da nessuna parte — la banca semplicemente rifiuta. Controlli il numero esercente, la chiave esercente e le eventuali credenziali aggiuntive di quella famiglia: entrano tutte nella firma. Una prova utile è che le banche rispondono diversamente a un errore di firma e a una carta non valida; ricevere un messaggio di “carta non valida” significa che la firma è corretta.
“Errore di hash” al ritorno, con più di un POS: Il ritorno è una richiesta separata, priva di sessione. MevvPos registra quale POS ha usato un ordine e verifica con quella chiave. Se ha eliminato il record POS con cui un ordine è stato pagato, la verifica ripiega sul POS predefinito e può fallire.
Il cliente paga su Stripe o PayPal ma l'ordine resta in sospeso: L'indirizzo webhook non è raggiungibile o non è registrato. L'ordine viene completato dalla notifica, non dal ritorno del cliente, quindi un webhook mancante appare esattamente come un cliente che non ha mai pagato. Verificate che l'indirizzo nella scheda Bank API sia quello salvato nel pannello del fornitore, e che l'evento di test del fornitore arrivi.
Tutti gli eventi Square vengono rifiutati: Square firma l'indirizzo di notifica insieme al corpo. L'indirizzo registrato su Square deve corrispondere carattere per carattere a quello nella scheda Bank API — basta una barra finale, http invece di https, o un www presente da una parte e assente dall'altra.
Gli eventi Authorize.Net non si verificano mai: La Signature key è un valore separato dalla Transaction Key e le due sono facili da scambiare. I webhook vengono verificati solo con la Signature key.
Il cliente arriva a una pagina di pagamento vuota, o il pulsante Öde (Paga) non fa nulla: Un plugin di cache o di ottimizzazione sta posticipando gli script. Su LiteSpeed, escluda mevvpos, jquery e gli script front-end di WooCommerce dall’elenco dei ritardi. Il modulo carta viene mostrato per impostazione predefinita così il flusso continua a funzionare, ma il reindirizzamento automatico no.
L’ordine resta “in attesa” dopo un pagamento riuscito: La banca o il provider non ha raggiunto l’indirizzo di callback. Verifichi che ?wc-api=mevvpos_callback sia raggiungibile dall’esterno — una modalità di manutenzione, una restrizione per IP o un muro di accesso davanti al sito lo bloccheranno.
Il modulo di pagamento viene inviato alla stessa pagina: Il campo Gate URL è vuoto per una banca il cui indirizzo non è precompilato. Inserisca l’indirizzo che Le ha dato la banca o il provider.
La modalità di prova è attiva ma il pagamento va comunque alla banca reale: La modalità test blocca il reindirizzamento automatico e vi mostra la richiesta; non riscrive l'indirizzo del gateway per le banche NestPay. Inserite l'indirizzo di test della vostra banca in Gate URL mentre state testando. Anche su Stripe e Mollie l'interruttore non cambia l'indirizzo — lì è la chiave di test a selezionare la sandbox.
Le rate non compaiono: 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.
Le carte finiscono al POS sbagliato dopo un aggiornamento: Le versioni più vecchie contenevano intervalli di BIN scritti a mano in parte errati. Verifichi che ogni POS sia archiviato sotto la banca presso cui si trova davvero.
La schermata di amministrazione appare priva di stile, o una correzione non compare: Una cache del browser obsoleta. Ricarichi la pagina bypassando la cache.

Limiti

L’elenco qui sotto è deliberato. Nulla di ciò è un difetto.

Nessun rimborso per il POS virtuale delle banche turche. Nessuna famiglia turca prevede una chiamata di rimborso; rimborsa dalla schermata della tua banca. I i fornitori internazionali lo fanno e WooCommerce mostra per loro il pulsante di rimborso.
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.
I pagamenti ricorrenti funzionano solo con i fornitori internazionali e non c'è un selettore di carte salvate. Un'autorizzazione di addebito viene creata, rinnovata, ritentata e contrassegnata come scaduta, e un prodotto WooCommerce Subscriptions la configura senza scrivere codice. Cosa manca: le famiglie di POS virtuali delle banche turche non possono portarla, l'acquirente non può scegliere una carta salvata al checkout e non esistono né un calendario di solleciti né la cancellazione dal pannello.
La pre-autorizzazione esiste, ma non ovunque. Un POS può bloccare l’importo e incassarlo più tardi — per intero o in parte — dalla schermata dell’ordine, oppure rilasciarlo. Solo la famiglia di banche NestPay, Stripe, Authorize.Net e Checkout.com la supportano; per ogni altro fornitore si tratta di una vendita diretta e l’impostazione non viene mostrata.
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.
Entrambi i checkout sono supportati. Sia il modulo di pagamento classico sia il blocco Checkout di WooCommerce vengono serviti, e la tabella rate e la sua maggiorazione si comportano allo stesso modo su entrambi. Il blocco scrive il BIN scelto e la rata tramite la Store API, quindi la maggiorazione viene calcolata dallo stesso codice della pagina classica.
3D Pay Hosting è stato scartato deliberatamente. La pagina ospitata elimina l'ambito PCI ma elimina anche il BIN e la tabella delle rate — e l'intero valore del lato Türkiye sta nell'instradamento che essi rendono possibile. I fornitori internazionali sono ospitati proprio perché lì non c'è nulla da instradare.
Nessun editor dei BIN. La tabella è gestita da noi e fusa con l’aggiornamento dal vivo; non c’è alcuna schermata per modificarla a mano.
Ventisei istituti sono elencati ma non implementati. Restano visibili perché la lacuna resti visibile.
Ogni provider tranne NestPay è dichiarato beta da noi stessi finché non sia stato verificato end-to-end con un conto esercente reale.
Le schede sono nella pagina. Le voci della barra laterale aprono la schermata di MevvPos; cambi scheda nella pagina stessa.

Ciò che non viene mai memorizzato, in nessuna forma: il numero della carta, la data di scadenza e il codice di sicurezza. Sul lato Türkiye l'unico dato della carta conservato sono le prime sei cifre e la banca che identificano; con i fornitori internazionali nemmeno quello, perché la carta non viene mai digitata sul vostro sito. Memorizzare il codice di sicurezza è vietato in ogni circostanza, e persino uno mascherato ne rivela la lunghezza.

Un solo motore: il POS virtuale bancario turco e i fornitori internazionali.