MevvPos — Documentación de Mevvsoft

Instalación

MevvPos necesita WordPress 6.0+ y PHP 8.1+. WooCommerce es opcional. Con WooCommerce 9.0 o posterior activo, MevvPos se registra como método de pago en el checkout; sin él, el motor de pagos igualmente se carga y puede ser gestionado por otro plugin. Las versiones anteriores declaraban WooCommerce como una dependencia obligatoria y WordPress rechazaba la activación sin ella — ese requisito ha desaparecido.

Ambas superficies de pago de WooCommerce están cubiertas. MevvPos se registra tanto en el pago clásico por shortcode como en el nuevo bloque de Pago. Hasta la 4.7.1 solo estaba conectada la página clásica, así que una tienda que pasaba al pago por bloques perdía por completo la opción de tarjeta: sin error, sin aviso, solo un método de pago ausente. No hay que configurar nada más: en la página de bloques los campos de tarjeta, la tabla de plazos y el recargo por plazos aparecen igual.

Suba el plugin en Plugins → Añadir nuevo → Subir plugin y actívelo.
Abra MevvPos en el menú lateral de administración. También hay un acceso directo bajo WooCommerce, donde los comerciantes suelen buscar los ajustes de pago.
En la pestaña General, active el método de pago y ponga el título que el cliente verá al finalizar la compra.
En Bank API, elija su proveedor — un POS virtual de banco turco o uno de los proveedores internacionales — e introduzca las credenciales que le entregó.
Si eligió un proveedor internacional, copie la Webhook address impresa en esa misma pestaña en el panel propio del proveedor. Nada se completa sin ella.
En Plazos y comisiones, introduzca sus tasas de plazos.
Pruebe con las credenciales de test de su banco antes de pasar a producción.

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

Pro es un plugin aparte, que se instala junto al gratuito — no lo sustituye. El plugin gratuito se publica en WordPress.org, donde todo lo publicado puede redistribuirse bajo la GPL; mantener el código de pago en el mismo paquete lo habría hecho legalmente redistribuible por cualquiera que borrase las comprobaciones de licencia. La clave de licencia se introduce en la pestaña Licencia.

Abrir WooCommerce → Ajustes → Pagos → MevvPos le redirige a la pantalla de MevvPos. Es deliberado: hay un solo lugar para estos ajustes, no dos que puedan contradecirse.

Cómo funciona

MevvPos habla dos tipos de protocolo de pago, y cuál obtiene depende del proveedor que eligió. Ambos pasan por el mismo motor y producen el mismo registro de pedido.

Formulario firmado — Türkiye: Las siete familias de POS virtual turcas. MevvPos construye los campos de pago, los firma con su clave de tienda y los envía por POST al banco. El cliente se autentica con 3-D Secure y el banco vuelve a su sitio; la firma de ese retorno es lo que completa el pedido.
Página alojada y webhook — internacional: Stripe, PayPal, Mollie, Square, Authorize.Net, Checkout.com, Razorpay y Paystack. MevvPos crea el pago en el proveedor a través de su API REST y envía al cliente a la página propia del proveedor. El pedido se completa con una respuesta del proveedor: la notificación firmada que llega a su dirección de webhook o —si el cliente vuelve antes de que llegue— una consulta de estado de servidor a servidor hecha desde la página de retorno. Lo que nunca completa un pedido por sí solo es el retorno del navegador.

En el lado de Türkiye el motor hace algo que los proveedores internacionales nunca necesitan: decide cuál de sus cuentas toma la tarjeta.

Usted define uno o más registros de POS. Un registro de POS es el POS virtual de un banco: sus credenciales, su dirección de pasarela, sus tasas de cuotas.
En el proceso de pago, el cliente teclea su tarjeta. Los primeros seis dígitos — el BIN — identifican al banco que la emitió.
MevvPos busca el BIN y envía el pago a su POS en ese banco, si tiene uno. Si no, recae en su POS predeterminado.
Las cuotas se ofrecen solo cuando la tarjeta pertenece al propio banco de ese POS, porque los bancos no conceden cuotas con tarjetas de otro banco.
El cliente pasa por 3-D Secure en el banco, y el banco vuelve a una única dirección de retorno en su sitio.
La firma del retorno se verifica con la clave del POS que el pedido realmente usó, el pedido se completa y el resultado queda registrado.

El número de tarjeta, la fecha de caducidad y el CVV nunca se escriben en su base de datos ni en la sesión de WooCommerce. Los únicos datos de tarjeta que se conservan son los primeros seis dígitos y el nombre del banco reconocido.

Con los proveedores internacionales ningún dato de tarjeta llega a su sitio: la tarjeta se escribe en la página propia del proveedor. Eso es lo que los convierte en la vía más corta hacia un alcance PCI reducido — y también es la razón por la que no llevan enrutamiento por BIN ni cuotas.

Los proveedores internacionales

