Casos de prueba API de pagos con suscripción

1. Request y response del servicio de pago con la API y pantallazo del comprobante de pago aceptado desde la app, en el ambiente de pruebas de QA y con un número de celu que esté activo. Además, el request y response del servicio de consulta de estado de pago, que demuestre que fue aceptado.

2. Request y response del servicio de pago con la API, en el ambiente de pruebas de QA y con un número de celu que esté activo, pero el pago debe haberse rechazado desde la app.

3. Request y response del servicio de pago con la API, en el ambiente de pruebas de QA y con un número de celu que esté activo, pero el pago debe vencerse o expirar, y esperar 45 minutos.

4. Request y response del servicio de una nueva suscripción de la API, con un número de celu que no exista en QA.

5. Request y response del servicio de pago con la API y pantallazo del comprobante de pago desde la app, en el ambiente de pruebas de QA y con un número de celu que esté activo. Además, el request y response del servicio de consulta de estado de pago, que demuestre que funcionó sin problema.

6. Request y response del servicio de pago automático con la API, con un monto mayor al saldo que tiene un número de celu que esté activo y exista en el ambiente de pruebas de QA.

7. Request y response del servicio de pago automático con la API, con una suscripción que no fue aceptada por un número de celu que esté activo y exista en el ambiente de pruebas de QA.

8. Request y response del servicio de pago automático con la API, con una suscripción que fue rechazada por un número de celu que esté activo y exista en el ambiente de pruebas de QA.

9. Request y response del servicio de devolución o reverso de un pago con la API que haya funcionado sin problema.

Este servicio debe usarse si hay fallas técnicas en tu sistema con la confirmación del pago, o cuando el servicio de Nequi para consultar el estado de un pago, muestra timeout o error 500 y no se puede confirmar si el usuario Nequi realizó o rechazo el pago.