OpPostAutorizacion

El método OpPostAutorizacion permite solicitar la finalización de una operación previamente autorizada mediante OpPreAutorizacion, utilizando el Gateway de Pagos de OEL.

Este método forma parte del flujo de autorización en dos etapas, en el que primero se solicita una autorización del importe y posteriormente se completa la operación mediante una postautorización.

Para realizar la solicitud, el comercio debe proporcionar los datos de identificación, el importe de la operación y la información de autorización correspondiente.

A diferencia de OpVenta y OpPreAutorizacion, este método no requiere transmitir nuevamente los datos sensibles de la tarjeta ni la información EMV utilizada durante la autorización inicial.

Importante: las reglas de vinculación con la preautorización original, los importes permitidos y los plazos para completar la operación dependen de la configuración y reglas del procesador de pagos. Estos aspectos deben confirmarse con OEL.

Información del servicio

Autenticación

La operación requiere las credenciales asignadas al comercio por OEL.

Estas deben enviarse mediante la cabecera SOAP OpHeader, utilizando los siguientes parámetros:

Adicionalmente, el cuerpo de la solicitud debe incluir el identificador del comercio (comercioId) y su contraseña (contrasena).

Parámetros de solicitud (Request)

El método recibe un objeto request de tipo cPostAutorizacionReq, compuesto por 11 parámetros.

La obligatoriedad indicada como «Sí» para campos distintos de comercioId y monto es una regla funcional heredada que requiere confirmación específica para este método.

Consideraciones sobre los parámetros

transaccionId

Permite identificar la transacción dentro del flujo de procesamiento. Para una postautorización es importante conservar la relación con la autorización inicial.

Debe utilizarse el mismo identificador enviado en OpPreAutorizacion.

codigoAprobacion

Representa el código de autorización bancaria asociado a la operación previamente autorizada.

El WSDL lo define como string, sin establecer una longitud máxima. La documentación de tarjeta presente indica que los códigos de aprobación bancaria suelen contener seis dígitos, aunque no garantiza esa longitud para todos los procesadores.

monto

Corresponde al importe solicitado para completar la operación.

El importe puede ser igual o menor del autorizado originalmente.

Ejemplo XML Request — SOAP 1.1

El siguiente ejemplo muestra la estructura de una solicitud de postautorización utilizando valores ficticios y simbólicos.

No representa una transacción ejecutable sin las credenciales, identificadores y valores de autorización válidos.

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns="https://servidorseguro.operacionesenlinea.com/">

  <soap:Header>
    <OpHeader>
      <OpKey1>CLAVE_1_ASIGNADA</OpKey1>
      <OpKey2>CLAVE_2_ASIGNADA</OpKey2>
    </OpHeader>
  </soap:Header>

  <soap:Body>
    <OpPostAutorizacion>
      <request>
        <comercioId>12345</comercioId>
        <contrasena>CLAVE_COMERCIO</contrasena>
        <modo>P</modo>
        <monto>500.00</monto>
        <transaccionId>ID_TRANSACCION</transaccionId>
        <codigoAprobacion>123456</codigoAprobacion>
        <referencia>RESERVA000001</referencia>
        <dirIp>192.0.2.10</dirIp>
        <deviceId>12345678</deviceId>
        <subcomercio>SUBCOMERCIO_ID</subcomercio>
        <version>VERSION_SDK</version>
      </request>
    </OpPostAutorizacion>

Los valores del ejemplo son ilustrativos. El identificador de transacción y el código de aprobación deben corresponder a las reglas de vinculación establecidas por OEL.

Parámetros de respuesta (Response)

El servicio devuelve un mensaje SOAP que contiene el elemento OpPostAutorizacionResponse y, dentro de él, el objeto OpPostAutorizacionResult, de tipo cPostAutorizacionResp.

La respuesta contiene 15 parámetros.

Identificación y resultado de la operación

Información de afiliación

Ejemplo XML Response — Operación aprobada

El siguiente ejemplo representa una respuesta ficticia con una estructura compatible con el WSDL.

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns="https://servidorseguro.operacionesenlinea.com/">

  <soap:Body>
    <OpPostAutorizacionResponse>
      <OpPostAutorizacionResult>
        <comercioId>12345</comercioId>
        <terminalId>12345678</terminalId>
        <transaccionId>ID_TRANSACCION</transaccionId>
        <fechaTransaccion>10/15/26</fechaTransaccion>
        <horaTransaccion>14:30:00</horaTransaccion>
        <monto>500.00</monto>
        <referencia>RESERVA000001</referencia>
        <numeroControl>CTRL000001</numeroControl>
        <codigoRespuesta>0</codigoRespuesta>
        <procReturnMsg>00</procReturnMsg>
        <ccErrorCode>0</ccErrorCode>
        <ccReturnMsg>APROBADA</ccReturnMsg>
        <codigoAprobacion>123456</codigoAprobacion>
        <afiliacion>AFILIACION_ID</afiliacion>
        <afiliacionEmpresa>EMPRESA_ID</afiliacionEmpresa>
      </OpPostAutorizacionResult>
    </OpPostAutorizacionResponse>

Códigos de respuesta

Se identifican los siguientes valores como respuesta para OpPostAutorizacion:

Adicionalmente, el servicio devuelve información del procesador mediante los campos procReturnMsg, ccErrorCode y ccReturnMsg.

Los catálogos completos de errores y códigos bancarios no están definidos en el WSDL disponible.

Consideraciones técnicas

• Autorización previa: la postautorización debe estar vinculada a una operación previamente autorizada, conforme a las reglas establecidas por OEL.

• Importe: antes de enviar la solicitud, verifica que el importe cumpla con las condiciones de la autorización original.

• Identificadores: conserva los identificadores y códigos devueltos por OpPreAutorizacion para facilitar la vinculación y trazabilidad.

• Seguridad: protege las credenciales de autenticación y utiliza exclusivamente conexiones HTTPS seguras.

• Datos sensibles: este método no requiere reenviar el PAN, Track 2 ni los criptogramas EMV de la tarjeta.

• Control de duplicados: evita ejecutar nuevamente una postautorización cuyo resultado sea desconocido sin consultar previamente su estado.

• Registro de operaciones: conserva los identificadores, fechas, importes y resultados necesarios para conciliación y auditoría, excluyendo credenciales e información sensible.

Relación con otros métodos

La implementación de un flujo completo requiere conocer las reglas de vinculación, vigencia y cancelación establecidas por el procesador de pagos.