Prueba tu integración

Probar tu integración ECR te permite confirmar que tu punto de venta (POS) se comunica correctamente con el terminal de pago de Market Pay antes de pasar a producción. Una campaña de pruebas estructurada permite detectar defectos de integración antes de pasar a producción.

Esta es nuestra herramienta de autopruebas en línea: pos-test-suite.market-pay.com

Requisito previo

Debes disponer de un terminal de preproducción conectado al host adquirente de pruebas (Dummy) de Market Pay. No se mueven fondos reales: los rechazos y las aprobaciones son simulados.

Conjunto de pruebas de integración del POS

El conjunto de pruebas de integración del POS es un manual de pruebas independiente que te guía a través de una campaña de integración completa y te permite registrar tus resultados, sin necesidad de una cuenta ni de un servidor. Todo se almacena localmente en tu navegador. Esta herramienta te permite:

  • Filtrar las pruebas según tu ámbito. Selecciona tu protocolo (Cloud API, Local API HTTP o TCP/IP, App2App) y activa o desactiva las funciones opcionales (preautorización, DCC, propina, recargo, S&F, etc.). El manual oculta las pruebas que no corresponden; por ejemplo, la categoría Sesión se elimina automáticamente para Cloud API.
  • Cubrir el manual estándar completo en seis categorías: Sesión, Transacción, Escenarios de rechazo, Interrupción y cancelación, Resiliencia, Transacciones especiales.
  • Proporcionar a cada prueba un escenario, el importe exacto que se debe activar, los campos de respuesta esperados y una sugerencia para el desarrollador, además de ejemplos de mensajes de solicitud/respuesta por protocolo.
  • Registrar si cada prueba se ha superado, ha fallado o no se ha ejecutado, y exportar una instantánea JSON para compartirla con tu contacto de Market Pay o archivarla para la certificación.
  • Personalizar: añadir, editar o eliminar pruebas y categorías completas cuando tu integración necesite algo más allá del manual estándar.

Qué tarjetas usar para las pruebas

Emulador de tarjetas

La herramienta principal para la campaña es el emulador de tarjetas de la marca junto con el servidor Dummy. Los escenarios se activan mediante el importe de la transacción: el servidor Dummy devuelve un código de respuesta bancario (BRC) específico según el importe que envíes. Esto te proporciona un control determinista y repetible sobre los rechazos, errores, aprobaciones parciales y flujos especiales, sin necesidad de utilizar distintas tarjetas físicas.

Tarjetas de prueba oficiales

Algunas marcas proporcionan tarjetas de prueba. Estas tarjetas se pueden utilizar con nuestra configuración Dummy o en un entorno de preproducción de extremo a extremo si disponemos de un MID que configurar con el adquirente esperado.

Advertencia

Solo para transacciones con contacto (chip): según la tarjeta, una transacción con contacto o chip puede rechazarse cuando se utiliza con nuestro servidor Dummy, que emula la respuesta. Algunas tarjetas esperan datos reales del emisor que no podemos devolver a la tarjeta cuando se utiliza en un entorno emulado.

Simulación de respuestas

Nuestro conector Dummy nos permite emular algunos escenarios y respuestas en función del importe introducido para ayudarte con la integración:

Importe Resultado activado
11.00 No aceptar: rechazo genérico (BRC 100)
11.01 Tarjeta caducada (BRC 101)
11.04 Tarjeta restringida (BRC 104)
11.06 Se ha superado el número permitido de intentos de PIN (BRC 106)
11.09 Comerciante no válido (BRC 109)
11.16 Fondos insuficientes (BRC 116)
16.20 Autorización parcial (autorizado = 16.20 − 0,50 €), si está configurada
19.07 Emisor de la tarjeta no operativo (BRC 907): tiempo de espera del host con un retraso de 30 segundos
19.09 Fallo de funcionamiento del sistema (BRC 909): activa el modo sin conexión si está configurado

Cómo interpretar correctamente el resultado

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

  • La aprobación o el rechazo se encuentra en el mensaje, no solo en el código HTTP. Un HTTP 200 aún puede contener un pago rechazado. Comprueba el campo de resultado dentro del mensaje de respuesta.
  • Local API HTTP utiliza un patrón POST → consulta periódica. POST devuelve 202 Accepted; después debes hacer consultas periódicas mediante GET. Un 206 significa que está en curso: sigue consultando; un 200 es el resultado final. Nunca cierres una transacción con 206.
  • Almacena el POITransactionID que devuelve el terminal. Las reversiones, los reembolsos y las consultas de estado hacen referencia a este identificador, no a tu propia referencia de venta.
  • Mantén ServiceID único para cada transacción dentro de una sesión. Reutilizarlo interrumpe la protección contra pagos duplicados.
  • Marca las aprobaciones sin conexión por separado. Cuando el resultado indique una aprobación sin conexión, tu POS debe registrarla de forma diferenciada de las aprobaciones en línea.

Criterios de finalización: ¿cuándo has terminado?

  • Todas las pruebas OBLIGATORIAS se han superado. Son imprescindibles para la puesta en producción.
  • Las pruebas RECOMENDADAS se han superado o cualquier fallo está documentado y aceptado.
  • Las pruebas CONDICIONALES se han superado para cada función opcional incluida en tu ámbito (preautorización, DCC, propina, recargo, S&F, etc.).
  • La campaña completada (exportada desde el conjunto de pruebas) se ha compartido con tu contacto de Market Pay.

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

¿Fue útil este artículo?

Usuarios a los que les pareció útil: 0 de 0