Skip to main content
Usa el ambiente de staging para validar tu integración antes de cambiar a producción. Solicita una organización y una API key de staging a soporte@quentli.com. No reutilices credenciales, clientes ni métodos de pago de producción.
Staging es no productivo, pero no es un simulador completamente aislado. Los webhooks que registres reciben llamadas HTTP reales y algunos flujos pueden enviar correos o mensajes. Usa direcciones de correo y teléfonos que controles.

Prepara un receptor de webhooks

Antes de probar pagos, registra un endpoint HTTPS que responda 2xx rápidamente. Conserva eventId y procesa los eventos de forma idempotente. Para una integración de adeudos, registra al menos:
  • PAYMENT_METHOD_CREATED
  • PAYMENT_ATTEMPT_SUCCEEDED
  • PAYMENT_ATTEMPT_FAILED
  • INVOICE_PAID
  • PAYMENT_COMPLETED
POST /v1/webhooks
Consulta el historial de entregas y vuelve a intentar los eventos fallidos desde la API de webhooks. No asumas que los eventos llegan en orden: el cobro y la notificación se procesan de manera asíncrona.

Prueba pagos con tarjeta

Completa el formulario de tarjeta del portal con los siguientes datos de prueba:
Estos escenarios dependen del procesador configurado y de los mocks activos en staging. Úsalos para validar tu manejo de resultados, no como una matriz universal de los procesadores.
Para cada escenario, valida tanto el resultado que muestra el portal como los webhooks que recibe tu sistema.

Simula pagos de efectivo y transferencia

En staging, obtén el pago que quieres probar mediante la API REST. Primero solicita las instrucciones de efectivo o transferencia para una factura pendiente y conserva el payment.id de la respuesta:
POST /v1/invoices/{invoiceId}/payments
Usa CASH en lugar de TRANSFER para probar efectivo. Consulta Sincroniza facturas en Quentli para ver el formato de las instrucciones. Después simula una liquidación exitosa con la siguiente solicitud. Usa la URL base de staging:
POST /v1/sandbox/payments/{paymentId}/complete
Esta ruta solo acepta pagos pendientes de tipo CASH o TRANSFER y está bloqueada en producción. Genera un evento simulado del procesador y continúa por el flujo normal de Quentli. Verifica que tu endpoint reciba INVOICE_PAID y PAYMENT_COMPLETED cuando la factura quede liquidada.
La simulación requiere que la organización tenga configurado el procesador correspondiente. Si la referencia no se puede crear o el pago ya no está pendiente, la ruta devuelve un error y no genera eventos.

Prueba un pago recibido fuera de Quentli

Para probar cómo procesa tu sistema un pago que se recibió por otro proveedor, marca una factura como pagada:
Este flujo genera un pago de tipo OTHER y permite validar INVOICE_PAID_OTHER y PAYMENT_COMPLETED. No simula una liquidación real de efectivo o SPEI.

Precauciones para las simulaciones

  • No uses la ruta de simulación en producción: está bloqueada fuera de ambientes no productivos.
  • Las integraciones y mocks de staging pueden cambiar entre pruebas. Si un resultado no coincide con esta guía, confirma la configuración del procesador con soporte.
  • Las simulaciones pueden activar recibos, notificaciones de la organización y webhooks de tu integración.
  • No hay una simulación soportada para domiciliación bancaria.
  • No uses la simulación de OXXO como criterio de certificación; no tiene un flujo de pruebas confiable.

Lista de verificación antes de producción

  1. Crea clientes de prueba con identificadores externos únicos.
  2. Valida un pago exitoso, un rechazo y, cuando aplique, 3DS.
  3. Valida efectivo, transferencia y pagos externos si los usarás.
  4. Confirma que tu receptor tolera reintentos, eventos duplicados y entregas fuera de orden.
  5. Reemplaza la URL base y API key de staging por las de producción.
  6. Usa únicamente datos reales y consentidos después de pasar a producción.