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

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 you must validate 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.

| Flow | Function | Parameters |
| :--- | :--- | :--- |
| Card present | `fnDllComContableTrj` | `cImporte`, `cFactura`, `cNumPedido`, `cRTSOriginal`, `cXMLResp`, `iTamMaxResp` |
| Referenced | `fnDllOperComContable` | `cNumPedido`, `cRTSOriginal`, `cImporte`, `cFactura`, `cTipoOper`, `cXMLResp`, `iTamMaxResp` |
| Without original | `fnDllDevSinOrigTrj` | `cImporte`, `cFactura`, `cXMLResp`, `iTamMaxResp` |

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.

| Parameter | Type | Description |
| :--- | :--- | :--- |
| `cImporte` | String | Amount to refund or confirm, in `XXXXXXXXX.XX` format. Mandatory in Transparent mode. |
| `cFactura` | String | Value the merchant supplies to label the operation. The TPVPC performs no validation on it. |
| `cNumPedido` | String | Order number of the original operation. The `pedido` field appears in every TPVPC operation response. Mandatory in Transparent mode. |
| `cRTSOriginal` | String | RTS identifier of the original transaction. The `identificadorRTS` field appears in every TPVPC operation response. Optional; recommended in Transparent mode. |
| `cTipoOper` | String | `DEVOLUCION` or `CONFIRMACION`. `fnDllOperComContable` only. |
| `cXMLResp` | Buffer | Buffer that receives the XML result. |
| `iTamMaxResp` | Integer | Maximum size of the response buffer. |

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

Here is a referenced refund:

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

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

Any other combination must be treated as **DENIED**.

Here is an example of an authorized refund:

```xml
<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](/en/get-central/tpvpc-payment-guides/generate-and-print-receipts) documentation.
* To learn more about standard point-of-sale payments, refer to the [Create a Single-Step Payment](/en/get-central/tpvpc-payment-guides/process-a-single-step-payment) guide.
* For a complete catalog of transaction statuses and host error codes, see the [Result Codes and Errors](/en/get-central/tpvpc-reference/result-codes-and-errors) documentation.