Inicio
Pagos Presenciales
Tokenización
Aliados
Ambientes
Referencia API
Recursos
Pagos en Línea
Referencia de Integración para Pagos en Línea
2
min read
2
2
min read
La solución de Pagos en Línea de OEL permite integrar el procesamiento de transacciones de comercio electrónico mediante los servicios web de OpGateway.
Esta integración está orientada a aplicaciones web, plataformas de comercio electrónico y sistemas que necesitan solicitar autorizaciones de pago y administrar operaciones relacionadas con una transacción.
El servicio expone métodos específicos para ventas, preautorizaciones, postautorizaciones, cancelaciones, devoluciones y reversas.
La interfaz está definida mediante un contrato WSDL, utiliza mensajes SOAP y dispone de operaciones diferenciadas para comercio electrónico y procesamiento presencial.
2. Funcionalidades disponibles
El WSDL de OpGateway define ocho operaciones específicas para comercio electrónico:
Método | Funcionalidad |
|---|---|
| Solicita un identificador de sesión para el envío seguro de transacciones. |
| Solicita la autorización de un cargo mediante comercio electrónico. |
| Solicita una preautorización de pago. |
| Solicita una postautorización de pago. |
| Solicita la precancelación de una operación. |
| Solicita la cancelación de un cargo. |
| Solicita una devolución total o parcial. |
| Solicita la reversa de una operación. |
Cada operación dispone de su propia estructura de solicitud y respuesta, aunque algunas comparten modelos de datos.
3. Modalidades de procesamiento
3.1. Venta directa
Permite solicitar la autorización de un cargo mediante ecommerceVenta.
La solicitud incluye información del comercio, importe, identificadores de la transacción y datos de la tarjeta, además de parámetros complementarios que dependen de la integración.
La respuesta proporciona información para identificar la operación y evaluar el resultado comunicado por el procesador.
3.2. Preautorización y postautorización
El servicio permite trabajar con un esquema de autorización en etapas:
Preautorización: se solicita mediante
ecommercePreAutorizacion.Postautorización: se solicita mediante
ecommercePostAutorizacion, utilizando los datos de referencia correspondientes.
La relación exacta entre ambas operaciones, los plazos permitidos y las reglas de captura deberán confirmarse con las especificaciones operativas del procesador.
3.3. Administración de transacciones
La API incluye métodos para gestionar operaciones posteriores:
Cancelación:
ecommerceCancelacion.Precancelación:
ecommercePreCancelacion.Devolución:
ecommerceDevolucion.Reversa:
ecommerceReversa.
Estas operaciones tienen propósitos distintos. Su disponibilidad puede depender del estado de la transacción original y de las reglas operativas aplicables.
No debe asumirse que son intercambiables.
4. Arquitectura de integración
El procesamiento se realiza mediante solicitudes SOAP enviadas desde el sistema integrador hacia OpGateway.
Recomendación de integración: las credenciales del comercio y las llamadas que involucren información sensible deben gestionarse desde componentes backend protegidos, no desde código JavaScript expuesto en el navegador.
5. Especificaciones técnicas
Característica | Especificación |
|---|---|
Servicio |
|
Interfaz | SOAP |
Versiones definidas | SOAP 1.1 y SOAP 1.2 |
Estilo | Document/literal |
Namespace |
|
Autenticación | Encabezado |
Formato de mensajes | XML |
Contrato de referencia |
|
La dirección del servicio indicada en el WSDL es:
Esta dirección se presenta únicamente como referencia del contrato. La configuración de ambientes, credenciales y endpoints habilitados se documentará posteriormente en el apartado Ambientes.
5.1. Encabezado SOAP
Las operaciones de comercio electrónico declaran el encabezado OpHeader, con los elementos:
Campo | Tipo XSD | Descripción |
|---|---|---|
|
| Primera clave del encabezado. |
|
| Segunda clave del encabezado. |
Ejemplo estructural:
<soap:Header> <OpHeader xmlns="https://servidorseguro.operacionesenlinea.com/"> <OpKey1>CLAVE_1_ASIGNADA</OpKey1> <OpKey2>CLAVE_2_ASIGNADA</OpKey2> </OpHeader>
5.2. Credenciales del comercio
Los modelos de solicitud de las operaciones ecommerce incluyen:
Campo | Tipo XSD | Función |
|---|---|---|
|
| Identificador del comercio. |
|
| Contraseña de acceso asociada al comercio. |
Los elementos comercioId ycontrasena son obligatorios y necesarios para autenticar la operación.
6. Estructuras compartidas
6.1. Venta y preautorización
Los métodos ecommerceVenta y ecommercePreAutorizacion comparten:
Solicitud:
cTCReq.Respuesta:
cTCResp.
El modelo de solicitud contiene 22 campos, entre ellos:
comercioId, contrasena, modo, monto, propina, transaccionId, referencia, tarjeta, tipo, mes, anio, digitos, titular, dirIp, diferimiento, numeroPagos, plan, xid, cavv, eci, status_3d y subcomercio.
La respuesta cTCResp contiene 11 campos, incluidos identificadores de la transacción, importe, códigos de respuesta, mensajes y código de aprobación.
6.2. Cancelaciones y devoluciones
Los métodos ecommercePreCancelacion, ecommerceCancelacion y ecommerceDevolucion utilizan solicitudes con una estructura de 12 campos.
Las respuestas incluyen datos como transaccionId, monto, numeroControl, codigoRespuesta, ccErrorCode y codigoAprobacion.
6.3. Reversa y postautorización
ecommerceReversa y ecommercePostAutorizacion comparten una estructura de solicitud de 11 campos, mediante los tipos cReversaReq y cPostAutorizacionReq, respectivamente.
Cada operación mantiene su propio tipo de respuesta.
7. Relación con 3D Secure
Los modelos de solicitud de ecommerceVenta y ecommercePreAutorizacion incluyen los siguientes campos:
Campo | Tipo XSD |
|---|---|
|
|
|
|
|
|
|
|
Estos campos evidencian que el contrato contempla el envío de información relacionada con autenticación 3D Secure.
Sin embargo, el flujo de autenticación se documentará de manera independiente en la sección 3D Secure.
8. Identificador de sesión
El método ecommerceSessionID permite solicitar un identificador de sesión para el envio seguro de transacciones.
Su solicitud utiliza el modelo cSessionReq, compuesto por comercioId y contrasena.
La respuesta cSessionResp incluye:
codigoRespuesta, comercioId, sessionId, timestamp, ccErrorCode, ccErrorMessage, ccReturnMsg y procReturnMessage.
9. Interpretación de resultados
Las respuestas de las operaciones de pago incluyen campos como:
Campo | Propósito |
|---|---|
| Código de respuesta de la operación. |
| Código adicional de error o resultado. |
| Mensaje devuelto por el procesamiento. |
| Mensaje complementario de respuesta. |
| Código de aprobación, cuando corresponda. |
| Referencia bancaria, cuando corresponda. |
La interpretación de estos campos deberá realizarse utilizando el catálogo oficial de respuestas.
No debe considerarse una operación aprobada únicamente porque la comunicación SOAP fue exitosa o porque un código tenga un valor determinado sin conocer su significado oficial.
En situaciones de timeout o respuesta indeterminada, el comercio deberá aplicar una estrategia de conciliación antes de volver a solicitar un cargo, para reducir el riesgo de duplicidades.
10. Seguridad de la integración
La integración deberá considerar las siguientes medidas:
Transmitir las solicitudes mediante HTTPS.
Proteger las credenciales del comercio y las claves de
OpHeader.Evitar registrar números de tarjeta, códigos de seguridad u otros datos sensibles en logs.
Implementar controles de acceso y trazabilidad sobre las operaciones financieras.
Evitar reintentos automáticos de cargos sin comprobar previamente el resultado de la operación original.
El uso de SOAP sobre HTTPS no sustituye por sí solo los controles de seguridad y cumplimiento necesarios para procesar datos de pago.
11. Organización de la referencia técnica
La documentación individual de Pagos en Línea se desarrollará en este orden:
Orden | Método | Tipo de operación |
|---|---|---|
1 |
| Sesión |
2 |
| Venta |
3 |
| Preautorización |
4 |
| Postautorización |
5 |
| Precancelación |
6 |
| Cancelación |
7 |
| Devolución |
8 |
| Reversa |
Cada método contará con su propia página técnica que incluirá propósito, parámetros de entrada y salida, obligatoriedad según XSD, estructura SOAP, ejemplos de solicitud y respuesta, consideraciones de integración y aspectos pendientes de validación.
La solución de Pagos en Línea de OEL permite integrar el procesamiento de transacciones de comercio electrónico mediante los servicios web de OpGateway.
Esta integración está orientada a aplicaciones web, plataformas de comercio electrónico y sistemas que necesitan solicitar autorizaciones de pago y administrar operaciones relacionadas con una transacción.
El servicio expone métodos específicos para ventas, preautorizaciones, postautorizaciones, cancelaciones, devoluciones y reversas.
La interfaz está definida mediante un contrato WSDL, utiliza mensajes SOAP y dispone de operaciones diferenciadas para comercio electrónico y procesamiento presencial.
2. Funcionalidades disponibles
El WSDL de OpGateway define ocho operaciones específicas para comercio electrónico:
Método | Funcionalidad |
|---|---|
| Solicita un identificador de sesión para el envío seguro de transacciones. |
| Solicita la autorización de un cargo mediante comercio electrónico. |
| Solicita una preautorización de pago. |
| Solicita una postautorización de pago. |
| Solicita la precancelación de una operación. |
| Solicita la cancelación de un cargo. |
| Solicita una devolución total o parcial. |
| Solicita la reversa de una operación. |
Cada operación dispone de su propia estructura de solicitud y respuesta, aunque algunas comparten modelos de datos.
3. Modalidades de procesamiento
3.1. Venta directa
Permite solicitar la autorización de un cargo mediante ecommerceVenta.
La solicitud incluye información del comercio, importe, identificadores de la transacción y datos de la tarjeta, además de parámetros complementarios que dependen de la integración.
La respuesta proporciona información para identificar la operación y evaluar el resultado comunicado por el procesador.
3.2. Preautorización y postautorización
El servicio permite trabajar con un esquema de autorización en etapas:
Preautorización: se solicita mediante
ecommercePreAutorizacion.Postautorización: se solicita mediante
ecommercePostAutorizacion, utilizando los datos de referencia correspondientes.
La relación exacta entre ambas operaciones, los plazos permitidos y las reglas de captura deberán confirmarse con las especificaciones operativas del procesador.
3.3. Administración de transacciones
La API incluye métodos para gestionar operaciones posteriores:
Cancelación:
ecommerceCancelacion.Precancelación:
ecommercePreCancelacion.Devolución:
ecommerceDevolucion.Reversa:
ecommerceReversa.
Estas operaciones tienen propósitos distintos. Su disponibilidad puede depender del estado de la transacción original y de las reglas operativas aplicables.
No debe asumirse que son intercambiables.
4. Arquitectura de integración
El procesamiento se realiza mediante solicitudes SOAP enviadas desde el sistema integrador hacia OpGateway.
Recomendación de integración: las credenciales del comercio y las llamadas que involucren información sensible deben gestionarse desde componentes backend protegidos, no desde código JavaScript expuesto en el navegador.
5. Especificaciones técnicas
Característica | Especificación |
|---|---|
Servicio |
|
Interfaz | SOAP |
Versiones definidas | SOAP 1.1 y SOAP 1.2 |
Estilo | Document/literal |
Namespace |
|
Autenticación | Encabezado |
Formato de mensajes | XML |
Contrato de referencia |
|
La dirección del servicio indicada en el WSDL es:
Esta dirección se presenta únicamente como referencia del contrato. La configuración de ambientes, credenciales y endpoints habilitados se documentará posteriormente en el apartado Ambientes.
5.1. Encabezado SOAP
Las operaciones de comercio electrónico declaran el encabezado OpHeader, con los elementos:
Campo | Tipo XSD | Descripción |
|---|---|---|
|
| Primera clave del encabezado. |
|
| Segunda clave del encabezado. |
Ejemplo estructural:
<soap:Header> <OpHeader xmlns="https://servidorseguro.operacionesenlinea.com/"> <OpKey1>CLAVE_1_ASIGNADA</OpKey1> <OpKey2>CLAVE_2_ASIGNADA</OpKey2> </OpHeader>
5.2. Credenciales del comercio
Los modelos de solicitud de las operaciones ecommerce incluyen:
Campo | Tipo XSD | Función |
|---|---|---|
|
| Identificador del comercio. |
|
| Contraseña de acceso asociada al comercio. |
Los elementos comercioId ycontrasena son obligatorios y necesarios para autenticar la operación.
6. Estructuras compartidas
6.1. Venta y preautorización
Los métodos ecommerceVenta y ecommercePreAutorizacion comparten:
Solicitud:
cTCReq.Respuesta:
cTCResp.
El modelo de solicitud contiene 22 campos, entre ellos:
comercioId, contrasena, modo, monto, propina, transaccionId, referencia, tarjeta, tipo, mes, anio, digitos, titular, dirIp, diferimiento, numeroPagos, plan, xid, cavv, eci, status_3d y subcomercio.
La respuesta cTCResp contiene 11 campos, incluidos identificadores de la transacción, importe, códigos de respuesta, mensajes y código de aprobación.
6.2. Cancelaciones y devoluciones
Los métodos ecommercePreCancelacion, ecommerceCancelacion y ecommerceDevolucion utilizan solicitudes con una estructura de 12 campos.
Las respuestas incluyen datos como transaccionId, monto, numeroControl, codigoRespuesta, ccErrorCode y codigoAprobacion.
6.3. Reversa y postautorización
ecommerceReversa y ecommercePostAutorizacion comparten una estructura de solicitud de 11 campos, mediante los tipos cReversaReq y cPostAutorizacionReq, respectivamente.
Cada operación mantiene su propio tipo de respuesta.
7. Relación con 3D Secure
Los modelos de solicitud de ecommerceVenta y ecommercePreAutorizacion incluyen los siguientes campos:
Campo | Tipo XSD |
|---|---|
|
|
|
|
|
|
|
|
Estos campos evidencian que el contrato contempla el envío de información relacionada con autenticación 3D Secure.
Sin embargo, el flujo de autenticación se documentará de manera independiente en la sección 3D Secure.
8. Identificador de sesión
El método ecommerceSessionID permite solicitar un identificador de sesión para el envio seguro de transacciones.
Su solicitud utiliza el modelo cSessionReq, compuesto por comercioId y contrasena.
La respuesta cSessionResp incluye:
codigoRespuesta, comercioId, sessionId, timestamp, ccErrorCode, ccErrorMessage, ccReturnMsg y procReturnMessage.
9. Interpretación de resultados
Las respuestas de las operaciones de pago incluyen campos como:
Campo | Propósito |
|---|---|
| Código de respuesta de la operación. |
| Código adicional de error o resultado. |
| Mensaje devuelto por el procesamiento. |
| Mensaje complementario de respuesta. |
| Código de aprobación, cuando corresponda. |
| Referencia bancaria, cuando corresponda. |
La interpretación de estos campos deberá realizarse utilizando el catálogo oficial de respuestas.
No debe considerarse una operación aprobada únicamente porque la comunicación SOAP fue exitosa o porque un código tenga un valor determinado sin conocer su significado oficial.
En situaciones de timeout o respuesta indeterminada, el comercio deberá aplicar una estrategia de conciliación antes de volver a solicitar un cargo, para reducir el riesgo de duplicidades.
10. Seguridad de la integración
La integración deberá considerar las siguientes medidas:
Transmitir las solicitudes mediante HTTPS.
Proteger las credenciales del comercio y las claves de
OpHeader.Evitar registrar números de tarjeta, códigos de seguridad u otros datos sensibles en logs.
Implementar controles de acceso y trazabilidad sobre las operaciones financieras.
Evitar reintentos automáticos de cargos sin comprobar previamente el resultado de la operación original.
El uso de SOAP sobre HTTPS no sustituye por sí solo los controles de seguridad y cumplimiento necesarios para procesar datos de pago.
11. Organización de la referencia técnica
La documentación individual de Pagos en Línea se desarrollará en este orden:
Orden | Método | Tipo de operación |
|---|---|---|
1 |
| Sesión |
2 |
| Venta |
3 |
| Preautorización |
4 |
| Postautorización |
5 |
| Precancelación |
6 |
| Cancelación |
7 |
| Devolución |
8 |
| Reversa |
Cada método contará con su propia página técnica que incluirá propósito, parámetros de entrada y salida, obligatoriedad según XSD, estructura SOAP, ejemplos de solicitud y respuesta, consideraciones de integración y aspectos pendientes de validación.
La solución de Pagos en Línea de OEL permite integrar el procesamiento de transacciones de comercio electrónico mediante los servicios web de OpGateway.
Esta integración está orientada a aplicaciones web, plataformas de comercio electrónico y sistemas que necesitan solicitar autorizaciones de pago y administrar operaciones relacionadas con una transacción.
El servicio expone métodos específicos para ventas, preautorizaciones, postautorizaciones, cancelaciones, devoluciones y reversas.
La interfaz está definida mediante un contrato WSDL, utiliza mensajes SOAP y dispone de operaciones diferenciadas para comercio electrónico y procesamiento presencial.
2. Funcionalidades disponibles
El WSDL de OpGateway define ocho operaciones específicas para comercio electrónico:
Método | Funcionalidad |
|---|---|
| Solicita un identificador de sesión para el envío seguro de transacciones. |
| Solicita la autorización de un cargo mediante comercio electrónico. |
| Solicita una preautorización de pago. |
| Solicita una postautorización de pago. |
| Solicita la precancelación de una operación. |
| Solicita la cancelación de un cargo. |
| Solicita una devolución total o parcial. |
| Solicita la reversa de una operación. |
Cada operación dispone de su propia estructura de solicitud y respuesta, aunque algunas comparten modelos de datos.
3. Modalidades de procesamiento
3.1. Venta directa
Permite solicitar la autorización de un cargo mediante ecommerceVenta.
La solicitud incluye información del comercio, importe, identificadores de la transacción y datos de la tarjeta, además de parámetros complementarios que dependen de la integración.
La respuesta proporciona información para identificar la operación y evaluar el resultado comunicado por el procesador.
3.2. Preautorización y postautorización
El servicio permite trabajar con un esquema de autorización en etapas:
Preautorización: se solicita mediante
ecommercePreAutorizacion.Postautorización: se solicita mediante
ecommercePostAutorizacion, utilizando los datos de referencia correspondientes.
La relación exacta entre ambas operaciones, los plazos permitidos y las reglas de captura deberán confirmarse con las especificaciones operativas del procesador.
3.3. Administración de transacciones
La API incluye métodos para gestionar operaciones posteriores:
Cancelación:
ecommerceCancelacion.Precancelación:
ecommercePreCancelacion.Devolución:
ecommerceDevolucion.Reversa:
ecommerceReversa.
Estas operaciones tienen propósitos distintos. Su disponibilidad puede depender del estado de la transacción original y de las reglas operativas aplicables.
No debe asumirse que son intercambiables.
4. Arquitectura de integración
El procesamiento se realiza mediante solicitudes SOAP enviadas desde el sistema integrador hacia OpGateway.
Recomendación de integración: las credenciales del comercio y las llamadas que involucren información sensible deben gestionarse desde componentes backend protegidos, no desde código JavaScript expuesto en el navegador.
5. Especificaciones técnicas
Característica | Especificación |
|---|---|
Servicio |
|
Interfaz | SOAP |
Versiones definidas | SOAP 1.1 y SOAP 1.2 |
Estilo | Document/literal |
Namespace |
|
Autenticación | Encabezado |
Formato de mensajes | XML |
Contrato de referencia |
|
La dirección del servicio indicada en el WSDL es:
Esta dirección se presenta únicamente como referencia del contrato. La configuración de ambientes, credenciales y endpoints habilitados se documentará posteriormente en el apartado Ambientes.
5.1. Encabezado SOAP
Las operaciones de comercio electrónico declaran el encabezado OpHeader, con los elementos:
Campo | Tipo XSD | Descripción |
|---|---|---|
|
| Primera clave del encabezado. |
|
| Segunda clave del encabezado. |
Ejemplo estructural:
<soap:Header> <OpHeader xmlns="https://servidorseguro.operacionesenlinea.com/"> <OpKey1>CLAVE_1_ASIGNADA</OpKey1> <OpKey2>CLAVE_2_ASIGNADA</OpKey2> </OpHeader>
5.2. Credenciales del comercio
Los modelos de solicitud de las operaciones ecommerce incluyen:
Campo | Tipo XSD | Función |
|---|---|---|
|
| Identificador del comercio. |
|
| Contraseña de acceso asociada al comercio. |
Los elementos comercioId ycontrasena son obligatorios y necesarios para autenticar la operación.
6. Estructuras compartidas
6.1. Venta y preautorización
Los métodos ecommerceVenta y ecommercePreAutorizacion comparten:
Solicitud:
cTCReq.Respuesta:
cTCResp.
El modelo de solicitud contiene 22 campos, entre ellos:
comercioId, contrasena, modo, monto, propina, transaccionId, referencia, tarjeta, tipo, mes, anio, digitos, titular, dirIp, diferimiento, numeroPagos, plan, xid, cavv, eci, status_3d y subcomercio.
La respuesta cTCResp contiene 11 campos, incluidos identificadores de la transacción, importe, códigos de respuesta, mensajes y código de aprobación.
6.2. Cancelaciones y devoluciones
Los métodos ecommercePreCancelacion, ecommerceCancelacion y ecommerceDevolucion utilizan solicitudes con una estructura de 12 campos.
Las respuestas incluyen datos como transaccionId, monto, numeroControl, codigoRespuesta, ccErrorCode y codigoAprobacion.
6.3. Reversa y postautorización
ecommerceReversa y ecommercePostAutorizacion comparten una estructura de solicitud de 11 campos, mediante los tipos cReversaReq y cPostAutorizacionReq, respectivamente.
Cada operación mantiene su propio tipo de respuesta.
7. Relación con 3D Secure
Los modelos de solicitud de ecommerceVenta y ecommercePreAutorizacion incluyen los siguientes campos:
Campo | Tipo XSD |
|---|---|
|
|
|
|
|
|
|
|
Estos campos evidencian que el contrato contempla el envío de información relacionada con autenticación 3D Secure.
Sin embargo, el flujo de autenticación se documentará de manera independiente en la sección 3D Secure.
8. Identificador de sesión
El método ecommerceSessionID permite solicitar un identificador de sesión para el envio seguro de transacciones.
Su solicitud utiliza el modelo cSessionReq, compuesto por comercioId y contrasena.
La respuesta cSessionResp incluye:
codigoRespuesta, comercioId, sessionId, timestamp, ccErrorCode, ccErrorMessage, ccReturnMsg y procReturnMessage.
9. Interpretación de resultados
Las respuestas de las operaciones de pago incluyen campos como:
Campo | Propósito |
|---|---|
| Código de respuesta de la operación. |
| Código adicional de error o resultado. |
| Mensaje devuelto por el procesamiento. |
| Mensaje complementario de respuesta. |
| Código de aprobación, cuando corresponda. |
| Referencia bancaria, cuando corresponda. |
La interpretación de estos campos deberá realizarse utilizando el catálogo oficial de respuestas.
No debe considerarse una operación aprobada únicamente porque la comunicación SOAP fue exitosa o porque un código tenga un valor determinado sin conocer su significado oficial.
En situaciones de timeout o respuesta indeterminada, el comercio deberá aplicar una estrategia de conciliación antes de volver a solicitar un cargo, para reducir el riesgo de duplicidades.
10. Seguridad de la integración
La integración deberá considerar las siguientes medidas:
Transmitir las solicitudes mediante HTTPS.
Proteger las credenciales del comercio y las claves de
OpHeader.Evitar registrar números de tarjeta, códigos de seguridad u otros datos sensibles en logs.
Implementar controles de acceso y trazabilidad sobre las operaciones financieras.
Evitar reintentos automáticos de cargos sin comprobar previamente el resultado de la operación original.
El uso de SOAP sobre HTTPS no sustituye por sí solo los controles de seguridad y cumplimiento necesarios para procesar datos de pago.
11. Organización de la referencia técnica
La documentación individual de Pagos en Línea se desarrollará en este orden:
Orden | Método | Tipo de operación |
|---|---|---|
1 |
| Sesión |
2 |
| Venta |
3 |
| Preautorización |
4 |
| Postautorización |
5 |
| Precancelación |
6 |
| Cancelación |
7 |
| Devolución |
8 |
| Reversa |
Cada método contará con su propia página técnica que incluirá propósito, parámetros de entrada y salida, obligatoriedad según XSD, estructura SOAP, ejemplos de solicitud y respuesta, consideraciones de integración y aspectos pendientes de validación.
¿Listo para integrar?
Comienza en ambiente de desarrollo, valida tus primeras operaciones y prepara tu integración para certificación. Cuando el flujo este completo, podrás solicitar el paso a produccion.
¿Listo para integrar?
Comienza en ambiente de desarrollo, valida tus primeras operaciones y prepara tu integración para certificación. Cuando el flujo este completo, podrás solicitar el paso a produccion.
© 2026 Derechos Reservados
© 2026 Derechos Reservados