SecurePay - Documentación Oficial

Configuraciones Generales

• Autenticación 3D Secure: Activa o desactiva la simulación del paso de verificación 3D Secure. Si está activado, se mostrará la página procesador.html para ingresar un código de 6 dígitos.
• Tiempo de Procesamiento: Permite seleccionar la velocidad simulada de procesamiento de una transacción (Rápido, Normal, Lento). Esto afecta el tiempo que tarda la aplicación en mostrar el resultado del pago.
• Frecuencia de Errores: Configura la probabilidad con la que el sistema simulará errores durante el procesamiento de pagos (Baja, Media, Alta).
• Autollenado de Datos: Un botón que rellena automáticamente el formulario de pago en index.html con datos de prueba válidos, agilizando las pruebas repetitivas.
• Modo Desarrollador: Si se activa, muestra información más detallada en la consola del navegador sobre el proceso de pago, útil para depuración y entender el flujo interno.
• Configuración de Monto Aleatorio: Permite definir cómo se generan los montos para las transacciones de prueba:
  • Rango completo: Montos aleatorios entre 1 y 999.99.
  • Rango limitado: Permite especificar un monto mínimo y máximo para la generación aleatoria.
  • Monto fijo: Permite especificar un monto fijo que se usará para todas las transacciones.

Configuraciones Avanzadas (Principalmente para 3D Secure)

• Tiempo de Expiración 3D Secure: Define cuánto tiempo (en segundos o minutos) tiene el usuario simulado para ingresar el código de verificación en la página procesador.html antes de que la transacción falle por tiempo expirado.
• Intentos 3D Secure: Establece el número máximo de intentos que el usuario simulado tiene para ingresar correctamente el código de verificación 3D Secure. Se proporcionan códigos de ejemplo válidos (ej. 123456).
• Reintentos Automáticos: Activa o desactiva la capacidad del sistema para reintentar automáticamente una transacción que ha fallado.
• Número de Reintentos: Si los reintentos automáticos están activados, este ajuste define cuántas veces se intentará procesar nuevamente una transacción fallida.

1. Simulación de Pago Exitoso

1. El usuario navega a index.html (o inicia un pago desde store.html).
2. Ingresa detalles de una tarjeta de prueba válida y un monto.
3. Hace clic en "Pagar Ahora".
4. Si la autenticación 3D Secure está habilitada en config.html:
   • Es redirigido a procesador.html.
   • Ingresa un código 3D Secure válido (ej. "123456").
   • Hace clic en "Verificar".
5. El sistema (payment.js y bank-system.js) procesa la transacción.
6. Se muestra un mensaje de "Pago Aprobado" en la interfaz (bank-ui.js).
7. La transacción se registra en las estadísticas (statistics.js).

2. Simulación de Pago Rechazado (Fondos Insuficientes)

1. El usuario utiliza una tarjeta marcada para simular fondos insuficientes o el sistema lo determina aleatoriamente según la configuración.
2. Sigue los pasos 1-4 del flujo de pago exitoso.
3. El bank-system.js determina que la transacción debe ser rechazada por fondos insuficientes.
4. Se muestra un mensaje de "Pago Rechazado: Fondos Insuficientes" (bank-ui.js).
5. La transacción se registra como rechazada en las estadísticas.

3. Simulación de Pago Rechazado (Error de 3D Secure)

1. La autenticación 3D Secure está habilitada.
2. El usuario ingresa un código 3D Secure incorrecto en procesador.html repetidamente (superando los intentos configurados) o el tiempo de espera expira.
3. El sistema (bank-system.js) rechaza la transacción debido a fallo en la autenticación 3D Secure.
4. Se muestra un mensaje de "Pago Rechazado: Fallo de Autenticación 3D Secure" (bank-ui.js).
5. La transacción se registra como rechazada.

4. Gestión de Tarjetas de Prueba

1. El usuario navega a cards.html.
2. Puede ver la lista de tarjetas de prueba existentes.
3. Puede agregar una nueva tarjeta, especificando número, fecha de caducidad, CVV, y opcionalmente un comportamiento específico (ej. simular fondos insuficientes).
4. Las tarjetas se guardan usando data-service.js (LocalStorage) para uso futuro.

5. Realización de Pruebas Masivas

1. El usuario navega a la sección correspondiente (si existe una interfaz específica, o mediante una función en bulk-tests.js).
2. Carga un archivo (ej. CSV) con múltiples datos de transacciones o genera datos de prueba.
3. El script bulk-tests.js procesa cada transacción simulada.
4. Los resultados de cada prueba se registran y se pueden mostrar en un resumen o exportar.
5. Las estadísticas generales se actualizan.

Validaciones del Formulario de Pago (index.html)

• Número de Tarjeta:
  • No puede estar vacío.
  • Debe tener un formato que parezca válido (generalmente se verifica la longitud y que sean solo dígitos, a veces con espacios).
  • Se aplica el algoritmo de Luhn para verificar la validez del número de tarjeta.
