Módulo 11 · Pagos

Última actualización: 14 de noviembre de 2026.

Documento funcional para validación con usuarios. Se presentan comportamientos esperados y reglas en lenguaje claro, sin códigos de trazabilidad técnica.

Contexto funcional vigente

• El MVP se desarrolla en plataforma web. Salud 365 presenta la experiencia del usuario y coordina las operaciones; Elite Global Doctors (EGD) es el core clínico. Las capacidades concretas de sus servicios e interfaces aún requieren validación técnica.

• El titular que contrata y paga puede ser distinto del paciente; los pacientes dependientes deben estar vinculados y autorizados. Los usuarios, pacientes y médicos requieren registro y correspondencia de identidad entre Salud 365 y EGD.

• Las modalidades son telemedicina «Lo antes posible» y programada. El consentimiento informado y el motivo de consulta de la etapa Triaje se registran antes del pago; Izipay confirma el pago antes del agendamiento o de continuar con la asignación correspondiente.

• En una cita programada, el horario se elige después de confirmar el pago. En «Lo antes posible» se continúa con asignación/cola y confirmación EGD. El motivo se conserva antes del pago y se transmite asociado a la cita EGD cuando exista su identificador externo.

Descripción funcional y procesos

Objetivo y alcance

Definir el cobro de servicios de telemedicina mediante Izipay en el frontend Salud 365, la verificación del resultado del pago, su relación con el agendamiento posterior en EGD, la gestión de incidencias y la conciliación. No comprende procesamiento directo de datos de tarjeta por Salud 365 ni la prestación del acto médico.

• Confirmado: Izipay es la pasarela de pago para la primera fase del MVP web.

• Confirmado: el consentimiento informado se acepta antes del pago.

• Confirmado: el pago ocurre antes del agendamiento de la cita en EGD.

• Confirmado: el motivo de consulta de la etapa Triaje se registra antes del pago, después del consentimiento informado.

• Confirmado: el TITULAR puede pagar una atención para sí mismo o para un paciente asociado.

Los nombres de estado son ilustrativos y deben aprobarse con las plataformas. Un pago aprobado no equivale a una cita confirmada ni a un acto médico realizado.

1. El TITULAR selecciona el servicio y el paciente que recibirá la atención.

2. Salud 365 determina el importe y muestra el resumen de compra.

3. El TITULAR revisa y acepta el consentimiento informado, registra el motivo en Triaje y después continúa al pago.

4. Salud 365 crea una operación de pago única y redirige o integra el mecanismo seguro de Izipay.

5. Izipay procesa el pago; Salud 365 valida el resultado mediante un canal confiable del proveedor.

6. Si el pago está aprobado, Salud 365 registra la transacción y habilita el proceso de agendamiento posterior con EGD.

7. Salud 365 consulta disponibilidad, solicita agendar o asignar médico y registra el identificador de cita EGD cuando se confirme.

8. Si no existe disponibilidad o falla el agendamiento, se conserva la evidencia del pago y se genera una incidencia sin crear una cita ficticia.

9. El motivo ya registrado antes del pago se conserva asociado a paciente y solicitud; se transmite a EGD vinculado a la cita cuando exista su identificador externo, distinguiendo guardado local de recepción confirmada.

RF-11-001 · Inicio de pago y resumen de compra

Objetivo: Permitir que el TITULAR autenticado revise y confirme los datos de la compra de un servicio de telemedicina, incluyendo paciente beneficiario, modalidad, precio, moneda e importe total, antes de iniciar una operación de pago mediante Izipay.

Actores:

• Principal: TITULAR.

• Sistema: Salud 365.

• Integración: Izipay, únicamente en las etapas posteriores de inicio y procesamiento del pago.

• EGD: No interviene directamente en el resumen de compra, salvo que determinados datos comerciales o de disponibilidad deban consultarse mediante su integración.

Precondiciones:

• El TITULAR inició sesión correctamente.

• El servicio de telemedicina fue seleccionado.

• El paciente se encuentra registrado y asociado al TITULAR.

• Existe un precio vigente para el servicio.

