# Create a Recurring Payment

Get Central supports **recurring payments** through a **token-based model** managed by the authorization host. This model allows merchants to perform subsequent charges **without cardholder presence**, provided that the cardholder has explicitly authorized the first transaction.

This guide applies to **Slim Pack**.

Recurring payments follow a strict two-phase model defined by the platform:

1. **First recurring payment** – an initial **card-present** transaction that generates a reusable token
2. **Subsequent recurring payments** – **card-not-present** charges using the stored token

## Requirements

Before you begin, ensure the following prerequisites are met:

* **Get Central** (TPVPC) installed and successfully initialized via `fnDllIniTpvpcLatente`
* **Recurring payment capability** enabled for the merchant and terminal
* **Physical PIN pad** available for the initial transaction
* A **secure persistence layer** to store non-sensitive token values

The merchant must **never store card numbers (PAN)**. Only the token value returned by the TPVPC may be persisted.

## Recurring Payment Model

Recurring payments are not a separate transaction type. They are executed as **standard `PAGO` operations** with additional parameters that request generation of a recurring token during the first transaction, and provide that token for subsequent charges.

## Step 1: Execute the First Recurring Payment

The recurring lifecycle begins with a **card-present payment**. Functionally, this is a normal sale marked as the first recurring operation.

To start this step, activate recurring mode first, then run a standard PIN pad payment. The activation lasts for the operating session: every call to `fnDllIniTpvpcLatente` deactivates it, so it has to be repeated after each initialization.

```
fnDllActivaRecurrente()
```

With the mode active, the payment runs with the usual `fnDllOperPinPad` parameters:

| Parameter     | Type    | Required | Description                                                                |
| ------------- | ------- | -------- | -------------------------------------------------------------------------- |
| `cImporte`    | String  | Yes      | Transaction amount in format `XXXXXXXXX.XX`. A real amount is recommended. |
| `cFactura`    | String  | Yes      | Purchase reference identifying the subscription or customer.               |
| `cTipoOper`   | String  | Yes      | Must be set to `PAGO`.                                                     |
| `cXMLResp`    | Buffer  | Yes      | Output buffer that will receive the XML response.                          |
| `iTamMaxResp` | Integer | Yes      | Maximum size of the response buffer (minimum recommended: `8192`).         |

Here is an example of the first recurring payment:

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

The integer return value only indicates whether the process executed correctly. It does **not** indicate authorization.

## Step 2: Validate the First Payment and Store the Token

After execution, the TPVPC returns an XML document describing the transaction result.

The transaction must be considered **AUTHORIZED** only if the XML contains **both**:

```xml
<estado>F</estado>
<resultado>Autorizada</resultado>
```

If authorized, the XML response carries a **`<token>`** field generated by the host. That value represents the card for future charges.

You must securely persist at least:

* Merchant reference (`cFactura`)
* The `<token>` value returned in the XML response
* Authorization result and response codes

Store the token before you deactivate recurring mode.

## Step 3: Deactivate recurring mode

While recurring mode is active, **every** operation you run carries the recurring token — not only the first one. Turn it off as soon as the first payment is done:

```
fnDllDesActivaRecurrente()
```

Operations run after this call are ordinary payments again. Initializing the library also deactivates the mode, so a fresh `fnDllIniTpvpcLatente` leaves it off.

<Callout type="note">

Slim Pack documents the first recurring payment only. Charging a stored token from a later session requires `fnDllOperRecurrente`, which the Slim Pack library does not expose — see [Create a Recurring Payment (TPVPC Implantado)](/en/get-central/tpvpc-payment-guides/handle-recurring-payments).

</Callout>

## Next Steps

After implementing recurring payments, you can proceed with further operational and management tasks:

* To reverse a recurring charge or manage fund returns, refer to the [Refund a Payment](/en/get-central/slim-pack-payment-guides/process-a-refund) guide.
* For details on generating and printing compliant receipts for subscription charges, see the [Generate and Print Receipts](/en/get-central/slim-pack-payment-guides/generate-and-print-receipts) documentation.
* To understand how to reserve funds before a recurring charge, consult the [Create a Pre-authorized Payment](/en/get-central/slim-pack-payment-guides/process-a-pre-authorization) guide.