• Nombre del Titular:
  • No puede estar vacío.
  • Generalmente se espera un formato de nombre (solo letras y espacios).
• Fecha de Caducidad:
  • No puede estar vacía.
  • Debe tener el formato MM/AA o MM/YYYY.
  • El mes debe estar entre 01 y 12.
  • El año no debe ser pasado (la tarjeta no debe estar expirada).
• CVV/CVC:
  • No puede estar vacío.
  • Debe tener 3 o 4 dígitos.
• Monto:
  • No puede estar vacío.
  • Debe ser un número positivo.
  • Puede tener un límite máximo o mínimo según la configuración.

Validaciones en la Gestión de Tarjetas (cards.html)

Similares a las del formulario de pago, asegurando que las tarjetas de prueba guardadas tengan datos coherentes.

Validaciones del Código 3D Secure (procesador.html)

• Formato del Código: Debe ser numérico y tener la longitud esperada (generalmente 6 dígitos).
• Validez del Código: Se compara con códigos predefinidos como válidos (ej. "123456", "111111") para la simulación.
• Número de Intentos: Se controla que el usuario no exceda el número de intentos configurado.
• Tiempo de Espera: Se verifica que el código se ingrese antes de que expire el tiempo límite configurado.

Activación y Funcionamiento

• La simulación de 3D Secure se puede activar o desactivar globalmente desde la página config.html.
• Cuando está activa y se inicia un pago, el usuario es redirigido a procesador.html después de ingresar los datos de la tarjeta.
• En procesador.html, se solicita al usuario que ingrese un código de autenticación de 6 dígitos que simula ser enviado a su teléfono.
• El script bank-ui.js maneja la visualización y la interacción en esta página, mientras que bank-system.js valida el código ingresado.

Parámetros Configurables (desde config.html)

• Tiempo de Expiración: Cuánto tiempo tiene el usuario para ingresar el código antes de que la solicitud caduque.
• Número de Intentos: Cuántas veces puede el usuario intentar ingresar el código incorrectamente antes de que la transacción sea rechazada.
• Códigos Válidos: Para la simulación, se utilizan códigos predefinidos como "123456", "111111", etc., que el sistema reconocerá como válidos. Cualquier otro código se considerará incorrecto.

Flujo de la Simulación

1. Usuario inicia pago con 3D Secure activado.
2. Redirección a procesador.html.
3. Usuario ingresa código:
   • Correcto y a tiempo: Transacción continúa al siguiente paso de autorización por el banco simulado.
   • Incorrecto (dentro de los intentos permitidos): Se solicita reintentar.
   • Incorrecto (supera intentos) o tiempo expirado: Transacción es rechazada con motivo de fallo en 3D Secure.

Implementación (js/payment/websocket.js)

