Prueba tu integración

Prueba tu integración

Probar la integración de tu ECR te permite confirmar que tu Punto de Venta (POS) se comunica correctamente con el terminal de pago Market Pay antes de pasar a producción. Una campaña de pruebas estructurada detecta defectos de integración mientras aún es barato solucionarlos — en preproducción, sin impacto financiero.

Este artículo describe qué probar, cómo activar cada escenario, e introduce el Conjunto de Pruebas de Integración POS — un libro de pruebas autónomo que puedes usar para ejecutar y hacer seguimiento de tu campaña.

Antes de comenzar

Confirma que lo siguiente está en su lugar:

  • Un terminal de preproducción conectado al host adquirente de prueba (Dummy) de Market Pay. No se mueve dinero real — se simulan rechazos y aprobaciones.
  • Tu método de integración está decidido: API Local (HTTP o Socket/TCP-IP), API en la Nube, o App2App (Intent de Android). Las pruebas aplicables dependen de esto (ver Qué pruebas aplican a mi integración).
  • El tiempo de espera (timeout) de tu cliente HTTP supera los 90 segundos para llamadas de pago. Varios escenarios de resiliencia retrasan deliberadamente la respuesta del host; un timeout más corto fallará esas pruebas incorrectamente.

Pasos clave para la prueba

  1. Valida el flujo feliz. Una venta estándar sin contacto y una venta estándar con chip + PIN que ambas se completen con resultado aprobado y recibo correcto.
  2. Examina los casos límite. Rechazos, abortos, cancelaciones, autorización parcial, firma requerida y transacciones especiales (reverso, reembolso, pre-autorización, etc.).
  3. Prueba la resiliencia. Pérdida de red a mitad de transacción, reinicio del POS, timeout del host, modo offline y comportamiento de sondeo.
  4. Verifica el manejo de datos. Que tu POS almacene los identificadores retornados por el terminal (POITransactionID) para reversos, reembolsos y consultas de estado, y que ServiceID sea único por transacción.
  5. Registra y documenta resultados. Anota aprobado/fallido para cada prueba para que la campaña sea auditable antes del lanzamiento.

El Conjunto de Pruebas de Integración POS

El Conjunto de Pruebas de Integración POS es un libro de pruebas autónomo que te guía a través de una campaña completa de integración y te permite registrar tus resultados — no se requiere cuenta ni servidor. Todo se almacena localmente en tu navegador.

Reemplaza el enfoque manual de copiar y pegar para pruebas de integración con una sola herramienta que:

  • Filtra las pruebas según tu alcance. Selecciona tu protocolo (API en la Nube, API Local HTTP o TCP/IP, App2App) y alterna funciones opcionales (pre-autorización, DCC, propina, recargo, S&F, etc.). El libro oculta pruebas que no aplican — por ejemplo, la categoría Sesión se elimina automáticamente para API en la Nube.
  • Cubre el libro estándar completo en seis categorías: Sesión, Transacción, Escenarios de Rechazo, Aborto y Cancelación, Resiliencia, Transacciones Especiales.
  • Proporciona a cada prueba un escenario, el monto exacto para activar, los campos de respuesta esperados y una pista para desarrolladores — además de ejemplos de mensajes solicitud/respuesta por protocolo.
  • Registra aprobado / fallido / no ejecutado por prueba y te permite exportar un snapshot JSON para compartir con tu contacto de Market Pay o archivar para certificación.
  • Es personalizable. Añade, edita o elimina pruebas y categorías enteras cuando tu integración requiera algo más allá del libro estándar.

Cómo usarlo: abre el conjunto de pruebas, completa el breve recorrido guiado, configura tu Alcance, luego avanza por cada categoría, marcando resultados a medida que avanzas. Usa Exportar al final para producir tu reporte de campaña.

Nota

Pide a tu contacto de integración de Market Pay el enlace actual al Conjunto de Pruebas de Integración POS para tu campaña.

Qué pruebas aplican a mi integración

Categoría API Local (HTTP / Socket) API en la Nube App2App
Sesión (Inicio / Cierre, chequeo serial, diagnóstico) Sí No aplicable — autenticación manejada en capa API Sí
Transacción Sí Sí Sí
Escenarios de Rechazo Sí Sí Sí
Aborto y Cancelación Sí Sí Sí
Resiliencia Sí Sí — el mecanismo de sondeo / autenticación puede diferir Sí — además resolución de Intent
Transacciones Especiales Sí — depende de la función Sí — depende de la función Sí — depende de la función

El conjunto de pruebas aplica este filtrado por ti una vez configures tu alcance.

Qué tarjetas usar para las pruebas

Emulador de tarjeta (recomendado)

