Flujos de Pago Robustos: La Verdad del Webhook en TuTiendaWeb

En el desarrollo de TuTiendaWeb, un componente crucial es la experiencia de compra, especialmente el proceso de pago. Asegurar que los usuarios puedan completar sus transacciones sin interrupciones es fundamental. Recientemente, abordamos un desafío específico en el flujo de pagos de Mercado Pago que impactaba directamente la usabilidad.

El Problema

Anteriormente, cuando un usuario generaba un link de pago con Mercado Pago en TuTiendaWeb, la interfaz de usuario entraba inmediatamente en un estado pendiente/confirmando. Esto significaba que la tienda online mostraba mensajes como "Confirmando pago" o "Cancelar intento", y el layout restringía ciertas acciones, asumiendo que el pago estaba en proceso. El problema surgía cuando un usuario generaba el link, pero luego regresaba a la tienda sin completar la transacción en la pasarela de pago. En estos casos, la tienda quedaba bloqueada en este estado "confirmando", impidiendo al usuario regenerar un nuevo link de pago o interactuar normalmente con la plataforma. La experiencia era frustrante y llevaba a estados inconsistentes.

La Solución

Para resolver este inconveniente y mejorar drásticamente la fiabilidad del proceso, implementamos un cambio fundamental: el webhook de Mercado Pago se convirtió en la única fuente de verdad para el estado de la transacción. Esto significa que la UI ya no entra en un estado pendiente/confirmando inmediato al generar el link de pago.

La lógica ahora opera de la siguiente manera:

1. Generación del Link: El usuario genera el link de pago de Mercado Pago. La UI no cambia a un estado de "confirmando" internamente en este punto.
2. Redirección: El usuario es redirigido a la pasarela de pago de Mercado Pago.
3. Procesamiento Asíncrono: Independientemente de si el usuario completa el pago o no, la UI de TuTiendaWeb permanece activa, permitiendo incluso regenerar un link si es necesario.
4. Confirmación por Webhook: Solo cuando Mercado Pago notifica a nuestro backend a través de un webhook que el pago ha sido exitoso o fallido, se actualiza el estado real de la transacción en nuestra base de datos (por ejemplo, en Firestore).
5. Reflejo en la UI: La interfaz de usuario reacciona a los cambios en la base de datos, reflejando el estado final del pago (pagado, cancelado, etc.), pero solo después de recibir la confirmación oficial del webhook.

Esta aproximación elimina la necesidad de estados intermedios en el frontend que no están respaldados por una confirmación externa, lo que hace el flujo mucho más robusto y amigable para el usuario. Ya no se producen bloqueos, y la regeneración de links de pago es fluida.

Flujo de Pagos Optimizado (Conceptual)

// Antes: Lógica UI de estado 'pendiente'
const generatePaymentLink = async () => {
  // setState({ status: 'pending' }); // Causa el bloqueo
  // ... llamar API para link ...
  // if (link) window.location.href = link;
};

// Después: Webhook como única fuente de verdad
const generatePaymentLink = async () => {
  // ... llamar API para link ...
  // if (link) window.location.href = link;
  // No hay cambio de estado local a 'pending'
  // El webhook actualizará el estado del pedido en la base de datos
  // y la UI reaccionará a ese cambio.
};

// Lógica del Webhook (backend)
// const webhookHandler = (data) => {
//   if (data.status === 'approved') {
//     updateOrderStatusInFirestore(data.orderId, 'completed');
//   } else if (data.status === 'rejected') {
//     updateOrderStatusInFirestore(data.orderId, 'failed');
//   }
// };

Impacto y Aprendizajes Clave

La eliminación del estado pendiente/confirmando inicial en TuTiendaWeb ha mejorado significativamente la experiencia del usuario y la resiliencia de la plataforma. Los usuarios ya no quedan atrapados en un limbo de "confirmación", lo que reduce la fricción y la frustración.

El aprendizaje clave aquí es la importancia de confiar en una única fuente de verdad para operaciones asíncronas críticas, como los pagos. Los webhooks ofrecen un mecanismo confiable para que los servicios externos comuniquen estados finales, liberando a la interfaz de usuario de la carga de mantener estados provisionales que pueden volverse inconsistentes. Para cualquier funcionalidad que dependa de una confirmación externa, es preferible delegar la gestión del estado a ese mecanismo asíncrono y reactivar la UI en consecuencia.

Generated with Gitvlg.com