• El consentimiento informado correspondiente fue aceptado y registrado.

• La modalidad seleccionada se encuentra habilitada.

Flujo principal:

1. Salud 365 verifica que exista consentimiento informado válido.

2. Salud 365 consulta el catálogo comercial y obtiene el precio vigente.

3. Salud 365 muestra el resumen de compra con: servicio, paciente, pagador, moneda e importe.

4. TITULAR revisa los datos y selecciona «Continuar al pago».

5. Salud 365 revalida el importe y registra la compra con una referencia única.

6. Salud 365 continúa hacia RF-11-002.

Validaciones y reglas:

El pagador y el paciente pueden ser personas diferentes

No permitir el pago para pacientes que no estén asociados o autorizados

No permitir continuar sin consentimiento informado válido

Los importes deben obtenerse del catálogo comercial autorizado

No permitir que el frontend modifique el importe que se enviará a Izipay

Si el precio cambia antes de confirmar, mostrar el nuevo importe y solicitar confirmación

Guardar una instantánea del precio, moneda y condiciones comerciales de la compra

No crear una cita en EGD durante la preparación de la compra

Alternativas y excepciones:

• Paciente no autorizado: bloquear operación e informar al TITULAR.

• Servicio inactivo: impedir continuar.

• Precio no disponible: mostrar mensaje y no habilitar pago.

• Consentimiento pendiente: dirigir al módulo correspondiente.

• Error en consulta de catálogo: permitir reintentar, sin inventar un importe.

Integraciones y datos: Salud 365 deberá registrar, como mínimo, el identificador de compra, TITULAR pagador, paciente, servicio, modalidad, precio, moneda, fecha de creación, versión del consentimiento y estado inicial de la compra.

Criterios de aceptación:

El resumen muestra correctamente pagador y paciente, incluso cuando son personas distintas.

El precio mostrado coincide con el precio comercial vigente.

No se habilita pago sin consentimiento válido.

Los cambios de precio requieren nueva confirmación.

La compra queda registrada con su referencia y datos comerciales.

No se genera ninguna cita EGD durante este proceso.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-11-002 · Creación segura de operación Izipay

Objetivo: Permitir que Salud 365 inicie de manera segura una operación de pago mediante Izipay, generando identificadores únicos, validando los datos comerciales y evitando la creación accidental de múltiples operaciones de cobro para una misma compra.

Actores: TITULAR, Salud 365 e Izipay. EGD no participa en este proceso.

Precondiciones:

• Existe una compra válida y registrada.

• El importe y la moneda han sido confirmados.

• El consentimiento informado está registrado.

• No existe un pago aprobado previamente para la misma compra.

• Las credenciales y configuraciones de Izipay están habilitadas.

• No existe un intento anterior con resultado incierto que requiera conciliación.

Flujo principal:

1. Salud 365 verifica la compra y que no tenga un pago aprobado

2. Salud 365 comprueba si existe un intento activo o pendiente de verificación

3. Salud 365 crea o reutiliza el intento correspondiente mediante un mecanismo de idempotencia

4. Salud 365 genera el identificador único requerido para Izipay

5. Salud 365 obtiene desde su backend el token de sesión de Izipay

6. Izipay devuelve la información necesaria para iniciar el pago

7. Salud 365 presenta el formulario seguro de Izipay

8. TITULAR ingresa los datos y confirma la operación

9. Salud 365 continúa con RF-11-003 para determinar el resultado.

Reglas de negocio:

Cada compra debe tener un identificador único

Cada intento nuevo debe contar con un identificador único

Dos clics consecutivos no deben crear dos cobros

La creación de intentos debe controlarse también desde el backend, no solo deshabilitando el botón

No almacenar número completo de tarjeta ni CVV en Salud 365

Las credenciales privadas deben mantenerse en el backend

Antes de permitir un nuevo intento, verificar el resultado del anterior

Registrar fallas y eventos con identificadores de correlación

Un error de comunicación no significa que Izipay haya rechazado el pago

Ejemplo practico: El TITULAR selecciona pagar una consulta de S/ 80.

Presiona dos veces el botón Pagar porque la pantalla demora en responder.