Los proveedores internacionales cubren el mundo fuera de Türkiye. Todos usan la página alojada o redirigida del propio proveedor, así que los datos de la tarjeta nunca se escriben en tu sitio. La autenticación también ocurre allí, pero el resultado no se queda allí: MevvPos registra si el pagador fue autenticado, lo envía al banco cuando el emisor pide una verificación adicional y lee el ECI para registrar si se transfirió la responsabilidad por contracargo. Cuando un proveedor no informa el resultado, se registra como desconocido y no como tuyo. Más allá de la tarjeta, los métodos locales salen en el campo propio de cada proveedor: iDEAL, Bancontact, domiciliación SEPA, Klarna, EPS, Przelewy24, BLIK, TWINT, Multibanco y monederos. Tú eliges cuáles ofrece cada cuenta, y un método que no elegiste nunca se envía. Un método cuya moneda no coincide con el pedido se descarta sin más: ofrecer iDEAL en un pedido en dólares solo haría que el pago fallara en el proveedor.

Stripe: Una Checkout Session en mode=payment, que crea un Payment Intent detrás de la página propia de Stripe. La clave secreta va en la clave de comerciante y el Webhook signing secret en el campo adicional. El pedido se completa mediante un payment_intent.succeeded firmado. Elements se evita deliberadamente: usarlo trasladaría los campos de tarjeta a su página y ampliaría su alcance PCI.
PayPal: Orders v2, en tres pasos: crear el pedido, el cliente lo aprueba en PayPal, y MevvPos lo captura. El tercer paso es el que más fácilmente se pasa por alto — un pedido aprobado que nunca se captura deja el dinero sin cobrar mientras el pedido parece pagado. El REST client ID va en el número de comerciante, el client secret en la clave de comerciante, y el Webhook ID en el campo adicional.
Mollie: Payments API v2. La clave API — live_… o test_… — va en la clave de comerciante y no hay campo adicional, porque Mollie no firma sus notificaciones. Vea la sección de webhooks más abajo para saber qué hace MevvPos en su lugar.
Square: Un Payment Link a través de la Checkout API. Introduzca el token de acceso como clave de comerciante, el Location ID y la Webhook signature key. Square ata cada venta a una ubicación: sin el Location ID no se puede crear ningún pago, y el propio error de Square no lo dice con claridad.
Authorize.Net: Accept Hosted. El API Login ID va en el número de comerciante, la Transaction Key en la clave de comerciante, y la Signature key en el campo adicional — un valor distinto de la Transaction Key y fácil de confundir con ella. Este es el único proveedor que no devuelve una dirección de redirección: devuelve un token que MevvPos envía por POST a la página alojada como un formulario.
Checkout.com: La Hosted Payments Page. La clave secreta (sk_…) va en la clave de comercio y la clave de firma del webhook en el campo extra; la notificación se firma con HMAC-SHA256 sobre el cuerpo en bruto. Un comportamiento que conviene prever: el reembolso se acepta de forma asíncrona. Checkout.com responde a la llamada de reembolso con un 202 y un id de acción, lo que significa que la petición se ha aceptado, no que el dinero ya haya vuelto.
Razorpay: Un Payment Link, para tiendas que venden a India, donde la tarjeta por sí sola no basta y UPI, la banca por internet y los monederos se reúnen en la página del proveedor. El Key ID va en el número de comercio, el Key Secret en la clave de comercio y el secreto del webhook —un valor distinto del Key Secret— en el campo extra. Razorpay devuelve dos identificadores que no son intercambiables: el id del enlace (plink_…) es con el que se pregunta el estado, mientras que un reembolso solo es posible con el id de pago (pay_…) que el enlace informa una vez pagado.
Paystack: Una página de transacción alojada, para tiendas que venden a Nigeria, Ghana, Sudáfrica, Kenia y Costa de Marfil, donde el USSD, la transferencia bancaria y el dinero móvil importan tanto como la tarjeta. La clave secreta (sk_live_… o sk_test_…) va en la clave de comercio y no hay campo extra: la notificación se firma con HMAC-SHA512 usando ese mismo secreto. Todo cuelga de una única referencia: iniciar el pago, preguntar su estado y reembolsarlo la usan toda.

El modo de prueba activa la dirección de sandbox propia del proveedor en PayPal, Square y Authorize.Net. Stripe y Mollie separan lo real de lo de prueba por la clave y no por la dirección, así que ahí lo que decide es la clave que pega.

Los importes se transportan de extremo a extremo como números enteros en la unidad menor de la moneda — kuruş, céntimos — y nunca como fracción decimal. Mollie es el único proveedor que quiere de vuelta una cadena decimal, y quiere exactamente el número correcto de dígitos para la moneda: 10.0 se rechaza donde 10.00 se acepta. Esa cadena se construye a partir del entero, no de un flotante.

