# 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:

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`:

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

```csharp
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**:

```xml
<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.

<Callout type="note">

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)](/es/get-central/tpvpc-payment-guides/handle-recurring-payments).

</Callout>

## 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](/es/get-central/slim-pack-payment-guides/process-a-refund).
* Para obtener detalles sobre cómo generar e imprimir recibos conformes para cargos de suscripción, consulta la documentación [Generar e imprimir recibos](/es/get-central/slim-pack-payment-guides/generate-and-print-receipts).
* Para comprender cómo reservar fondos antes de un cargo recurrente, consulta la guía [Crear un pago preautorizado](/es/get-central/slim-pack-payment-guides/process-a-pre-authorization).