Comportamiento esperado: Salud 365 reconoce que existe un intento en proceso y evita generar una segunda operación independiente. Si se desconoce el resultado del primero, lo envía a verificación.

Alternativas y excepciones:

• Error antes de solicitar el token: permitir un reintento controlado.

• Token de sesión vencido: generar uno nuevo únicamente cuando corresponda, manteniendo la trazabilidad.

• Error o timeout durante la operación: marcar el intento como pendiente de verificación.

• Compra ya pagada: impedir un cobro nuevo.

• Sesión del usuario vencida: solicitar autenticación sin perder la referencia de compra.

Integraciones y datos: Referencia de compra, identificador de intento, transacción Izipay, importe, paciente, pagador, auditoría.

Criterios de aceptación:

Un doble clic no genera operaciones de cobro independientes.

Cada intento queda asociado a una única compra.

Las credenciales privadas no se exponen en el frontend.

Se conserva la trazabilidad de intentos fallidos y reintentos.

Una compra aprobada no permite nuevos cobros.

Una operación con resultado incierto no habilita automáticamente un nuevo intento.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-11-003 · Confirmación y verificación del pago

Objetivo: Permitir que Salud 365 determine y registre de forma confiable el resultado de una operación de pago procesada mediante Izipay, validando su autenticidad, integridad e información comercial, y habilitando la continuación del flujo de atención únicamente cuando exista confirmación suficiente del pago.

Actores:

• TITULAR: consulta el resultado.

• Salud 365: procesa y valida la respuesta.

• Izipay: proporciona el resultado de la operación.

• ADMINISTRADOR: interviene excepcionalmente en operaciones pendientes de conciliación.

Precondiciones:

• Existe una compra registrada.

• Se ha iniciado una operación de pago con Izipay.

• Existe un identificador para correlacionar la respuesta.

• Salud 365 cuenta con los mecanismos de validación configurados.

Flujo principal:

1. Izipay procesa la operación y genera un resultado.

2. Salud 365 recibe el resultado mediante el mecanismo habilitado.

3. Salud 365 identifica la compra y el intento correspondiente.

4. Salud 365 verifica la autenticidad e integridad de la respuesta.

5. Salud 365 contrasta referencia, monto, moneda y comercio.

6. Salud 365 determina el estado interno del intento y de la compra.

7. Salud 365 registra los identificadores, respuesta y evidencia de confirmación.

8. Salud 365 informa el resultado al TITULAR.

9. Salud 365 si se confirma el pago, habilita las siguientes etapas funcionales.

10. Salud 365 si no se confirma pago, ejecuta RF-11-004.

Estados internos propuestos:

Estado	Significado	Acción
Pendiente	Operación iniciada sin resultado final	Esperar resultado o continuar verificando
Aprobado	Pago confirmado mediante evidencia válida	Habilitar siguiente etapa
Rechazado	Rechazo final confirmado	Permitir nuevo intento controlado
Por verificar	Resultado desconocido, inconsistente o incompleto	Conciliar antes de permitir otro cobro
Anulado	Operación anulada y confirmada	Actualizar compra
Reembolsado	Devolución confirmada	Actualizar estado financiero y seguimiento

Estos son estados recomendados para Salud 365; necesitan mapearse con los códigos y respuestas reales de la modalidad Izipay elegida.

Validaciones y reglas:

No confiar exclusivamente en el resultado enviado por el navegador

Validar firma y autenticidad de las notificaciones según el contrato Izipay

Verificar referencia, monto, moneda e identificador de comercio

Procesar notificaciones repetidas de forma idempotente

Si el resultado es incierto, no crear un nuevo cobro automáticamente

Registrar evidencia del resultado y trazabilidad de cambios

Un pago aprobado habilita el flujo posterior, pero no confirma la cita EGD

Evitar que notificaciones tardías sobrescriban un estado válido sin conciliación

No modificar manualmente un pago a Aprobado sin evidencia financiera verificable

Si una compra recibe más de un cobro aprobado, registrar incidente y gestionar conciliación o devolución.