Ninguno de los ocho se ha verificado de principio a fin con una cuenta de comercio real. Cada archivo de proveedor lo dice en su propia cabecera y enumera las páginas de documentación a partir de las cuales se escribió. Los flujos siguen la documentación publicada de los proveedores, y los algoritmos de firma y los nombres de campo están fijados a ella, pero eso no es lo mismo que un pago real completado y no lo describiremos como si lo fuera. Léalos como listos para conectar y probar contra su propio sandbox, no como probados en producción.

Registros de POS

La barra de POS está encima de las pestañas y se ve en todas ellas. Cada tarjeta muestra el banco, el número de comercio y un distintivo cuando algo requiere su atención.

Predeterminado: El POS que cobra cuando no se encuentra una coincidencia mejor. Siempre hay exactamente uno.
Inactivo: Se conserva pero no cobra. Use esto en lugar de borrar cuando un POS está configurado pero aún no está activo en el banco — de otro modo, un cliente con una tarjeta de ese banco no podría pagar.
A la espera de licencia: El registro existe pero está inactivo porque la licencia no está activa. No se ha borrado nada; se retoma donde lo dejó cuando se renueva la licencia.
No se han introducido los datos de la API: El registro todavía no tiene número de comercio.

Los bancos se muestran con una franja de color en lugar de un logotipo. Los logotipos de banco son marcas registradas, y quince de ellos son a la vez exposición legal y mantenimiento permanente — usted ya sabe cuál es su banco.

El último POS no se puede eliminar y el último habilitado no se puede desactivar. Para dejar de aceptar pagos con tarjeta por completo, desactive el método de pago en la pestaña General.

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.

Cuando una licencia caduca, la cuenta que sigue cobrando no se elige al azar: es la marcada como predeterminada, o si no, la primera cuenta habilitada configurada. Elegir al azar significaría que una tienda empieza silenciosamente a cobrar a través de otro banco una mañana.

API del banco — credenciales y dirección de la pasarela

Proveedor: La lista viene en dos grupos: Türkiye — POS virtual bancario y Proveedores de pago internacionales. Todo lo demás que el formulario le pide se deriva de esta única elección, y los ajustes que no pueden aplicarse a su elección no se muestran en absoluto.
Banco: Elija el banco con el que está su POS. Tanto la dirección de la pasarela como la lista de BIN usada para las cuotas dependen de esta elección. Las entidades sin implementación todavía aparecen con “— yakında” (próximamente) y no se pueden seleccionar.
Número de comercio (Client ID): El número de comercio que le dio el banco.
Clave de comercio (store key): La clave de seguridad del comercio. Se guarda como campo de contraseña; una vez guardada se muestra enmascarada.
Gate URL: La dirección a la que el formulario de pago envía los datos.
Enviar al banco la propia moneda del pedido: Solo para el POS virtual turco, y desactivado por defecto: MevvPos envía liras turcas, que es lo que su banco espera a menos que tenga un acuerdo multidivisa. La moneda forma parte de la firma, así que un valor que su banco no acepta se rechaza sin explicación. Los proveedores internacionales toman la moneda del pedido tal cual y nunca se les hace esta pregunta.
Activar el modo de pruebas: Detiene la redirección automática para que pueda inspeccionar la petición antes de que se envíe.

Dejar la Store Key en blanco al guardar significa “no la cambies”. Escribir el valor en blanco borraría la clave y su tienda dejaría de aceptar pagos sin un solo mensaje de error. La misma regla se aplica a los demás campos secretos.

Algunas familias necesitan credenciales adicionales, y el formulario las muestra solo para el proveedor que eligió:

Garanti BBVA — Merchant ID, nombre de usuario de autorización, contraseña de autorización.
VakıfBank — Terminal No, y una dirección MPI (déjela vacía para usar la dirección de prueba).
PayTR — Merchant Salt.
iyzico, Craftgate, Sipay — sin campos adicionales: la clave de API va en Número de comercio y el secreto en Clave de comercio.
Stripe — Webhook signing secret.
PayPal — Webhook ID.
Square — Location ID y Webhook signature key.
Authorize.Net — Signature key, usada solo para webhooks.
Mollie — sin campos adicionales: la clave API va en Merchant key.

Estas credenciales adicionales entran en la firma. Si falta una, la firma se calcula con un valor vacío y el banco rechaza el pago en silencio — sin error, sin mensaje, solo una denegación.

Para los siete bancos NestPay, la dirección de la pasarela se rellena a partir de su elección de banco, así que puede dejar Gate URL vacío. Para los demás el campo no viene rellenado: introduzca la dirección que le dio su banco o proveedor, o el formulario de pago no tendrá adónde enviar los datos.

Las trece entidades compatibles

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

Las entidades sin implementación permanecen a propósito en la lista de bancos, marcadas como «— yakında». Quitarlas ocultaría qué familias de protocolo siguen faltando. Si la suya es una de ellas, la pestaña Solicitud de banco es donde decirlo.

