A quién está dirigida esta guíaAl comercio y a su equipo de desarrollo que llevarán a cabo la certificación de su integración con NetPay. Esta página explica qué es la certificación y en qué momento del proyecto ocurre; el detalle está en uno de los dos documentos que se enlazan en el apartado 3, según tenga o no su matriz de pruebas.
1. La certificación y su propósito
La certificación valida que la comunicación entre su sistema y la terminal NetPay quedó integrada conforme a la documentación que se le compartió. No es un trámite: es la última oportunidad de detectar en ambiente de pruebas un comportamiento que en producción se convertiría en una transacción perdida, un cobro duplicado o un reverso mal interpretado.
Recomendación previa a la sesiónLe sugerimos revisar internamente todo lo que se evalúa antes de cualquier sesión con NetPay, y resolver por correo con el equipo de integraciones cualquier duda con anticipación. El apartado 3 le indica cuál de los dos documentos le corresponde.
Ubicación de la certificación dentro del proyecto
La certificación no es el primer paso ni el último. Se sitúa entre el desarrollo y la salida a producción, y condiciona a ambos: no se agenda hasta tener la integración terminada, y las terminales productivas no se solicitan antes de haberla concluido.
flowchart TD
subgraph D["1 · Desarrollo"]
direction TB
D1["Solicita la terminal<br/>de pruebas"] --> D2["Integra siguiendo<br/>la documentación"]
end
subgraph C["2 · Certificación sandbox"]
direction TB
C1["Agenda la sesión"] --> C2["Completa la matriz<br/>y ejecuta las pruebas"]
end
subgraph P["3 · Pre-producción"]
direction TB
P1["Solicita las terminales<br/>productivas"] --> P2["Prueba piloto<br/>con una terminal"]
end
subgraph E["4 · Producción"]
direction TB
E1["Despliegue del resto<br/>de terminales"]
end
D --> C --> P --> E
La certificación ocupa una fase propia del proyecto. Esta guía cubre la segunda etapa; las tres restantes se coordinan con su asesor comercial y con el equipo de integraciones.
La sesión de certificación se agenda con el equipo de integraciones, que le indicará el medio para hacerlo.
Sobre la solicitud de terminales productivasQuien solicita las terminales productivas es su asesor comercial de NetPay, con base en las indicaciones que el área de integraciones publica en sus comunicados y correos. El área de integraciones define las características que deben tener, pero no es quien tramita ni envía los equipos.
El equipo de integraciones no recomienda solicitarlas antes de concluir la certificación. Las características de las terminales pueden cambiar durante el proceso, y una solicitud anticipada puede generar multas por falta de uso, cuya responsabilidad no corresponde a NetPay. Si el comercio lo prefiere, las terminales pueden entregarse ya configuradas, o bien puede agendarse una sesión para mostrar al equipo cómo realizar esa configuración.
Considérelo en su plan de trabajoLe sugerimos contemplar dentro de las estimaciones de su proyecto un margen adicional para cubrir las etapas descritas. La certificación, las correcciones que puedan derivarse de ella y la prueba piloto requieren tiempo de su equipo además del de desarrollo.
2. El proceso completo, de principio a fin
Este es el recorrido completo, de principio a fin. Conviene tenerlo presente antes de entrar en el detalle: el documento que le corresponde desarrolla cada uno de estos pasos.
flowchart TD
A["1 · NetPay le comparte<br/>el alcance de sus pruebas"] --> B["2 · Entrega los datos<br/>de su proyecto"]
B --> C["3 · Responde las<br/>preguntas técnicas"]
C --> T{"¿aplica el ticket<br/>personalizado?"}
T -->|"sí"| TP["4 · Certifica el<br/>ticket personalizado"]
T -->|"no"| P
TP --> P["5 · Ejecuta<br/>las pruebas"]
P --> E["6 · Entrega los tickets<br/>y los JSON como evidencia"]
E --> R{"7 · NetPay revisa"}
R -->|"con observaciones:<br/>corrige y reenvía"| P
R -->|"sin observaciones"| F["8 · Cierre y<br/>notas finales"]
F --> G["9 · Producción"]
El paso 4 es el único que puede omitirse o anticiparse. El resto de la secuencia es lineal, y el paso 7 retorna al 5 cuantas veces sea necesario.
Sobre el orden de ejecuciónCuando el ticket personalizado resulta aplicable, se certifica antes que el resto de las pruebas. Una modificación posterior del ticket obliga a repetir las evidencias ya entregadas.
3. Elija su documento
Al llegar el momento de certificar, NetPay le comparte una matriz de pruebas: un documento con la lista concreta de preguntas y escenarios que le corresponden, ya filtrada para su integración. Tenerla o no tenerla es lo único que decide cuál de los dos documentos debe abrir. Cada uno es completo por sí solo: no necesita leer el otro.
Su integración está en desarrollo o todavía no ha recibido el documento. Ese es el material completo: qué alcance le corresponde, qué debe preparar, qué se le preguntará, qué escenarios ejecutará y qué evidencia entregará. Léalo como una especificación: varios requisitos —el folio único, los tiempos de espera y el bloqueo de multi-instancias— son mucho menos costosos de resolver durante el desarrollo que una vez terminado.
Ya tiene el documento en la mano y va a completarlo, o ya recibió observaciones. Ese material no repite lo que su matriz ya contiene: explica cómo trabajarla, qué evidencia adjuntar, qué significa cada estatus y reúne los recordatorios y observaciones que evitan repetir una prueba.
4. Posterior a la certificación
- NetPay registra las notas finales de la certificación y la bitácora de las sesiones sostenidas con su equipo.
- Sus respuestas quedan como referencia para la atención de casos productivos: si más adelante se abre un caso, se contrasta con lo que su equipo declaró durante la certificación.
- Si el ticket personalizado se modifica, deberá recertificarse.
Casos que requieren una recertificación
La certificación no se realiza una sola vez. Una vez concluida, conviene tener presente qué cambios obligan a repetir el proceso, total o parcialmente. Los casos más habituales son:
- Cambio de la librería
.aaren integraciones por SDK, o de la.dllen integraciones por COM. - Cambio de versión de Smart PinPad, que es el procesador de pagos de la terminal.
- Cambio del tipo de integración, por ejemplo al migrar de API a SDK, o al incorporar check-in y check-out.
- Cambio de modelo de terminal, ya que la versión de Android que ejecuta puede modificar el comportamiento.
- Cambio de marca de terminal entre Pax, Urovo y Kozen.
- Incorporación de funcionalidades que no se certificaron previamente, como meses sin intereses, propina, cashback, devoluciones o lectura NFC.
- Cualquier otro cambio que afecte el flujo de la transacción.
Si tiene dudas sobre si un cambio en particular requiere recertificarse, le sugerimos consultarlo con el equipo de integraciones antes de desplegarlo a producción.
Referencia de marcaTanto esta guía como la documentación publicada describen el comportamiento de las terminales Pax. En Urovo y en Kozen ciertos flujos pueden variar; las diferencias se señalan donde corresponde.