Integra TEF.

Tu operación presencial
potenciada con IOPAY

Una integración dividida en dos capas bien definidas

La captura en presencia de TEF ocurre localmente entre Tu Aplicaciónel componente Zoop y el PINPad El pago, sin embargo, sigue integrado en IOPAY Esto preserva una sola capa para la gestión de transacciones, activación de la terminal, eventos y webhooks

Quién hace qué en la integración

La separación a continuación evita que el uso del componente Zoop para captura local sea confundido con un cambio de la integración principal de la operación

SDK Embedded o Desktop Server

Hay dos formas documentadas de implementar la capa local Los dos conservan la misma arquitectura IOPAY para cuenta, activación y eventos

Desde el proyecto vacío al primer pago en cinco pasos

implementation(
    "br.zoop.pos.plugin:zoop-pos-plugin-desktop-jvm:X.Y.Z"
)

Zoop.initialize(context)

val desktopPlugin = DesktopPlugin(
    Zoop.constructorParameters()
)

Zoop.plug(desktopPlugin)

val activationRequest =
    ZoopFoundationPlugin
        .createDashboardActivationRequestBuilder()
        .tokenCallback(/* receber e exibir o token */)
        .confirmCallback(/* persistir dados confirmados */)
        .build()

Zoop.post(activationRequest)

{
  "marketplace": "<retornado-na-ativacao>",
  "seller": "<retornado-na-ativacao>",
  "accessKey": "<retornado-na-ativacao>"
}

Zoop Desktop SDK integrado directamente en el PDV

En este enfoque, el componente de captura se encuentra dentro de su aplicación El plugin habla localmente con el PINPad, mientras que la operación sigue vinculada a la infraestructura IOPAY

Iniciación después de la activación

Después de que marketplace, seller y accessKey si se han recuperado y persistido, utilice estos valores en tiempo de ejecución para reiniciar el SDK No deben ser digitados manualmente por el operador

Zoop.initialize(context) {
    credentials {
        marketplace = storedMarketplace
        seller = storedSeller
        accessKey = storedAccessKey
    }
}

val desktopPlugin = DesktopPlugin(
    Zoop.constructorParameters()
)

Zoop.plug(desktopPlugin)

Estado de integración

El token nace en el SDK y el enlace se completa en IOPAY

La activación asocia el dispositivo a la cuenta correcta Este paso debe ocurrir antes de la primera transacción y debe probarse también después de reiniciar su aplicación

Consulte la clave de transacción antes de cobrar

La clave de transacción Zoop debe existir en el PINPad para que se ejecuten pagos con tarjeta Si está ausente, activa IOPAY para coordinar la corrección con el proveedor del equipo

Ejemplo de cobro por tarjeta

val paymentRequest = DesktopPlugin
    .createPaymentRequestBuilder()
    .amount(1000)              // R$ 10,00 — valor em centavos
    .option(Option.CREDIT)
    .installments(2)
    .referenceId("pedido-84217")
    .callback(/* tratar sucesso e falha */)
    .build()

Zoop.post(paymentRequest)

Trabaja también los mensajes intermedios del flujo para mostrar al operador instrucciones como acercar, insertar o leer la tarjeta El retorno local permite al PDV seguir lo que está sucediendo en la terminal

Lo que persiste del resultado

Alternativa a través de WebSocket local

Zoop Desktop Server se ejecuta como un servicio local y expone un WebSocket para su aplicación Su alcance sigue siendo la captura TEF Acreditación, cuenta, webhooks y flujo de transacciones permanecen en las plataformas IOPAY

java -version

ws://localhost:1337

const socket = new WebSocket('ws://localhost:1337');

socket.onopen = () => {
    console.log('Desktop Server conectado');
};

socket.onmessage = (event) => {
    const message = JSON.parse(event.data);
    handleZoopMessage(message);
};

socket.onerror = (error) => {
    handleSocketError(error);
};

socket.onclose = () => {
    handleSocketClosed();
};

{
  "type": "activation"
}

{
  "type": "initialize",
  "marketplace": "<valor recebido na ativacao>",
  "seller": "<valor recebido na ativacao>",
  "accessKey": "<valor recebido na ativacao>"
}

Tu Aplicación sigue recibiendo eventos de IOPAY.

Agregar TEF no cambia el contrato de integración asíncrona: Su aplicación sigue recibiendo por IOPAY los webhooks de cada evento y transacción según la integración contratada La devolución local del SDK/Server complementa la experiencia del PDV; no elimina la capa de eventos IOPAY

Modelo de correlación recomendado

Exercita fallas antes de homologar

No válida sólo el escenario de aprobación El piloto debe contemplar fallas de comunicación, token expirado, interrupción durante la captura, reinicio de la aplicación y cancelaciones

Datos de activación deben permanecer fuera de la interfaz y de los registros

marketplace, vendedor y accessKey son parte del arranque técnico del dispositivo Su aplicación debe protegerlos y usarlos automáticamente después de su activación

Checklist antes de liberar al piloto

Documentación oficial para la implementación

Use las guías siguientes como referencia técnica de la versión del componente instalado en el proyecto Parámetros, compatibilidad, versiones y protocolos pueden evolucionar; siempre valida la documentación oficial durante la implementación