Solo la firma NestPay tiene una prueba de vector de referencia frente al propio ejemplo publicado por el banco. Todos los demás proveedores están marcados como beta en su propio código: el flujo está implementado según la documentación, pero todavía no se ha verificado de extremo a extremo con una cuenta de comercio real en esa entidad. Esa etiqueta se mantiene hasta que se haga.

Las entidades de pago no emiten tarjetas, así que no llevan lista de BIN. Se seleccionan como su POS en lugar de enrutar hacia ellas.

Webhooks — dónde se completa realmente el pedido

Cada proveedor internacional necesita una dirección en su sitio, y tiene la misma forma para todos ellos: ?mevvpos-webhook=<provider> sobre su dirección principal. El valor exacto se muestra de solo lectura en la pestaña Bank API; hacer clic en el campo lo selecciona.

Lo que completa el pedido es el webhook, no que el cliente vuelva a su sitio. La dirección de retorno se puede adivinar y un cliente puede llegar a ella sin haber pagado, así que un navegador que llega ahí no prueba nada por sí solo. MevvPos nunca lee el resultado del retorno: o bien espera la notificación firmada o pregunta al proveedor directamente, servidor a servidor. Hasta que llega una de esas dos respuestas, el pedido permanece pendiente y una nota del pedido lo indica.

Copie la dirección desde la pestaña Bank API.
Mollie es la excepción y no necesita que se pegue nada en ningún sitio: MevvPos envía la dirección con cada pago que crea. Se omite cuando el sitio responde en una dirección local, porque Mollie no podría alcanzarla de todos modos — durante el desarrollo local el resultado viene en cambio de la consulta de estado.
Péguela en el panel propio del proveedor exactamente tal como aparece. Square calcula su firma sobre la dirección de notificación junto con el cuerpo, así que una diferencia de un solo carácter — basta una barra final — hace que todos los eventos fallen la verificación, silenciosamente.
Guarde el secreto de firma que el proveedor devuelve en el campo adicional de ese proveedor.
Envíe un evento de prueba desde el panel del proveedor y compruebe que un pedido realmente se mueve.

Mollie no firma en absoluto su notificación — el cuerpo no lleva más que un id de pago. Eso parece inseguro y de hecho es más seguro: MevvPos no confía en la notificación, la trata como un timbre. Toma el id y pregunta directamente a Mollie cuál es el estado del pago, y solo una respuesta paid produce un evento. Un atacante puede tocar el timbre con un id inventado pero no puede falsificar la respuesta de Mollie, así que una notificación falsa nunca puede marcar un pedido como pagado. Si no se puede contactar con Mollie, la respuesta es “no lo sé” y nada cambia.

La firma de PayPal tampoco se verifica localmente. Es una cadena de certificados, y un error silencioso al verificar una cadena hace que la firma carezca de sentido; PayPal publica un endpoint para ello, y cualquier cosa distinta de SUCCESS significa que el evento se ignora.

Tres reglas valen para todos los proveedores. La respuesta es siempre un 200 vacío — un evento verificado, un duplicado y basura reciben todos la misma respuesta, porque una respuesta diferente le diría a un atacante qué intento estuvo más cerca, y una respuesta de error solo haría que el proveedor reintentara un evento que nunca podrá verificarse. PayTR es la única excepción, porque quiere el texto literal OK y repite la notificación durante horas sin él. El mismo evento entregado dos veces no tiene un segundo efecto. Y contra qué cuenta se verifica un evento se lee de su propia configuración, nunca de la solicitud — de lo contrario un atacante podría elegir la clave con la que se comprueba su propia falsificación.

El webhook no pasa por el endpoint de WooCommerce. Tiene su propia variable de consulta y se captura antes de que el tema, la página y la maquinaria de consultas lleguen a ejecutarse — lo cual también explica por qué funciona en un sitio sin WooCommerce instalado.

Enrutamiento basado en BIN

Los primeros seis dígitos de una tarjeta identifican al banco que la emitió. MevvPos hace coincidir exactamente esos seis dígitos.

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 actualiza cada semana desde nuestros servidores. La actualización se fusiona sobre la tabla empaquetada en lugar de sustituirla: una respuesta parcial o vacía no debe dejar nunca a una tienda sin datos de BIN.
Una respuesta que traiga menos de cien BIN se rechaza por inverosímil y no se escribe.
Los conflictos — el mismo BIN reclamado por dos bancos — se resuelven en nuestro lado antes de enviar la lista. Una tienda que los resolviera localmente podría contar una tarjeta como “nuestra” y enrutarla a otro sitio al mismo tiempo.

Un BIN no reconocido nunca se rechaza. Cae en su POS predeterminado. Rechazar una tarjeta que simplemente no tenemos fichada sería perder una venta para proteger una tabla de consulta.

La misma tabla responde a una segunda pregunta, distinta, en el proceso de pago: ¿es esta tarjeta del propio banco de este POS? Eso es lo que decide si se ofrecen cuotas — véase más abajo.

