Crear un pago recurrente

Get Central soporta pagos recurrentes a través de un modelo basado en token gestionado por el host de autorización. Este modelo permite a los comercios realizar pagos sucesivos sin la presencia del titular de la tarjeta, siempre que el titular de la tarjeta haya autorizado explícitamente la primera transacción.

Esta guía se aplica a Slim Pack.

Los pagos recurrentes siguen un modelo estricto de dos fases definido por la plataforma:

Primer pago recurrente – una transacción inicial con tarjeta presente que genera un token reutilizable
Pagos sucesivos recurrentes – pagos con tarjeta no presente utilizando el token almacenado

Requisitos

Antes de comenzar, asegúrate de cumplir con los siguientes requisitos previos:

Get Central (TPVPC) instalado e inicializado con éxito a través de fnDllIniTpvpcLatente
Capacidad de pago recurrente habilitada para el comercio y el terminal
PIN pad físico disponible para la transacción inicial
Una capa de persistencia segura para almacenar los valores de token no sensibles

El comercio nunca debe almacenar números de tarjeta (PAN). Solo se puede almacenar el valor de token que devuelve el TPVPC.

Modelo de pago recurrente

Los pagos recurrentes no son un tipo de transacción separado. Se ejecutan como operaciones PAGO estándar con parámetros adicionales que solicitan la generación de un token recurrente durante la primera transacción y proporcionan ese token para los cargos posteriores.

Paso 1: Ejecutar el primer pago recurrente

El ciclo de vida recurrente comienza con un pago con tarjeta presente. Funcionalmente, se trata de una venta normal marcada como la primera operación recurrente.

Para iniciar este paso, activa primero el modo recurrente y ejecuta después una operación de pago estándar con el PIN pad. La activación dura la sesión de funcionamiento: cada llamada a fnDllIniTpvpcLatente la desactiva, así que hay que repetirla después de cada inicialización.

fnDllActivaRecurrente()

Con el modo activo, el pago se ejecuta con los parámetros habituales de fnDllOperPinPad:

Parámetro	Tipo	Requerido	Descripción
`cImporte`	String	Sí	Importe de la transacción en formato `XXXXXXXXX.XX`. Se recomienda un importe real.
`cFactura`	String	Sí	Referencia de compra que identifica la suscripción o al cliente.
`cTipoOper`	String	Sí	Debe establecerse en `PAGO`.
`cXMLResp`	Buffer	Sí	Buffer de salida que recibirá la respuesta XML.
`iTamMaxResp`	Integer	Sí	Tamaño máximo del buffer de respuesta (mínimo recomendado: `8192`).

A continuación se muestra un ejemplo de cómo ejecutar el primer pago recurrente:

fnDllActivaRecurrente();

StringBuilder xmlResponse = new StringBuilder(8192);

int result = fnDllOperPinPad(
    "29.90",            // cImporte
    "SUB-USER-001",     // cFactura
    "PAGO",             // cTipoOper
    xmlResponse,
    xmlResponse.Capacity
);

if (result != 0)
{
    // Technical execution error. Do not proceed.
}

El valor de retorno entero solo indica si el proceso se ejecutó correctamente. No indica autorización.

Paso 2: Validar el primer pago y almacenar el token

Tras la ejecución, el TPVPC devuelve un documento XML que describe el resultado de la transacción.

La transacción debe considerarse AUTORIZADA solo si el XML contiene ambos:

<estado>F</estado>
<resultado>Autorizada</resultado>

Si es autorizada, la respuesta XML trae un campo <token> generado por el host. Ese valor representa la tarjeta para futuros pagos.

Debes almacenar de forma segura al menos:

Tu referencia de compra (cFactura)
El valor <token> devuelto en la respuesta XML
Resultado de la autorización y códigos de respuesta

Guarda el token antes de desactivar el modo recurrente.

Paso 3: Desactivar el modo recurrente

Mientras el modo recurrente está activo, todas las operaciones que ejecutes llevan el token recurrente, no solo la primera. Desactívalo en cuanto termine el primer pago:

fnDllDesActivaRecurrente()

Las operaciones posteriores a esta llamada vuelven a ser pagos normales. Inicializar la biblioteca también desactiva el modo, así que un fnDllIniTpvpcLatente nuevo lo deja apagado.

Slim Pack documenta únicamente el primer pago recurrente. Cobrar un token almacenado en una sesión posterior requiere fnDllOperRecurrente, que la biblioteca Slim Pack no expone: consulta Crear un pago recurrente (TPVPC Implantado).

Próximos pasos

Después de implementar los pagos recurrentes, puedes continuar con tareas operativas y de gestión adicionales:

Para revertir un cargo recurrente o gestionar devoluciones de fondos, consulta la guía Devolver un pago.
Para obtener detalles sobre cómo generar e imprimir recibos conformes para cargos de suscripción, consulta la documentación Generar e imprimir recibos.
Para comprender cómo reservar fondos antes de un cargo recurrente, consulta la guía Crear un pago preautorizado.