Escenarios de pruebas:

Pago correctamente aprobado. Resultado esperado: Registrar Aprobado, guardar evidencia y permitir continuar con el flujo de atención.

Pago rechazado. Resultado esperado: Informar el rechazo y permitir un nuevo intento solamente después de confirmar el estado final.

El usuario cierra el navegador.Resultado esperado:Conservar la operación y recuperar su estado mediante notificación o consulta de conciliación.

Izipay no responde.Resultado esperado:Registrar Por verificar, evitar un segundo cobro y ejecutar conciliación.

Notificación duplicada.Resultado esperado:Reconocer la operación previamente procesada sin duplicar pagos ni ejecutar acciones adicionales.

Monto o firma no coinciden.Resultado esperado:|No aprobar el pago, registrar la inconsistencia y activar revisión.

Integraciones y datos:

Salud 365 debería registrar:

Identificador interno de compra e intento.

transactionId de Izipay.

Número de orden o referencia, cuando aplique.

Importe y moneda enviados y confirmados.

Código de respuesta y estado interpretado.

Fecha y hora del resultado.

Resultado de validación de firma.

Evidencia técnica y registro de auditoría, sin almacenar datos sensibles de tarjeta.

Criterios de aceptación:

Un pago solo se marca aprobado después de verificaciones satisfactorias.

El cierre del navegador no genera pérdida de trazabilidad.

Las notificaciones duplicadas no duplican operaciones.

Las diferencias de monto, moneda o referencia impiden aprobar automáticamente.

El estado Por verificar bloquea nuevos intentos hasta su resolución.

Un pago aprobado permite continuar a la elección de horario de una programada o a la asignación/cola de «Lo antes posible»; consentimiento y motivo de Triaje ya se registraron antes del pago.

Una aprobación no modifica automáticamente la cita a Confirmada.

Se conserva evidencia auditable de todas las decisiones de estado.

Referencias de trazabilidad (vinculación preliminar): FL-11-001 | Sin INT EGD específica | Checklist EGD: Sin referencia registrada.

RF-11-004 · Reintentos, duplicados y resultado incierto

Objetivo: Controlar los reintentos de pago y prevenir cargos duplicados cuando se producen errores de comunicación, interrupciones de sesión, acciones repetidas o respuestas inciertas de Izipay.

Actores: TITULAR, Salud 365, Izipay; EGD y ADMINISTRADOR cuando aplique.

Precondiciones:

• Compra existente.

• Intento de pago registrado o solicitud para iniciar uno.

• Identificadores de correlación disponibles.

• Mecanismo de consulta, recuperación o conciliación definido según la integración Izipay.

Flujo principal:

1. El TITULAR inicia una operación de pago.

2. Salud 365 registra el intento.

3. Ocurre una interrupción o se recibe una solicitud repetida.

4. Salud 365 verifica si existe un intento previo asociado a la compra.

5. Si el intento continúa en proceso o su resultado es incierto, no inicia otro cobro.

6. Recupera o consulta el resultado del intento original mediante el mecanismo disponible.

7. Si el resultado anterior es un rechazo final, puede habilitar un nuevo intento.

8. Si el resultado sigue siendo incierto, registra o mantiene el caso para conciliación.

Validaciones y reglas:

No iniciar dos cobros concurrentes para la misma compra

Utilizar identificadores de correlación e idempotencia según las capacidades verificadas

Validar el estado de la compra desde el backend antes de cobrar

No reutilizar arbitrariamente identificadores que Izipay exige únicos

No permitir un nuevo cargo mientras exista un resultado incierto

Conservar todos los intentos y su historial

Enviar casos no resolubles a RF-11-010

Criterios de aceptación:

Doble clic en Pagar:Se controla una sola operación activa

Actualización de la página:Se recupera la compra y su intento

Timeout después de enviar el pago:Queda Por verificar

Pago previamente aprobado:No se permite un nuevo cobro

Rechazo final confirmado:Se habilita un nuevo intento controlado

Dos notificaciones iguales:El resultado se procesa una sola vez a nivel de negocio

Observación técnica:

Izipay documenta notificaciones de resultados mediante IPN y mecanismos de consulta del estado a través del SDK Web. Sin embargo, el endpoint, la semántica de idempotencia y las garantías de recuperación deben validarse para la modalidad contratada.

No basta con deshabilitar el botón Pagar. El control de concurrencia y duplicados debe realizarse también en el backend y la base de datos de Salud 365.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-11-005 · Consulta de pagos e historial del TITULAR(referenciado desde Modulo 01)

Objetivo: Permitir que el TITULAR autenticado consulte el historial de compras y pagos efectuados en Salud 365, identificando el paciente beneficiario, servicio contratado, importe, estado del pago y su relación con citas o incidencias registradas.

Actores: TITULAR, Salud 365.

Precondiciones:

• TITULAR autenticado.

• El TITULAR tiene autorización para acceder a las operaciones solicitadas.

• No necesita tener un servicio o paciente previamente seleccionado.

Flujo principal:

1. El TITULAR ingresa a la opción «Mis pagos».

2. Salud 365 consulta las compras asociadas al usuario.

3. Presenta el listado de operaciones.

4. El TITULAR consulta el registro de operaciones, sin que tocar un pago histórico abra una cita, reactive una solicitud o lo redirija a otra pantalla.

5. Salud 365 muestra en el registro los datos autorizados del pago y la referencia de su solicitud o cita cuando exista; la consulta histórica no retoma el flujo de contratación.

6. Las incidencias financieras se conservan con su trazabilidad; su gestión corresponde al flujo administrativo autorizado y no a navegar desde un pago histórico.

Validaciones y reglas:

Mostrar únicamente las compras que el TITULAR está autorizado a consultar

Diferenciar el estado del pago del estado de la cita

Mostrar compras pagadas sin cita asociada

No exponer datos sensibles de tarjeta

El historial financiero no debe mostrar datos clínicos

Mostrar la operación aun cuando la integración de EGD esté temporalmente indisponible

Permitir identificar el número de referencia de compra

Criterios de aceptación:

• El TITULAR visualiza sus compras y pagos como registro de consulta; las filas del historial no navegan ni ejecutan acciones de contratación.

• Puede identificar el paciente de cada compra.

• Distingue el estado del pago y el de la cita.

• Visualiza una compra aprobada que aún no tiene cita.

• No puede consultar pagos de otros titulares sin autorización.

• El historial continúa disponible aunque EGD esté temporalmente fuera de servicio.

Recomendación: el historial se consulta desde los registros de Salud 365, incluidos los pagos sin cita confirmada; Izipay se utiliza cuando sea necesario verificar o conciliar el resultado, sin depender de EGD para mostrar el registro financiero.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-11-006 · Conciliación de pagos y cita (BATCH)

Objetivo: Permitir que Salud 365 identifique, registre y gestione inconsistencias entre las compras, las transacciones procesadas mediante Izipay y las solicitudes o citas administradas por EGD, manteniendo la trazabilidad financiera y operativa hasta su resolución.

Actores: Salud 365, Izipay, EGD y ADMINISTRADOR autorizado.

El TITULAR puede consultar el estado de una incidencia propia, pero no ejecuta la conciliación administrativa.

Precondiciones:

• Existen compras, intentos de pago o solicitudes de cita registradas.

• Salud 365 dispone de referencias que permiten correlacionar las operaciones.

• Se han definido mecanismos de consulta y conciliación con Izipay y EGD.

Flujo principal:

1. Salud 365 identifica operaciones pendientes o inconsistentes.

2. Obtiene los datos registrados de la compra y del pago.

3. Verifica el resultado con Izipay cuando sea necesario y técnicamente posible.

4. Consulta la existencia o estado de la cita en EGD, cuando aplique.

5. Compara las respuestas con los estados almacenados.

6. Si existe una inconsistencia, registra una incidencia.

7. Si la evidencia permite corregirla automáticamente, actualiza el estado correspondiente con trazabilidad.

8. Si requiere intervención humana, deriva el caso al ADMINISTRADOR.

9. Registra la resolución y cierra la incidencia cuando corresponda.