La exactitud de los BIN no es una función de pago. Lo que Pro paga es la actualidad, no la corrección: la lista empaquetada es la misma lista, solo congelada en el momento de la compilación.

Cuotas y comisión

Las tasas se fijan por POS, desde el pago único hasta doce plazos, en la pestaña Plazos y comisiones. Son porcentajes: escriba 5.50 para 5,5%.

Esto funciona en ambas superficies de pago. En la página de bloques, la tabla de plazos la dibuja el propio bloque y el recargo se añade al carrito como una tarifa, exactamente igual que en la página clásica, de modo que elegir un plazo actualiza el total antes de hacer el pedido.

Las cuotas son una institución turca y la pestaña lo sabe. Mientras un proveedor internacional está seleccionado, la tabla de tasas no se muestra en absoluto, y la pestaña lo explica en una frase en su lugar: rellenar doce filas que nunca podrían aplicarse sería una forma de inducirle a error.

0: La opción se muestra y no se añade comisión.
Vacío: La opción no se muestra en absoluto. Vacío y cero no son lo mismo.

La comisión aparece en el carrito como una tarifa sujeta a impuestos llamada “N Taksit Komisyonu” (comisión de N cuotas), calculada sobre el total del carrito incluidos envío e impuestos.

Las cuotas se ofrecen solo con tarjetas emitidas por el propio banco de ese POS, y esto se aplica en el servidor — no se limita a ocultarse en la interfaz. Una tarjeta de otro banco se fuerza de vuelta al pago único y la tarifa se elimina.

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.

El formulario de ajustes siempre muestra los doce campos, sea cual sea su licencia. Si desaparecieran al caducar una licencia, guardar la página borraría en silencio tasas que ya había introducido. Los campos por encima de su límite se marcan como «Se desbloquea en Pro» y sus números se conservan.

No hay ninguna tabla de cuotas suministrada por el banco. Las tasas son las que usted introduce, y la comisión de un pedido pasado se calcula con la tasa que se aplicaba el día de la venta — cambiar una tasa hoy no reescribe el informe de ayer.

El flujo de pago y el tratamiento de la tarjeta

Todas las familias turcas pasan por 3-D Secure. No hay modo sin 3D ni ajuste para desactivarlo. En el lado internacional MevvPos habla EMV 3-D Secure 2: registra si el pagador se autenticó con o sin verificación adicional, envía al cliente al banco cuando el emisor la pide y lee el ECI para registrar si se transfirió la responsabilidad por contracargo. Dos cosas que deliberadamente no hace: nunca reclama una exención para la que el proveedor no tiene campo, y nunca informa la responsabilidad como tuya cuando el proveedor no nos comunica el resultado: «no lo sabemos» y «la responsabilidad es del comercio» son respuestas distintas.

Flujo por formulario: NestPay, Garanti, PayTR y Sipay: el navegador envía un formulario firmado al banco, el cliente se autentica y el banco vuelve a su sitio.
Flujo por servidor: VakıfBank, iyzico y Craftgate: su servidor habla con el proveedor, obtiene la página 3-D, la muestra y completa la venta de servidor a servidor tras la autenticación.
Flujo de redirección: Stripe, PayPal, Mollie, Square, Checkout.com, Razorpay y Paystack: MevvPos crea el pago a través de la API REST del proveedor y envía al cliente a la dirección que el proveedor devuelve.
Flujo de formulario con token: Authorize.Net: el proveedor devuelve un token en lugar de una dirección, y el token se envía por POST a su página alojada como un formulario. Escribir el token en una URL lo filtraría en el historial del navegador y en los registros del servidor.

Los bancos turcos siempre vuelven a una dirección en su sitio: ?wc-api=mevvpos_callback. La firma de ese retorno se verifica usando la clave del POS que el pedido realmente usó, registrada en el propio pedido — con más de un POS, verificar contra la clave equivocada produce un error de hash en cada pago.

La tarjeta nunca llega a su base de datos. Se mantiene en el navegador durante lo que dura la redirección y se elimina después. Si no está allí cuando se carga la página de pago — una pestaña nueva, una recarga, el almacenamiento deshabilitado, una vuelta atrás desde el banco — se muestra un formulario de tarjeta visible en lugar de enviar campos vacíos al banco. El formulario de tarjeta es visible por defecto, a propósito: un flujo de pago no puede depender de que JavaScript se haya ejecutado.

Cuando el banco aprueba el pago, el pedido se completa aunque el código de estado 3-D fuera inesperado — una nota de pedido registra la anomalía y le pide que la confirme desde la propia pantalla del banco. Si el banco dice aprobado, al cliente ya se le ha cobrado; rechazarlo significaría “se le cobró la tarjeta pero su pedido falló”.

Cada intento registra el POS usado, el banco y el BIN de la tarjeta, el número de cuotas y la tasa, el resultado, el código y el mensaje de respuesta del banco, y las referencias de autorización y de transacción.

Preautorización, enlaces de pago y reglas de riesgo

Autoriza ahora, captura después

