🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónPagos 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.
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.
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
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.