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 TpvpcImplantado.

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

1. Primer pago recurrente – una transacción inicial con tarjeta presente que genera un token reutilizable
2. 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:

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

El token es la base de todos los pagos posteriores.

Paso 3: Cobrar con el token almacenado

Los pagos sucesivos se realizan sin la presencia del titular de la tarjeta y sin interacción con el PIN pad. Usan fnDllOperRecurrente, que recibe el token directamente: no hace falta tener activado el modo recurrente para llamarla.

La función devuelve en cXMLResp una respuesta análoga a un pago con tarjeta.

StringBuilder xmlResponse = new StringBuilder(8192);

int result = fnDllOperRecurrente(
    "90d264df618c21c527aaf836d61a6cb3d56c4bea",   // cTokenRec
    "29.90",                                      // cImporte
    "SUB-USER-001-M2",                            // cFactura
    xmlResponse,
    xmlResponse.Capacity
);

if (result != 0)
{
    // Technical execution error
}

Paso 4: Validar el resultado del pago

Como en todas las operaciones financieras, el pago es exitoso solo si la respuesta XML contiene:

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

Si la operación es denegada, es posible que el token ya no sea válido — una caducidad de tarjeta, por ejemplo. El cliente debe entonces realizar un nuevo primer pago recurrente.

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.