Cada registro POS lleva un método de cobro: cobrar de inmediato, o retener el importe y cobrarlo más tarde. Con el segundo, el dinero se reserva en la tarjeta al pagar y la pantalla del pedido gana dos botones — capturar (todo, o una parte) y liberar. Captúralo cuando salga el paquete; libéralo cuando no puedas suministrar.

El ajuste solo aparece donde el proveedor lo lleva de verdad: la familia de bancos NestPay (İşbank, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat) más Stripe, Authorize.Net y Checkout.com. Para el resto de proveedores la opción no se ofrece en absoluto, en lugar de ofrecerse y fallar luego en la pasarela.

Un enlace de pago

La pantalla Enlaces de pago crea un enlace por un importe y, opcionalmente, una descripción y una caducidad. Quien lo abra aterriza en la página de pago habitual de la tienda con un pedido pendiente ya creado, lo que significa el mismo enrutamiento BIN, la misma tabla de plazos y el mismo paso de 3-D Secure que cualquier otro pago. Nada es un atajo que rodee el motor de pago.

El token son 32 bytes aleatorios; la dirección no se puede adivinar a partir de otra.
El enlace caduca en la fecha que fijes.
Funciona una vez. Una vez pagado el pedido el enlace deja de abrirse, así que un mensaje reenviado no se puede pagar dos veces.

Reglas de riesgo

La pantalla Riesgo contiene cinco reglas, cada una se activa y recibe su propio umbral por separado. Se evalúan antes de enviar la tarjeta a ningún proveedor, y cada una puede marcar el pedido, retenerlo para revisión o rechazarlo directamente.

Intentos por dirección — cuántos intentos de pago puede hacer un visitante en una ventana de tiempo.
Intentos por tarjeta — el mismo recuento para una sola tarjeta.
Fallos consecutivos — una racha de rechazos seguidos.
Discrepancia de país — una tarjeta emitida en Türkiye con una dirección de facturación fuera de Türkiye.
Techo de importe — un total de pedido por encima del cual quieres mirar antes.

No se anota ninguna dirección ni ningún número de tarjeta. Lo que guardan los contadores es un resumen con sal de la clave de tu propio sitio, de modo que las reglas pueden reconocer una repetición sin que la pantalla se convierta nunca en una segunda base de datos de tarjetas. No hay huella de dispositivo, ni puntuación aprendida por máquina, ni lista negra de BIN — cinco reglas que puedes leer, y nada que no puedas explicarle a un cliente.

Reembolsos

Para los proveedores internacionales, los reembolsos se emiten desde la pantalla de pedidos de WooCommerce de la manera habitual — total o parcial. MevvPos envía el reembolso al proveedor contra la referencia de pago registrada en el pedido.

Los reembolsos nunca están limitados por la licencia. No poder devolverle su dinero a un cliente no es algo que un recordatorio de renovación tenga permitido causar, y además en la mayoría de los países es una obligación legal.

El POS virtual de bancos turcos todavía no se puede reembolsar desde WordPress, y MevvPos lo dice en lugar de fingir. Reembolse la transacción desde la pantalla propia de su banco. Reportar éxito silenciosamente haría que WooCommerce marcara el pedido como reembolsado mientras el dinero permanecía en el banco — un registro contable erróneo cuesta mucho más que un botón que no funciona.

Un reembolso necesita la referencia de pago que devolvió el proveedor. Un pedido realizado antes de que esa referencia fuera registrada, o uno cuya cuenta de proveedor ha sido eliminada desde entonces, no se puede reembolsar a través del plugin.

Informes

La pestaña Informes muestra los ingresos, las transacciones correctas, la tasa de éxito y el reparto entre pago único y plazos, con un gráfico diario. Las transacciones que aún esperan respuesta del banco se cuentan aparte y quedan fuera de la tasa de éxito.

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

Carga de cuotas y comisiones — número, ingresos y carga de comisión por nivel de cuotas.
Desglose por POS y banco — ingresos, éxitos, fallos y tasa de éxito para cada POS y para cada banco emisor.
Distribución de códigos de rechazo — con exportación CSV. Un código de rechazo que se repite señala algo que usted puede arreglar: fondos insuficientes es problema del cliente, pero los errores de verificación 3-D y de configuración del POS son suyos.

Los datos que hay detrás de los informes los recoge el plugin gratuito, así que el historial se sigue acumulando tenga o no Pro. Tiene que ser así: los datos pasados no se pueden generar retroactivamente cuando actualiza.

Una tienda recién instalada no tiene gráfico. El registro empieza con el plugin, y la pantalla se llena tras el primer intento de pago.

Usar el motor sin WooCommerce

La pasarela de WooCommerce es ahora un consumidor del motor de pagos y no el motor en sí. El motor no sabe nada de pedidos, carritos o sesiones: usted le entrega una intención de pago — un importe como número entero de unidades menores, una moneda, una referencia y las direcciones de retorno — y él le devuelve o bien un formulario para enviar por POST o una dirección a la que redirigir. Un plugin de formularios, un plugin de reservas o su propio código pueden gestionarlo de la misma manera que lo hace el checkout.

