Configurar Wompi en Merez: guía paso a paso

Configurar Wompi en Merez es conectar el módulo Pedidos con la pasarela para que tu cliente pague con tarjeta, PSE, Nequi o Bancolombia y el pedido se marque solo cuando la transacción se aprueba. Son cuatro credenciales, dos bloques de llaves y un selector de modo. Aquí ves dónde se consigue cada dato, cómo se ve una venta aprobada y una rechazada, y qué revisar antes de cobrar dinero real.

Qué necesitas antes de empezar

• El módulo Pedidos activo. La tarjeta de Wompi vive en Ajustes → Integraciones, y el checkout que la usa es el de Pedidos. Ojo con un detalle: el cobro automático por pasarela exige además el módulo Pagos automáticos encendido. Con Pedidos solo, Bre-B funciona; Wompi no.
• Una cuenta de comercio en Wompi. Las llaves se crean en comercios.wompi.co, en Desarrolladores → Llaves del API. Ahí están las de sandbox y las de producción.
• El sitio publicado y el checkout funcionando. La prueba se hace comprando, no mirando la pantalla de configuración.
• Un pedido de prueba. Con $80.000 alcanza para ver el recorrido completo sin arriesgar mucho.
• Permisos. Solo un propietario del sitio puede abrir y guardar Ajustes → Integraciones. Si otra persona del equipo la necesita, tiene que quedar como propietaria.

Las credenciales, una por una

Wompi entrega cuatro datos por ambiente y el prefijo los delata: pub_test_, prv_test_, test_integrity_ y test_events_ son de pruebas; pub_prod_, prv_prod_, prod_integrity_ y prod_events_ son de producción. Una llave de un ambiente no sirve en el otro, y la documentación de ambientes y llaves lo dice con todas las letras.

En Merez el formulario tiene dos bloques, Llaves de pruebas y Llaves de producción, y arriba un selector de Modo activo. Los cuatro campos se guardan por separado en cada bloque y cifrados. Los secretos no se vuelven a mostrar completos: si uno ya está guardado, el campo aparece vacío y solo se reemplaza si escribes uno nuevo.

Qué significa cada modo

Pruebas es el ambiente sandbox de Wompi: las transacciones son simuladas, no se cobra dinero real y lo que pase ahí no existe en producción. Producción mueve dinero de verdad. Los dos ambientes son independientes: una transacción de sandbox no aparece en el reporte de producción ni al contrario.

El error más caro es cambiar el modo sin llenar el bloque de producción. El selector no copia llaves: solo elige cuál de los dos bloques se usa. Si dejas las llaves test y pasas a Producción, el checkout se sigue armando contra sandbox y ninguna venta cobra.

Simulación de uso: de la plataforma a Merez

Supón una venta de $80.000 (8.000.000 de centavos, que es como Wompi recibe los montos).

1. El cliente arma el pedido. Elige pagar con tarjeta y deja sus datos. Merez crea el pedido en estado Nuevo, con su número (PED-…) y una referencia interna con la forma MRZ-sitio-pedido. Esa referencia es la que después buscas en Wompi.
2. Merez arma el checkout. Con la llave pública del modo activo, el monto en centavos y una firma calculada con el secreto de integridad, abre el checkout de Wompi. El cliente escoge el medio de pago y paga.
3. Si el pago se aprueba. Wompi envía el evento transaction.updated con estado APPROVED a la URL de eventos. Merez valida la firma SHA256 con el secreto de eventos, comprueba que el monto sea exactamente el del pedido y que el pedido sea de ese sitio; si todo cuadra, lo pasa a Verificado con la marca auto:wompi. Desde ahí ya puedes despachar.
4. Si el pago se rechaza. Llega DECLINED (o ERROR) y el pedido se queda en Nuevo: nadie lo mueve por ti. Decides si el cliente reintenta o si rechazas el pedido.
5. La entrega. Con el pedido en Verificado, el botón Marcar entregado lo cierra y queda en Entregado.

