Refund a Payment

Refund operations (DEVOLUCION) allow merchants to return funds to a cardholder after a successful payment. Get Central supports multiple refund flows, depending on whether the original transaction, the physical card, or both are available at the time of the refund.

This guide applies to Slim Pack.

A refund always results in a financial reversal of a previously authorized and captured payment.

Requirements

Before initiating a refund, ensure the following conditions are met:

• the TPVPC initialized and operational

• Refund capability enabled for the merchant and terminal

• At least one of the following available:

  • Physical card used in the original transaction, or
  • Original transaction identifiers

Refunds may be full or partial, depending on configuration and issuer rules.

Refund Models

Get Central supports the following refund scenarios:

1. Refund with card present – the original card is read again on the PIN pad
2. Refund with original reference – the refund is executed using data from the original transaction
3. Refund without original – the refund is executed without original transaction data (if enabled)

All refund models use the same operation type: DEVOLUCION.

Refund Process

A refund is performed by invoking the appropriate TPVPC function with the required parameters. The TPVPC returns an XML response that must be validated to determine whether the refund was authorized.

Step 1: Call the function that matches the flow

Each refund flow has its own function. None of them is fnDllOperPinPad, which handles payments and pre-authorizations only.

Only fnDllOperComContable takes a cTipoOper, because it serves both refunds and confirmations: set it to DEVOLUCION for a refund, or CONFIRMACION to capture a pre-authorization. The other two functions carry the operation in their own name.

The refund amount must be less than or equal to the original captured amount.

Here is a referenced refund:

StringBuilder xmlResponse = new StringBuilder(8192);

int result = fnDllOperComContable(
    "123456",           // cNumPedido — original order
    "",                 // cRTSOriginal — recommended when available
    "5.00",             // cImporte
    "REF-2024-001",     // cFactura
    "DEVOLUCION",       // cTipoOper
    xmlResponse,
    xmlResponse.Capacity
);

A return value of 0 indicates that the operation was processed. It does not confirm authorization.

Step 2: Validate the Refund Result

After execution, the TPVPC returns an XML response. A refund must be considered AUTHORIZED only if the response contains:

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

Any other combination must be treated as DENIED.

Here is an example of an authorized refund:

<resultadoOperacion>
  <tipoPago>DEVOLUCION</tipoPago>
  <importe>5.00</importe>
  <moneda>978</moneda>
  <pedido>REF-2024-001</pedido>
  <estado>F</estado>
  <resultado>Autorizada</resultado>
</resultadoOperacion>

Persistence Requirements

For reconciliation and auditing purposes, store at least:

• Refund reference (factura)
• Original transaction reference (pedido)
• Authorization result and response codes

Next Steps

After processing a refund, you can proceed with further reconciliation and management tasks:

• For details on generating and printing compliant receipts for the cardholder, see the Generate and Print Receipts documentation.
• To learn more about standard point-of-sale payments, refer to the Create a Single-Step Payment guide.
• For a complete catalog of transaction statuses and host error codes, see the Result Codes and Errors documentation.