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

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

The token is what every later charge is built on.

Step 3: Charge with the stored token

Subsequent charges run without the cardholder present and without PIN pad interaction. They use fnDllOperRecurrente, which takes the token directly — recurring mode does not have to be active to call it.

The function returns in cXMLResp a response analogous to a card payment.

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
}

Step 4: Validate the charge result

As with all financial operations, the charge succeeds only if the XML response contains:

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

If the operation is denied, the token may no longer be valid — a card expiry, for example. The customer then has to run a new first recurring payment.

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.