Loading
_ DESCIFRANDO CONEXIÓN SEGURA...

Pagos delegados y alcance

5 tareas · 40 min · Principiante

Casi ninguna tienda procesa tarjetas por su cuenta: delega el pago en un proveedor que muestra el formulario, recibe los datos y devuelve a la tienda un identificador. Eso reduce mucho el riesgo, pero no lo elimina, y confundir «lo delegué» con «ya no me toca» es el error más caro. En Hogar Nogal lees cómo se hace el pago, las columnas de la base de pedidos, el registro de avisos del proveedor y la lista de sistemas, y decides qué debe revisarse y qué sobra. Todo es lectura de archivos exportados; no hay tarjetas ni claves reales, solo marcadores evidentes.

0 de 5 · 0%

Objetivo de la sala

Casi ninguna tienda procesa tarjetas por su cuenta: delega el pago en un proveedor que muestra el formulario, recibe los datos y devuelve a la tienda un identificador. Eso reduce mucho el riesgo, pero no lo elimina, y confundir «lo delegué» con «ya no me toca» es el error más caro. En Hogar Nogal lees cómo se hace el pago, las columnas de la base de pedidos, el registro de avisos del proveedor y la lista de sistemas, y decides qué debe revisarse y qué sobra. Todo es lectura de archivos exportados; no hay tarjetas ni claves reales, solo marcadores evidentes.

Cuando el formulario de pago lo aloja el proveedor, los números de tarjeta viajan del navegador al proveedor sin pasar por la tienda. Con eso, los sistemas de la tienda que «ven, guardan o transmiten» datos de tarjeta desaparecen casi todos, y el trabajo de cumplir con el estándar de la industria de tarjetas (PCI DSS) se reduce. Lo que no desaparece es la responsabilidad sobre la página que carga el formulario: si un script ajeno la modifica, puede leer lo que la persona escribe.

Abre flujo-de-pago.txt y entiende los cuatro pasos antes de leer nada más.

Responde para continuar

Si el formulario de pago lo aloja el proveedor, ¿qué sucede con la responsabilidad de la tienda?

Ver pista de ayuda

La página de la tienda sigue cargando el formulario del proveedor.

El flujo dice que la tienda recibe solo un token y los últimos cuatro dígitos. Con eso basta para mostrar «tarjeta terminada en…» y para gestionar un reembolso. Si la base de pedidos guarda algo más, es porque alguien lo añadió, y cada dato extra es riesgo sin función. El estándar de la industria de tarjetas es explícito en algo: el código de seguridad impreso en la tarjeta no puede conservarse después de la autorización.

Abre columnas-base-pedidos.csv y compara cada columna con lo que el flujo dice que llega.

Responde para continuar

¿Qué columna de la tabla de pedidos no debería existir según el flujo de pago?

Ver pista de ayuda

Busca el dato que el flujo no menciona y que nunca se guarda tras autorizar.

El proveedor avisa a la tienda de cada pago con una notificación firmada, y la tienda debe marcar el pedido como pagado solo si la firma es válida. Si no, cualquiera que conozca la dirección del aviso podría mandar uno falso y llevarse mercancía sin pagar. La regla 4 del flujo lo dice, y el registro permite comprobarla.

Abre notificaciones-pago.log y revisa la columna de la firma contra la del estado resultante.

Responde para continuar

¿Qué pedido quedó marcado como pagado a pesar de una firma inválida?

Ver pista de ayuda

Busca la fila donde firma e estado_resultante no son coherentes con la regla.

El alcance no es una lista de sistemas «que tienen tarjetas» sino de los que pueden ver el número o influir en quien lo ve. En la tabla hay uno que no ve nunca el número, pero carga la página donde se escribe, y por eso sigue en alcance: un cambio en ese sistema puede insertar un script que lo capture. Es la clase de dependencia que se olvida al decir «el proveedor se encarga».

Abre sistemas-en-alcance.csv.

Responde para continuar

¿Qué sistema carga la página de pago sin ver nunca el número de tarjeta?

Ver pista de ayuda

Compara las dos columnas de sí/no; solo una fila tiene no en la primera y sí en la segunda.

Hay un pedido marcado como pagado sin que su aviso lo respalde. No se sabe si el cliente pagó, si el aviso fue un error o si fue falso. La decisión prudente no depende de adivinar: se retiene el envío mientras no se sepa y se confirma con la fuente que sí lo sabe, el proveedor.

Responde para continuar

¿Qué hace el equipo con el pedido cuya firma fue inválida?

Ver pista de ayuda

Hay una fuente que sabe si el pago existe, y no es el aviso dudoso.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Whoami-Labs Pro

Whoami-Labs Pro utiliza cookies

Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad