Cálculo del coste de una integración de pagos
Cómo realizar una estimación de una integración de pagos: entorno de pruebas frente a entorno de producción, reembolsos, webhooks, idempotencia y ámbito de aplicación de la normativa PCI. La conversación que debe mantenerse antes de que se concrete cualquier cifra.
En el ticket pone «añadir Stripe». En el documento pone «medio cuarto».
Los pagos cuentan con una interfaz API pública que cabe en una sola página y una interfaz de toma de decisiones privada que no cabe. La selección de un proveedor supone un pico de trabajo de un día. La configuración del proceso de pago en condiciones óptimas lleva un par de días. Todo lo que viene después (el flujo de reembolsos, la política de reintentos de los webhooks, las claves de idempotencia, el informe de conciliación que el departamento financiero solicitará en el segundo mes) constituye la funcionalidad propiamente dicha, y nada de ello figura en el ticket.
La historia que dice «integrar Stripe» rara vez es la historia que se está evaluando. La historia que se está evaluando es «podemos aceptar pagos, realizar reembolsos, demostrar que los hemos recibido y hacer frente a un cargo impugnado». Hasta que el equipo no vote sobre ese alcance, la cifra no es más que una estimación sobre algo distinto.
Lo que se dice en la sala
Backend: «Sandbox es sencillo. La biblioteca se encarga de casi todo».
SRE: «Los webhooks deben ser idempotentes. ¿Cuál es nuestra estrategia de reintento en caso de que Stripe vuelva a enviar la solicitud?»
Finanzas: «¿Cómo se concilian los reembolsos? ¿Y los reembolsos parciales?»
Cumplimiento normativo: «¿Manejamos números de tarjetas de crédito o nos ceñimos al SAQ-A?»
PM: «¿Qué dice el correo electrónico sobre el pago fallido y quién lo redacta?»
Preguntas que conviene plantearse antes de votar
- ¿Primero solo en el entorno de pruebas, o se incluirán las claves de producción desde el primer día?
- Reembolsos y reembolsos parciales: ¿UI, API o solo para administradores?
- Idempotencia de los webhooks y gestión de reintentos: ¿a quién pertenece la tabla de deduplicación?
- Ámbito de aplicación de la norma PCI: ¿cumplimos con el SAQ-A si nunca accedemos al PAN?
- Reconciliación: ¿quién elabora el informe y con qué fuente de referencia se compara?
- Experiencia de usuario en caso de fallo: ¿se incluyen en el ámbito de aplicación las tarjetas rechazadas, las tarjetas caducadas y los problemas con 3DS?
Lo más adecuado en un caso como este suele ser dividirlo en partes. «Cobrar» es una parte; «devolver el dinero» es otra; y «conciliar el dinero» es una tercera. Si se tratan como un todo, la integración se entrega en la tercera semana y el departamento de finanzas pregunta dónde está el informe en la octava.
Vote a favor de «demostrar que hemos recibido el dinero y hemos superado el conflicto», y no de «llamar a la API de pago».
Véase también: errores habituales en el «planning poker» al dividir las historias demasiado tarde; técnicas de estimación para trabajos de esta complejidad. Consulte los demás ejemplos prácticos de estimación o inicie una sesión gratuita de «planning poker» cuando el refinamiento esté listo.