• El archivo websocket.js es el encargado de establecer y gestionar la conexión WebSocket.
• Intenta conectarse a un servidor WebSocket en una dirección específica (ej. ws://localhost:8080). Es importante notar que para que esta funcionalidad opere correctamente, debe existir un servidor WebSocket escuchando en dicha dirección y puerto, capaz de entender los mensajes enviados por SecurePay y responder de manera adecuada. La aplicación SecurePay por sí misma (como conjunto de archivos HTML/JS estáticos) no incluye este servidor WebSocket; este debe ser un componente separado si se desea una comunicación real.
• Manejo de Conexión: Gestiona los eventos de apertura (onopen), cierre (onclose), y error (onerror) de la conexión.
• Envío de Mensajes (sendMessage): Proporciona una función para enviar datos (generalmente objetos JSON serializados) al servidor WebSocket. Esto se usaría, por ejemplo, para enviar los detalles de una transacción para su procesamiento.
• Recepción de Mensajes (onmessage): Define cómo se manejan los mensajes recibidos del servidor. Estos mensajes podrían ser actualizaciones del estado de la transacción (ej. "procesando", "aprobado", "rechazado"), solicitudes de información adicional, o notificaciones. El script parsea el mensaje (asumiendo que es JSON) y puede disparar eventos o llamar a otras funciones (ej. en bank-ui.js) para actualizar la interfaz de usuario.

Simulación de Comunicación en Tiempo Real

• Aunque websocket.js está preparado para comunicación real, si no hay un servidor WebSocket activo, la aplicación puede recurrir a una simulación local de estos eventos para mantener la funcionalidad (esto dependerá de cómo esté integrado websocket.js con el resto de los módulos como payment.js).
• En un escenario ideal con un servidor WebSocket funcional, el cliente enviaría los datos de la transacción, y el servidor respondería con mensajes que actualizan el estado en tiempo real en la página del usuario, por ejemplo, mostrando "Verificando con el banco...", luego "Autenticación 3D Secure requerida...", y finalmente "Pago Aprobado".

Recopilación de Datos

• Cada vez que se procesa una transacción (ya sea aprobada o rechazada), statistics.js es invocado para registrar el evento.
• Se almacenan detalles clave de la transacción, como:
  • ID de transacción (si se genera).
  • Fecha y hora.
  • Monto.
  • Resultado (Aprobada, Rechazada).
  • Motivo del rechazo (ej. fondos insuficientes, error 3D Secure, tarjeta inválida).
  • Tipo de tarjeta (Visa, Mastercard, etc., si se detecta).
• Los datos de las estadísticas se persisten en el LocalStorage del navegador, lo que permite que se acumulen a lo largo de múltiples sesiones de uso.

Visualización de Estadísticas

Las estadísticas se presentan al usuario de varias maneras:

• Contadores Simples: Número total de transacciones, total aprobadas, total rechazadas.
• Porcentajes: Tasa de aprobación y tasa de rechazo.
• Gráficos (usando Chart.js):
  • Gráfico de Pastel (Pie Chart): Muestra la proporción de transacciones aprobadas vs. rechazadas.
  • Gráfico de Barras (Bar Chart): Podría usarse para mostrar el número de transacciones por tipo de tarjeta, o el número de rechazos por motivo.
  • Gráfico de Líneas (Line Chart): Podría usarse para mostrar tendencias de transacciones a lo largo del tiempo (si se implementa el seguimiento temporal).
• Tablas de Transacciones Recientes: Un listado de las últimas transacciones con sus detalles.

La página banco.html suele ser el lugar centralizado para ver estas visualizaciones detalladas, aunque resúmenes pueden aparecer en otras páginas.

Funcionalidades Adicionales

• Reseteo de Estadísticas: Opción para borrar todas las estadísticas acumuladas y empezar de cero.
• Exportación de Datos (Potencial): Aunque no siempre implementado, una funcionalidad avanzada podría permitir exportar los datos de las transacciones o las estadísticas a formatos como CSV o JSON.

Módulo Payment

payment.processPayment(amount, cardDetails): Procesa un pago con el monto y detalles de la tarjeta proporcionados.
payment.onPaymentSuccess(callback): Registra un callback que se ejecuta cuando el pago es exitoso.
payment.onPaymentError(callback): Registra un callback que se ejecuta cuando hay un error en el pago.
                    

Módulo Statistics

statistics.getTotalTransactions(): Retorna el número total de transacciones procesadas.
statistics.getApprovalRate(): Retorna la tasa de aprobación de transacciones.
statistics.getRejectionRate(): Retorna la tasa de rechazo de transacciones.
                    

Problemas Comunes y Soluciones

• Error de Conexión: Asegúrese de que su dispositivo esté conectado a Internet. Verifique su conexión y vuelva a intentarlo.
• Problemas con 3D Secure: Si tiene problemas para completar la verificación 3D Secure, asegúrese de que está ingresando el código correcto y que no ha expirado.
• Transacciones No Registradas: Si una transacción no aparece en las estadísticas, asegúrese de que se haya completado correctamente y de que está buscando en el rango de fechas correcto.

Requisitos del Servidor

• Servidor web con soporte para HTML5 y CSS3.
• Navegador moderno con JavaScript habilitado.

Configuración de Base de Datos

SecurePay no requiere una base de datos en el servidor, ya que utiliza almacenamiento local (LocalStorage) para guardar la información de las transacciones y configuración.

Pasos para la Instalación

1. Descargue los archivos de SecurePay desde el repositorio oficial.
2. Suba los archivos a su servidor web en el directorio deseado.
3. Asegúrese de que los permisos de archivo y carpeta sean los correctos para permitir el acceso público.
4. Acceda a la aplicación a través de su navegador web.

Estructura del Proyecto

El código fuente de SecurePay está organizado en módulos JavaScript independientes, cada uno encargado de una parte específica de la funcionalidad:

• loader.js: Carga y configuración inicial.
• payment.js: Procesamiento de pagos.
• bank-system.js: Simulación del sistema bancario.
• statistics.js: Generación de estadísticas.
• bulk-tests.js: Pruebas masivas.
• data-service.js: Gestión de datos.
• store.js: Lógica de la tienda de demostración.
• cards.js: Gestión de tarjetas de prueba.
• config.js: Configuración de la aplicación.
• main.js: Script principal de la aplicación.
• websocket.js: Comunicación por WebSocket.

Estilo y Diseño

SecurePay utiliza TailwindCSS para el diseño de la interfaz, lo que permite una personalización fácil y rápida de los estilos.

Contribuciones

Las contribuciones son bienvenidas. Por favor, siga las pautas de contribución en el repositorio oficial.

Ejecutar Pruebas

Para ejecutar las pruebas, abra la consola del navegador y ejecute:

npm run test
                    

Optimización de Carga

Los recursos se cargan de manera asíncrona y se minimiza el uso de bibliotecas pesadas. Además, se utiliza almacenamiento en caché para acelerar la carga de datos frecuentes.