MevvPos_Payment_Engine::start() inicia un pago y devuelve lo que el navegador debe hacer a continuación.
MevvPos_Payment_Engine::handle_webhook() es la única vía que cambia el estado de un pago. Un evento cuya firma no se verifica no cambia nada y queda registrado.
MevvPos_Payment_Engine::webhook_url() construye la dirección que pega en el panel del proveedor.
El tope de cuotas también se aplica dentro del motor, como última línea de defensa — la pantalla que lo llama pudo haberse renderizado antes de que la licencia caducara.

Si registró su propio proveedor a través del filtro mevvpos_providers antes de la versión 4.0.0, ahora recibe una intención de pago en lugar de un WC_Order. Las solicitudes y firmas de las siete familias turcas no han cambiado, así que las configuraciones de POS existentes siguen funcionando sin tocarlas.

Solicitudes de banco y soporte

Solicitud de banco: Enumera todas las entidades que aún no están implementadas, con el motivo: o bien no se ha determinado la familia de protocolo, o bien la familia se conoce y estamos esperando la documentación. Puede abrir una solicitud para una de ellas, o nombrar una entidad que no esté en la lista en absoluto.
Soporte: Un asunto, el POS o el banco en cuestión, qué ocurre cuando hace qué, y el mensaje de error que mostró el banco.

El formulario de soporte le pide que no incluya ningún número de tarjeta ni código de seguridad. Nunca hacen falta para diagnosticar un problema de pago, y con ninguno de los dos formularios se envía dato alguno de pago o de tarjeta.

El plugin gratuito contacta con nuestros servidores solo cuando usted pulsa uno de estos botones. No se envía nada de forma programada y en la edición gratuita no hay ninguna llamada de licencia.

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

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

Cuando una licencia expira o falta:

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.
Los reembolsos siguen funcionando, porque no están limitados en absoluto.
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.
La actualización de BIN en vivo se detiene; la tabla empaquetada sigue funcionando.

Si nuestros servidores no están accesibles, una licencia activa sigue funcionando durante siete días apoyándose en la última comprobación correcta. Pero una licencia cuya propia fecha de vencimiento ha pasado se lee como caducada de todos modos — de lo contrario, bloquear nuestra dirección sería una manera de alargar una licencia una semana.

Actualizaciones

El plugin Pro lleva un actualizador ligado a su licencia. Tiene que ser así: Pro no está publicado en WordPress.org, así que no hay dónde WordPress pueda enterarse de que existe una nueva versión. Con una licencia activa, una actualización de Pro aparece en la pantalla de plugins como cualquier otra.

El plugin gratuito ahora también anuncia sus propias actualizaciones. Pregunta a nuestro servidor si existe una versión más nueva y entrega la respuesta al propio flujo de actualización de WordPress, de modo que una nueva versión aparece en la pantalla de plugins con un botón Actualizar corriente en lugar de esperar a que alguien descargue un zip a mano. La petición lleva solo el nombre del paquete y la versión instalada: ninguna dirección del sitio, ningún correo electrónico, ninguna clave de licencia, ningún inventario de plugins. Como nada en ella le identifica, la confianza descansa por completo en la firma: la respuesta va firmada con nuestra clave Ed25519, y una respuesta sin firma, mal firmada, repetida desde una marca de tiempo antigua o que apunte la descarga a cualquier host que no sea el nuestro se descarta sin tocar el sitio. Sus registros de TPV, credenciales e historial recogido viven en las opciones de WordPress y en los metadatos del pedido, y una actualización nunca los toca.

Cuando algo no funciona