Matriz de conciliación propuesta:

Pago Izipay	Situación EGD	Acción Salud 365
Aprobado	Cita confirmada	Verificar vínculo y cerrar pendiente
Aprobado	Cita inexistente	Registrar pago sin cita
Aprobado	Resultado de cita incierto	Consultar antes de reintentar la creación
Rechazado	Cita confirmada	Registrar inconsistencia crítica
Por verificar	Sin cita	Conciliar pago; no generar otro cobro
Aprobado	Cita cancelada	Evaluar política económica

Validaciones y reglas:

Toda compra pagada debe poder vincularse con una atención/cita o una incidencia documentada

No crear nuevamente una cita solo porque EGD no devolvió respuesta

Verificar si la cita ya fue creada antes de repetir una solicitud

No modificar pagos definitivos sin evidencia verificable

Los casos no resueltos automáticamente deben escalarse

Registrar motivo, fechas, referencias y responsable de regularización

La conciliación no debe generar cargos adicionales

Las operaciones de conciliación deben ser idempotentes

Ejemplo práctico: Un TITULAR realiza el pago de una consulta programada y posteriormente solicita el agendamiento.

EGD registra correctamente la cita, pero se produce un timeout antes de responder a Salud 365.

Salud 365 no debe crear nuevamente la cita de forma «Lo antes posible». Primero debe intentar determinar si EGD creó la reserva original.

Dependencia crítica con EGD: se necesita confirmar si existe una API para consultar una cita por identificador de solicitud o referencia externa y si la creación admite protección contra solicitudes repetidas.

Criterios de aceptación:

• Identificar pagos aprobados sin cita.

• Identificar citas confirmadas asociadas con pagos no confirmados.

• Evitar duplicidad de citas durante los reintentos.

• Registrar todas las inconsistencias y su seguimiento.

• Permitir al ADMINISTRADOR consultar y actualizar la gestión de incidencias dentro de sus permisos.

• Conservar el historial completo de regularización.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-11-007 · Administración, auditoría y seguridad de pagos (referenciado desde Modulo 12)

Objetivo:

Permitir que los administradores autorizados supervisen las operaciones de pago e incidencias, consulten resultados de conciliación y registren acciones de seguimiento, asegurando controles de acceso, trazabilidad y protección de información financiera y personal.

Actores:

• Principal: ADMINISTRADOR.

• Sistema: Salud 365.

• Integraciones de consulta o conciliación: Izipay y EGD, cuando corresponda.

Precondiciones:

• ADMINISTRADOR autenticado.

• Perfil autorizado para consultar pagos o gestionar incidencias.

• Existencia de operaciones registradas.

• Mecanismos de auditoría habilitados.

Flujo principal:

1. El ADMINISTRADOR accede al módulo de gestión de pagos.

2. Salud 365 valida sus permisos.

3. Presenta las operaciones e incidencias autorizadas.

4. El ADMINISTRADOR busca por referencia de compra, transacción o paciente.

5. Consulta el detalle de pago y cita asociada.

6. Registra observaciones y acciones de seguimiento.

7. Si corresponde, solicita o ejecuta una conciliación permitida.

8. Salud 365 conserva el registro de auditoría.

Validaciones y reglas:

Solo los perfiles autorizados pueden consultar pagos administrativos

Los permisos de consulta y gestión deben diferenciarse

Registrar usuario, fecha, acción y resultado de las intervenciones

No permitir modificar importes o marcar pagos Aprobados manualmente sin evidencia válida

No almacenar CVV ni información sensible de tarjetas

Evitar exposición de credenciales y secretos de integración

Proteger los registros de auditoría contra modificaciones no autorizadas

Aplicar controles de autorización al consultar información personal del paciente

Criterios de aceptación:

• El ADMINISTRADOR autorizado consulta las operaciones e incidencias permitidas.

• Un usuario sin permiso no puede acceder.

• Las intervenciones administrativas quedan auditadas.

• No se revelan credenciales ni información sensible de tarjetas.

• Las incidencias pueden seguirse desde su registro hasta su resolución.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

---

Descargar Markdown original