En este artículo
Dos proveedores dan por terminada la entrega. ¿Qué pruebas pides antes de aceptarla?
Los compradores pagaban y el producto nunca les llegaba. Cuando escribían a soporte, el operador abría la aplicación y veía el pago como pendiente. Le llovieron consultas. ¿Qué le dices a alguien que tiene un cargo en su cuenta si tú ni siquiera encuentras su pedido?
En este caso faltaba configurar el webhook de pagos. La notificación que debía llegar al servidor para registrar la compra se perdía por el camino. El operador tampoco tenía monitorización para detectar la discrepancia. Me acuerdo de este caso cuando dos proveedores me dicen que cada uno ha terminado su parte. Mi primera pregunta es qué necesita conseguir el cliente una vez que las dos piezas funcionan juntas.
¿Qué resultado necesita aceptar el cliente?
Pido que el responsable de producto describa una operación con un principio y un final observables. En una compra, el usuario paga, el pedido queda registrado y el operador puede tramitarlo. Con ese resultado delante, revisamos los requisitos acordados y delimitamos qué demuestra cada proveedor. Así aparece el paso que atraviesa ambos sistemas y que alguien tiene que probar en su conjunto. En otro proyecto, explicamos cómo organizamos las pruebas entre servicios y proveedores.
¿Cómo se descubre un cobro que nunca se convierte en pedido?
Para la próxima entrega pediría una compra de prueba sobre la versión candidata, con la configuración de pagos del entorno que se evalúa. Seguiría la misma referencia desde la confirmación del cobro hasta el pedido visible para operaciones. Si la demostración termina en la página de agradecimiento, todavía queda por comprobar quién puede entregar lo que el comprador acaba de pagar.
La guía de Stripe para tramitar pedidos ilustra esa diferencia. El navegador puede cerrarse después del cobro. La integración necesita poder iniciar la tramitación a partir de un evento recibido por el servidor. La documentación de webhooks explica cómo revisar los intentos de entrega. El vídeo sobre un pago confirmado y un pedido pendiente ilustra cómo se ve esta discrepancia en una integración con Stripe.
¿Qué debería contener el acta de pruebas de los dos proveedores?
Propongo completar juntos una ficha como esta con datos de prueba. Quien decide sobre la entrega debería poder seguir la operación y pedir que se repita sobre las mismas versiones. Si queda un hueco entre el último registro de un proveedor y el primero del siguiente, anótalo antes de firmar.
| Aspecto | Qué deben mostrar los proveedores | Qué se registra |
|---|---|---|
| Requisito y alcance | Un único pedido listo para tramitar por cada cobro confirmado. | Identificador del requisito, versiones de ambos sistemas y entorno. |
| Compra completada | La misma operación desde el proveedor de pagos hasta el pedido visible para operaciones. | Referencia de prueba, estado final observado y enlace a la evidencia. |
| Compra interrumpida | Quién detecta un aviso retrasado y cómo recupera el pedido. | Alerta, responsable, resultado de la recuperación y comprobación de duplicados. |
| Decisión y seguimiento | Qué riesgo queda pendiente y quién tiene autoridad para aceptarlo. | Decisión, responsable, asuntos abiertos y fecha de la próxima prueba. |
La guía de monitorización de Google SRE distingue los síntomas visibles para el usuario de las señales internas. Aquí pediría ambas cosas. Un aviso de pedido pendiente sirve a operaciones. El historial de eventos ayuda al equipo técnico a localizar dónde dejó de avanzar.
¿Cuánta verificación merece cada entrega?
Compara el coste de la prueba con el daño de equivocarte. Un fallo que deja dinero cobrado y pedidos sin tramitar merece una prueba repetible de extremo a extremo y una comprobación manual desde la cuenta de operaciones. Para estimar la carga de esa prueba, pregunta cuántos compradores coinciden en el momento de mayor demanda. El total mensual responde a otra pregunta.
También cuenta el historial del equipo. Si un proveedor fiable ajusta un texto de ayuda, una revisión breve puede bastar. Si cambia un flujo de cobro, yo mantendría el ensayo completo. Una revisión humana y una revisión con IA orientada a buscar contradicciones ayudan a elegir qué casos ensayar. Quien firma debe poder ver qué ocurrió al ejecutarlos. Para acotar el esfuerzo puedes usar la lista de pruebas antes del lanzamiento.
¿Quién acepta la entrega y quién atiende un fallo después?
Acuerda con ambos proveedores quién revisa el recorrido completo, quién acepta la entrega por parte del cliente y quién autoriza la puesta en producción. Deja por escrito el alcance del mantenimiento y cómo se tramita un defecto que reaparece. Una ventana de corrección de 30 días es una condición que se puede pactar. Hay que consultar el acuerdo concreto para saber qué cubre.
Si los proveedores discrepan sobre la evidencia, nuestro servicio de QA puede contrastar el recorrido. Para preparar la intervención, consulta qué se revisa durante el primer mes de QA externa o cuéntanos qué operación necesitas aceptar. Pide el rigor que merecen el daño posible y la trayectoria de quienes entregan.