En el panel, el pedido se ve en Pedidos con su estado y su total. En el panel de Wompi, la transacción se ve con la referencia MRZ-…, el monto en centavos y el estado en mayúsculas: APPROVED, con un mensaje como «Transacción aprobada», o DECLINED cuando el emisor niega el cobro. Los estados posibles de una transacción son PENDING, APPROVED, DECLINED, VOIDED y ERROR, y una transacción recién creada siempre nace en PENDING.

Qué cambia exactamente el estado del pedido

Con Wompi el que cambia el estado es el webhook, no la pantalla. Un APPROVED autenticado y con el monto correcto verifica el pedido sin que toques nada. Un DECLINED no lo cambia: si quieres cerrar ese pedido, lo rechazas a mano. Y un pedido que ya está Verificado o Entregado no se toca aunque llegue otro APPROVED del mismo pago, porque Merez solo actúa sobre pedidos en Nuevo o en Pago por verificar.

Cómo comprobar que quedó bien

1. Pon el modo en Pruebas, llena el bloque de pruebas con las cuatro llaves test, activa la integración y guarda.
2. Haz un pedido de $80.000 desde tu propio sitio y paga con la tarjeta 4242 4242 4242 4242, cualquier fecha futura y un CVC de tres dígitos. Esa tarjeta aprueba siempre en sandbox, según los datos de prueba oficiales.
3. Vuelve a Pedidos: el pedido tiene que estar en Verificado sin que hayas pulsado nada, y en el detalle deben verse la referencia y la fecha de verificación.
4. Busca la transacción en el panel de Wompi, en sandbox: referencia MRZ-…, monto 8000000, estado APPROVED.
5. Repite con 4111 1111 1111 1111: la transacción queda DECLINED y el pedido sigue en Nuevo. Cualquier otra tarjeta termina en ERROR.
6. Solo cuando las dos pruebas salgan bien: llena el bloque de producción con las llaves prod, cambia el Modo activo a Producción, guarda y haz una compra real de monto bajo. Lo que debe cambiar no es la pantalla sino el extracto: la venta tiene que aparecer en tu cuenta Wompi.

Errores frecuentes

Límites y buenas prácticas

• La comisión la cobra Wompi, no Merez. Depende del medio de pago y del plan que tengas con ellos. La tarifa vigente está publicada en wompi.com/es/co/planes-tarifas y en Conoce nuestros planes. Aquí no ponemos cifras porque cambian.
• El dinero no pasa por Merez. Entra a tu cuenta de comercio en Wompi y se dispersa según tu acuerdo con ellos. Merez inicia el cobro y recibe el aviso; no retiene la plata.
• Reversos y reembolsos. Una transacción de tarjeta se puede anular (VOID) solo en ciertos estados, y los reembolsos se gestionan en Wompi. Merez no ejecuta ni una cosa ni la otra: si hay que devolver plata, se hace desde Wompi y el pedido se ajusta a mano.
• Webhooks con reintentos. Si tu servidor no responde 200, Wompi reintenta hasta tres veces en 24 horas: a los 30 minutos, a las 3 horas y a las 24. Merez responde 200 y es idempotente, así que un APPROVED repetido no vuelve a verificar el pedido.
• Las llaves se tratan como contraseñas. La privada y los dos secretos no van en el código del sitio, ni en un chat, ni en una captura de pantalla. El formulario de Integraciones las guarda cifradas y no las vuelve a mostrar.
• Lo que Merez no hace con Wompi: no guarda datos de tarjeta (el cliente los digita en el checkout de Wompi), no parte un pago en dos, no factura electrónicamente y no concilia contra tu banco. Eso queda del lado de Wompi y de tu contabilidad.
• Un modo a la vez. Puedes tener las dos parejas de llaves guardadas, pero solo una activa. Si vas a probar, vuelve a Pruebas; y acuérdate de regresar a Producción antes de la primera venta del día.