Saltar a contenido

Cobrar sin Convoca Members

El gateway no necesita a nadie para cobrar. No requiere convoca-members ni convoca-enroll: con convoca-core y convoca-gateway activos hay una página de pago que acepta cantidad, concepto y correo, y cobra por Redsys o por transferencia. Así lleva meses funcionando en Lugg.

Hasta ahora esa página no estaba montada en biodevas: había core y el tema, y el pago lo hacía un plugin antiguo (boton-pago-redsys). Esto es lo que hay que hacer para montarla, y lo que se aprendió haciéndolo.

Montar la página

  1. Crear una página con el shortcode [convoca_pago]. Después de elegir método, pide importe, concepto y correo, y redirige a la pasarela.
  2. Crear la de vuelta: [convoca_pago_ok] en la página de pago correcto y [convoca_pago_ko] en la de error. Sin ellas, Redsys devuelve al usuario a una página que no dice nada.
  3. Configurar la pasarela en Gateway → General: código de comercio (FUC), terminal, entorno y clave secreta. El diagnóstico dice si la clave se descifra, que es lo que importa: una clave con pinta correcta que no descifra deja los pagos bloqueados sin dar error en ninguna parte.
  4. Seleccionar las páginas de retorno en Gateway → Páginas de pago.

Si la instalación ya tenía el plugin antiguo boton-pago-redsys, las claves están ahí: fuc, terminal, clave (producción) y clave_t (pruebas), con el modo en modo. Son las mismas.

El aviso de privacidad

El formulario informa antes del botón: responsable, finalidad, base jurídica, destinatarios y derechos, con enlace a la política. El texto y el enlace se configuran en Gateway → Privacidad porque el responsable del tratamiento es de cada entidad, no del plugin. Si no se configuran, se usa un texto con el nombre del sitio y la página de privacidad de WordPress, y el diagnóstico avisa de que falta ponerlo.

No hay casilla de «acepto la política de privacidad», y no es un olvido. La base jurídica de un pago es la ejecución de un contrato (art. 6.1.b RGPD), no el consentimiento: una casilla no añade nada. Lo que la ley exige es informar (art. 13) en el momento de recoger los datos, y eso es la línea informativa. La AEPD ha señalado justamente esa fórmula como el patrón que sustituye la información por finalidad: la política de privacidad no se acepta, se informa.

Donde sí hace falta casilla es para lo que el contrato no cubre —boletín, cesión a terceros que no son necesarios para el pago—, y ahí va aparte, opcional y sin premarcar.

El requisito que nadie mira: try_files y los query strings

En biodevas, /pago/?convoca_gateway_method=tarjeta mostraba el primer paso del formulario, una y otra vez, como si el parámetro no existiera. No era el plugin: era nginx.

# MAL: $is_args añade una «?» que ya está puesta → «/index.php??convoca_gateway_method=tarjeta»
try_files $uri $uri/ /index.php?$is_args$args;

# BIEN
try_files $uri $uri/ /index.php?$args;

Con $is_args$args el ? se duplica y el query string deja de llegar a WordPress en todas las URLs bonitas. El síntoma no es un error: es que los parámetros desaparecen. Se nota primero en el pago, pero estaba rompiendo también la búsqueda del sitio (/?s=algo devolvía la portada como si no hubiera buscado) y cualquier filtro o paginación por parámetro.

Cómo distinguirlo en un minuto:

curl -s "https://SITIO/?s=prueba" | grep -o '<title>[^<]*</title>'   # ¿dice «Has buscado…»?

Si devuelve el título normal, los query strings no están llegando.

Y dos trampas del diagnóstico, porque me costaron tiempo:

  • En este servidor sites-enabled/biodevas.org es un fichero real, no un symlink a sites-available. Editar el de sites-available no cambia nada. Lo que manda se comprueba con nginx -T | awk '/server_name biodevas.org/,/^}/' | grep try_files.
  • La caché FastCGI cachea los 301 durante 60 minutos (fastcgi_cache_valid 200 301 302 60m) y su clave incluye $request_uri, así que una redirección vieja sobrevive a purgar Redis y a recargar nginx. Se limpia con find /var/nginx-cache -type f -delete.

Comprobar que cobra, sin cobrar

Antes de dar por buena una configuración, se puede verificar la criptografía sin enviar nada a la pasarela: construir los parámetros y firmarlos.

$b64   = \Convoca\Gateway\Redsys_Client::build_merchant_params( $params );
$firma = \Convoca\Gateway\Redsys_Client::sign( $b64, 'PRUEBA0001' );
// HMAC_SHA256_V1 · firma de 44 caracteres en base64 · determinista

Si eso sale, las claves son válidas y el flujo está bien armado. Lo que no demuestra es que Redsys acepte el cobro: eso exige un pago real o un entorno de pruebas con sus propias claves.

Migrar desde boton-pago-redsys

Los dos pueden convivir: el plugin antiguo tiene sus propios shortcodes de retorno ([boton_redsys_ok], [boton_redsys_error]) y las páginas de resultado pueden llevar los dos, cada uno en su bloque. Ojo con sustituirlos en vez de añadirlos: quitarlos deja sin confirmación el flujo antiguo.

Detalle que conviene saber: esos shortcodes, al cargar la página normalmente, pintan «Error: No se han recibido los datos de la operación» — solo funcionan cuando Redsys les pasa el POST del retorno. Un usuario que llegue a «Pago recibido correctamente» sin pasar por la pasarela ve un error.

El orden sensato es: montar y probar Convoca, y después retirar el antiguo.