El banco rechaza todos los pagos sin ningún mensaje útil: Casi siempre es la firma. Una firma incorrecta no genera ningún error en ninguna parte — el banco simplemente deniega. Compruebe el número de comercio, la clave del comercio y las credenciales adicionales de esa familia: todas entran en la firma. Una prueba útil es que los bancos responden de forma distinta a un error de firma y a una tarjeta no válida; recibir un mensaje de “tarjeta no válida” significa que su firma es correcta.
“Error de hash” en el retorno, con más de un POS: El retorno es una petición aparte, sin sesión. MevvPos registra qué POS usó cada pedido y verifica con esa clave. Si borró el registro de POS por el que se pagó un pedido, la verificación recae en el POS predeterminado y puede fallar.
El cliente paga en Stripe o PayPal pero el pedido permanece pendiente: La dirección del webhook no es accesible o no está registrada. El pedido se completa mediante la notificación, no mediante el retorno del cliente, así que un webhook ausente se ve exactamente igual que un cliente que nunca pagó. Compruebe que la dirección de la pestaña Bank API es la misma que la guardada en el panel del proveedor, y que el evento de prueba del proveedor llega.
Todos los eventos de Square son rechazados: Square firma la dirección de notificación junto con el cuerpo. La dirección registrada en Square debe coincidir carácter por carácter con la de la pestaña Bank API — basta una barra final, http en lugar de https, o un www que un lado tiene y el otro no.
Los eventos de Authorize.Net nunca se verifican: La Signature key es un valor distinto de la Transaction Key y es fácil confundirlas. Los webhooks se verifican solo con la Signature key.
El cliente llega a una página de pago en blanco, o el botón Öde (Pagar) no hace nada: Un plugin de caché o de optimización está aplazando los scripts. En LiteSpeed, excluya mevvpos, jquery y los scripts públicos de WooCommerce de la lista de retardo. El formulario de tarjeta se muestra por defecto para que el flujo siga funcionando, pero la redirección automática no.
El pedido se queda en “pendiente” tras un pago correcto: El banco o el proveedor no llegó a la dirección de retorno. Compruebe que ?wc-api=mevvpos_callback es accesible desde fuera — un modo de mantenimiento, una restricción por IP o un muro de inicio de sesión delante del sitio lo bloquearán.
El formulario de pago se envía a la misma página: El campo Gate URL está vacío para un banco cuya dirección no viene rellenada. Introduzca la dirección que le dio su banco o proveedor.
El modo de prueba está activado pero el pago sigue yendo al banco real: El modo de prueba detiene la redirección automática y le muestra la solicitud; no reescribe la dirección de la pasarela para los bancos NestPay. Ponga la dirección de prueba de su banco en Gate URL mientras prueba. En Stripe y Mollie el interruptor tampoco cambia la dirección — ahí lo que selecciona el sandbox es la clave de prueba.
Las cuotas no aparecen: 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.
Las tarjetas van al POS equivocado tras una actualización: Las versiones antiguas llevaban rangos de BIN escritos a mano que en parte eran incorrectos. Compruebe que cada POS está archivado bajo el banco con el que realmente está.
La pantalla de administración se ve sin estilos, o una corrección no aparece: Una caché del navegador obsoleta. Recargue la página saltándose la caché.

Límites

La lista de abajo es deliberada. Nada de eso es un error.

Sin reembolsos para el POS virtual de bancos turcos. Ninguna familia turca incluye una llamada de reembolso; reembolse desde la pantalla de su propio banco. Los los proveedores internacionales sí, y WooCommerce muestra el botón de reembolso para ellos.
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.
Los pagos recurrentes funcionan solo con los proveedores internacionales, y no hay selector de tarjetas guardadas. Se crea, renueva, reintenta y marca como vencido un permiso de cobro almacenado, y un producto de WooCommerce Subscriptions lo configura sin escribir código. Lo que falta: las familias de POS virtual de bancos turcos no pueden llevarlo, el comprador no puede elegir una tarjeta guardada al pagar, y no hay calendario de reintentos ni cancelación desde el panel.
La preautorización existe, pero no en todas partes. Un POS puede retener el importe y capturarlo más tarde — total o parcialmente — desde la pantalla del pedido, o liberarlo. Solo lo llevan la familia de bancos NestPay, Stripe, Authorize.Net y Checkout.com; cualquier otro proveedor es una venta directa y el ajuste no se muestra para ellos.
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.
Se admiten las dos páginas de pago. Se sirven tanto el formulario de pago clásico como el bloque Checkout de WooCommerce, y la tabla de plazos y su recargo se comportan igual en ambos. El bloque escribe el BIN y el plazo elegidos a través de la Store API, así que el recargo lo calcula el mismo código que en la página clásica.
3D Pay Hosting se rechazó a propósito. La página alojada elimina el alcance PCI pero también elimina el BIN y la tabla de cuotas — y todo el valor del lado de Türkiye está en el enrutamiento que estos hacen posible. Los proveedores internacionales están alojados precisamente porque ahí no hay nada que enrutar.
Sin editor de BIN. La tabla la gestionamos nosotros y se fusiona con la actualización en vivo; no hay ninguna pantalla para editarla a mano.
Hay veintiséis entidades listadas pero no implementadas. Siguen visibles para que la carencia sea visible.
Todos los proveedores salvo NestPay están declarados beta por nosotros mismos hasta que se hayan verificado de extremo a extremo con una cuenta de comercio real.
Las pestañas están dentro de la página. Las entradas de la barra lateral abren la pantalla de MevvPos; cambie de pestaña en la propia página.

Lo que nunca se almacena, de ninguna forma: el número de tarjeta, la fecha de caducidad y el código de seguridad. En el lado de Türkiye el único dato de tarjeta que se guarda son los primeros seis dígitos y el banco que identifican; con los proveedores internacionales ni siquiera eso, porque la tarjeta nunca se escribe en su sitio. Almacenar el código de seguridad está prohibido en cualquier circunstancia, e incluso uno enmascarado filtra su longitud.

Un motor: el POS virtual de bancos turcos y los proveedores internacionales.