Request Parameters

This reference lists the public functions and parameters the TpvpcImplantado library exposes, with their exact parameter names and signatures.

This guide applies to TpvpcImplantado.

The tables below reflect the real invocation model used by the library. Parameters are listed exactly as they must appear in code, without aliases, translations, or inferred fields.

Initialization and Lifecycle Functions

These are the functions that are used to initialize and manage the TPVPC lifecycle.

fnDllIniTpvpcLatente

Initializes the TPVPC and opens communication with the PIN pad. This function must be called once when the application starts.

Function signature (C#):

int fnDllIniTpvpcLatente(string cComercio, string cTerminal, string cClaveFirma, string cConfPuerto, string cVersion);

Return value: 0 if initialization succeeds. Any other value indicates a library-level error.

fnDllParaTpvpcLatente

Stops communication and releases all internal resources.

Function signature:

int fnDllParaTpvpcLatente();

This function has no input parameters.

Payment and Financial Operations

All financial operations are executed through exported functions that receive typed parameters and return an XML response buffer. A return value of 0 only indicates that the operation was processed; authorization must always be validated from the XML.

fnDllOperPinPad

Executes a PAGO or PREAUTORIZACION using a physical PIN pad.

Function signature:

int fnDllOperPinPad(string cImporte, string cFactura, string cTipoOper, StringBuilder cXMLResp, int iTamMaxResp);

fnDllOperManualExt

Executes a PAGO or PREAUTORIZACION using manual card data entry.

Function signature:

int fnDllOperManualExt(string cTarjeta, string cCaducidad, string cCVC2, string cImporte, string cFactura, string cTipoOper, StringBuilder cXMLResp, int iTamMaxResp);

Confirmation and Refund Operations

A confirmation captures a previously authorized pre-authorization; a refund returns funds. Both travel through the same family of functions, and which one you call depends on where the card and the original reference come from.

cTipoOper appears only in the two ComContable functions that serve both operations, and takes DEVOLUCION or CONFIRMACION. The others carry the operation in their own name.

Recurring Payments

Recurring mode is a session switch, not a parameter. Two functions toggle it, and neither takes arguments:

fnDllIniTpvpcLatente deactivates recurring mode, so activate it again after every initialization.

The token itself comes back in the <token> element of the payment’s XML response.

fnDllOperRecurrente

Charges a token obtained earlier. Recurring mode does not have to be active to call it.

Function signature:

int fnDllOperRecurrente(LPCTSTR cTokenRec, LPCTSTR cImporte, LPCTSTR cFactura, LPTSTR cXMLResp, int iTamMaxResp);

The response is analogous to that of a card payment.

Receipt Generation

fnDllGenerateReceipt

Builds a receipt from a completed operation and returns it encoded in base64.

Function signature:

int fnDllGenerateReceipt(string cXMLResp, StringBuilder base64Receipt, int iTamMaxbase64Receipt, string nombreComercio, bool bIsClient);

Authorization Validation

All financial operations are considered AUTHORIZED only if the XML response contains:

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

Any other combination must be treated as DENIED, regardless of numeric codes or library return values.