La herramienta principal para la campaña es el emulador de tarjetas Market Pay junto con el Servidor Dummy. Los escenarios se activan por el monto de la transacción: el Servidor Dummy devuelve un Código de Respuesta Bancaria (BRC) específico basado en el monto que envías. Esto te da control determinista y repetible sobre rechazos, errores, aprobaciones parciales y flujos especiales — sin necesidad de docenas de tarjetas físicas.

Por ejemplo (cualquier monto no en la lista de activadores devuelve un Aprobado por defecto):

Monto Resultado activado
11.00 No Autorizar — rechazo genérico (BRC 100)
11.01 Tarjeta expirada (BRC 101)
11.16 Fondos insuficientes (BRC 116)
11.17 PIN incorrecto (BRC 117)
16.00 – 17.99 Autorización parcial (autorizado = solicitado − €1.00)
18.00 – 18.99 Firma requerida en recibo
19.07 Emisor inoperativo — retraso de respuesta de 30 segundos (BRC 907)

El mapeo completo monto-a-BRC (incluyendo rangos específicos para tarjetas) se proporciona dentro del conjunto de pruebas, por prueba.

Usando tus propias tarjetas personales

También puedes usar tus propias tarjetas personales en preproducción. Debido a que el entorno de preproducción está conectado al host adquirente Dummy, no hay impacto financiero — no se realiza ninguna autorización, captura o liquidación real contra tu tarjeta.

Esto es un complemento útil al emulador cuando quieres validar el comportamiento con tarjetas reales: pagos sin contacto, lecturas reales de chip, ingreso real de PIN y la experiencia del titular en la pantalla del terminal.

Advertencia

Solo transacciones con contacto (chip): dependiendo de la tarjeta, una transacción con contacto/chip puede ser rechazada. Esto es esperado y es una propiedad de la tarjeta, no un defecto en tu integración. Los pagos sin contacto generalmente no se ven afectados. Si necesitas una aprobación garantizada o una razón específica de rechazo, usa el emulador de tarjetas con el monto activador correspondiente en su lugar.

Leer el resultado correctamente

Al verificar el resultado de una transacción, confirma la respuesta a nivel de campo, no solo el estado HTTP:

  • La aprobación/rechazo está en el mensaje, no solo en el código HTTP. Un HTTP 200 puede aún contener un pago rechazado. Revisa el campo de resultado dentro del mensaje de respuesta.
  • La API Local HTTP usa un patrón POST → sondeo. POST devuelve 202 Accepted; luego haces sondeo con GET. Un 206 significa en progreso — sigue sondeando; un 200 es el resultado final. Nunca cierres una transacción con 206.
  • Almacena el POITransactionID que devuelve el terminal. Reversiones, reembolsos y consultas de estado lo referencian — no tu propia referencia de venta.
  • Mantén ServiceID único por transacción dentro de una sesión. Reutilizarlo rompe la protección contra pagos duplicados.
  • Marca las aprobaciones offline por separado. Cuando el resultado indica una aprobación offline, tu POS debe registrarla de forma distinta a las aprobaciones online.

Criterios de salida — ¿cuándo has terminado?

  • Todas las pruebas OBLIGATORIAS pasan. Estas son bloqueantes para el lanzamiento.
  • Las pruebas RECOMENDADAS pasan, o cualquier fallo está documentado y aceptado.
  • Las pruebas CONDICIONALES pasan para cada función opcional en tu alcance (pre-autorización, DCC, propina, recargo, S&F, etc.).
  • Tu campaña completada (Exportada desde el conjunto de pruebas) se comparte con tu contacto de Market Pay.

¿Necesitas ayuda con tu campaña? Contacta a tu contacto de integración de Market Pay o abre una solicitud a través de Market Pay Assist.

 

 

Probar la integración de tu ECR te permitirá verificar que tu integración funciona como se espera antes de pasar a un entorno de producción.

Los pasos clave de prueba incluyen:

  1. Validar el flujo feliz.
  2. Examinar flujos no felices, que abarcan escenarios como tiempos de espera y problemas de conexión, mientras se confirma el estado de la transacción.
  3. Replicar diversas respuestas del adquirente para evaluar tu manejo de transacciones rechazadas.
  4. Realizar pruebas con varios Métodos de Verificación del Titular de la Tarjeta (CVM).

Puedes obtener tarjetas emuladas para el entorno de pruebas desde:

Nota. Para tarjetas físicas, debes consultar con tu adquirente o con tu contacto de Market Pay.

Para probar flujos no felices, al usar el entorno de prueba de Market Pay, existe una regla para devolver un código de respuesta específico según el monto recibido cuando coincide con el siguiente formato: 9XXX, donde

Ejemplo: se espera recibir la respuesta 116 (Fondos insuficientes). Debes hacer una transacción con el monto 9116.

Adjuntos