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:

Here is an example of the first recurring payment:

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:

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

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 guide.
• For details on generating and printing compliant receipts for subscription charges, see the Generate and Print Receipts documentation.
• To understand how to reserve funds before a recurring charge, consult the Create a Pre-authorized Payment guide.