Conectar un botón de pago no termina el trabajo de una tienda. El negocio también debe saber qué pedido corresponde a cada transacción, cuándo confirma una compra y cómo atender una operación que queda pendiente o se rechaza. Esas decisiones deben estar claras antes de abrir la venta.

Describe el recorrido completo

Parte de una compra hipotética: el cliente selecciona un producto, revisa las condiciones, intenta pagar y vuelve a la tienda. El sistema necesita conservar una referencia que permita relacionar pedido y transacción. Si el pago no se confirma inmediatamente, la persona debe saber qué ocurre y cómo consultar o recibir una actualización.

No confundas haber llegado a la pantalla de retorno con haber pagado. Wompi documenta estados distintos, como pendiente, aprobado, rechazado y error. El proveedor que elijas puede tener su propio flujo y documentación: revísalos antes de definir la regla de tu tienda.

Compara condiciones del proveedor

Revisa medios de pago admitidos, tarifas, momentos de liquidación, moneda, requisitos de cuenta y disponibilidad para tu negocio. Pregunta quién administra la cuenta, cómo se gestionan los reembolsos y qué soporte hay ante un error. Las condiciones comerciales y normativas cambian y deben verificarse con el proveedor y los asesores correspondientes.

Una integración a medida no modifica automáticamente las comisiones o los contratos del proveedor. Separa el costo de implementación del costo de operación y de las condiciones que la entidad de pagos aplica a cada transacción.

Diseña confirmaciones y excepciones

Define cómo recibirá el sistema una notificación fiable, cómo comprobará su integridad y qué hará cuando la reciba dos veces o fuera de orden. Wompi describe eventos por webhook y mecanismos de validación para su servicio. Antes de marcar un pedido como pagado, verifica en el servidor el estado autorizado y que la referencia, el importe y la moneda coincidan con el pedido, siguiendo las instrucciones vigentes del proveedor. Una notificación repetida no debe provocar una segunda entrega o cargo.

Decide quién revisa transacciones que no coinciden con un pedido, pagos pendientes durante demasiado tiempo o importes distintos de lo esperado. Conserva referencias e historial apropiados sin exponer claves ni datos sensibles en el navegador.

Prueba antes de habilitar ventas

  • Una operación aprobada y otra rechazada en el ambiente de pruebas.
  • Un pago que queda pendiente y se actualiza después.
  • La persona cierra el navegador antes de volver a la tienda.
  • Una notificación repetida o una interrupción de la conexión.
  • Una comparación entre el registro del proveedor y el pedido interno.

Define además el canal de ayuda para el comprador y ensaya el procedimiento de conciliación con el equipo. La documentación técnica orienta la conexión; los acuerdos de pagos y las obligaciones del negocio requieren revisión específica.

Acuerda quién resuelve una diferencia

Cuando el proveedor muestra una transacción aprobada pero el pedido no aparece, el equipo necesita una ruta para encontrar la referencia, revisar el historial y atender al comprador. Especifica quién tiene acceso a esas pantallas y cómo se evita crear otro pedido o cobro durante la revisión.

Prepara mensajes distintos para pago pendiente, rechazado o confirmado, respetando la terminología de la pasarela elegida. Incluye un medio de contacto y evita dar por completada una operación cuyo estado aún no se ha verificado. Prueba también cómo se comunica una corrección posterior.

Fuentes consultadas

Planeemos el recorrido de compra

Cuéntanos cómo vendes y qué necesitas confirmar antes de preparar cada pedido.

Conversar sobre mi tienda