Cómo conectar tu sistema con WhatsApp, Mercado Pago o tu ERP sin romper nada

Un servicio externo se integra de forma segura cuando definís de antemano qué datos viajan, quién es la fuente de verdad y qué pasa cuando el otro lado no responde, y recién después escribís código. Con eso resuelto, sumar cobros, mensajería o una sincronización con tu ERP no obliga a cambiar el sistema que ya funciona: se agrega una capa que se puede probar, monitorear y apagar.

Qué significa integrar

Integrar es lograr que dos sistemas intercambien información sin que una persona copie datos a mano. Hay tres mecanismos, y casi todo proyecto usa más de uno.

Mecanismo	Cómo funciona	Ejemplo
API	Tu sistema le pide algo al otro, o le ordena una acción, cuando lo necesita.	Crear un cobro, enviar un mensaje, consultar el stock.
Webhook	El otro sistema te avisa con una petición HTTP a una URL tuya cuando algo ocurre.	Un pago cambió de estado, llegó un mensaje de un cliente.
Sincronización por lotes	Un proceso programado compara y copia datos cada cierto tiempo.	Actualizar precios y stock desde el ERP cada noche.

La diferencia práctica: con una API vos llamás, con un webhook te llaman. Por eso el webhook necesita una URL pública en tu sitio, que cualquiera puede intentar usar, y de ahí sale casi toda la parte de seguridad de esta nota.

Antes de escribir código

Las integraciones fallan más por decisiones que no se tomaron que por errores de programación. Estas cuatro preguntas conviene contestarlas por escrito.

• Qué datos viajan, en qué dirección y cuáles son personales. Cuanto menos viaje, menos hay que proteger.
• Cuál es la fuente de verdad de cada dato. Si el precio vive en el ERP, el sitio lo lee y no lo edita.
• Qué pasa si el otro servicio no responde o responde tarde: si se reintenta, si se encola o si se le avisa a la persona.
• Qué cuentas y permisos hacen falta, a nombre de quién están y quién las puede renovar. Una integración atada a la cuenta personal de alguien que se va deja de funcionar ese día.

Cobros: el flujo seguro

Para cobrar online con Mercado Pago, la documentación de Checkout Pro describe este recorrido: tu sitio crea una preferencia de pago, la persona paga en el entorno de Mercado Pago y vuelve a tu sitio o al destino que configuraste. De ese recorrido se desprenden cuatro reglas.

1. Creá el pago del lado del servidor. El monto y el producto salen de tu base de datos, nunca de un campo que el navegador pueda modificar.
2. No des por pagado un pedido porque la persona volvió a tu sitio. La redirección pasa por el navegador y se puede manipular o no ocurrir (se cerró la pestaña, se cortó la conexión).
3. Confirmá con la notificación del proveedor. Mercado Pago avisa a tu URL de notificaciones y firma el aviso con un secreto de tu aplicación, enviado en el encabezado x-signature. Verificá esa firma antes de actuar.
4. Consultá el estado real. Una vez validado el aviso, pedile el detalle del pago a la API del proveedor en lugar de confiar en lo que trae el cuerpo.

La misma documentación indica que tu servidor debe responder 200 o 201 dentro de un plazo de 22 segundos; si no, el proveedor reintenta. Dos consecuencias: la respuesta tiene que ser rápida, y el mismo aviso puede llegar más de una vez. Por eso hace falta idempotencia: procesar dos veces el mismo evento no debe generar dos entregas ni dos facturas. Es también la respuesta a la pregunta clásica de qué pasa si el pago se aprueba y tu sitio no se entera: el reintento y una consulta periódica de pedidos pendientes cubren ese hueco.

Ejemplo mínimo: recibir un webhook en PHP

El esquema siguiente verifica la firma de un webhook, descarta eventos repetidos y responde enseguida. Los datos son ficticios y el formato de la firma es genérico: cada proveedor define el suyo. Meta, por ejemplo, documenta un encabezado X-Hub-Signature-256 calculado con SHA256 y el secreto de la aplicación, mientras que Mercado Pago firma con los datos de la notificación y su encabezado x-signature. Leé la documentación de tu proveedor para saber exactamente qué se firma y en qué formato.

<?php
// webhook.php (esquema genérico; adaptá la firma a tu proveedor)
$secreto = getenv('WEBHOOK_SECRETO');          // viene del entorno, no del código
$cuerpo  = file_get_contents('php://input');   // el cuerpo crudo, sin decodificar
$enviada = $_SERVER['HTTP_X_FIRMA'] ?? '';     // p. ej. "sha256=ab12..."

if ($secreto === false || $secreto === '') {
    http_response_code(500);
    exit;
}

$calculada = 'sha256=' . hash_hmac('sha256', $cuerpo, $secreto);
if (!hash_equals($calculada, $enviada)) {      // comparación en tiempo constante
    http_response_code(401);
    exit;
}

$evento = json_decode($cuerpo, true);
$id     = is_array($evento) ? ($evento['id'] ?? '') : '';
if (!is_string($id) || $id === '' || strlen($id) > 64) {
    http_response_code(400);
    exit;
}

try {
    $pdo = conexion_pdo();                      // tu conexión PDO con ERRMODE_EXCEPTION
    // La clave única en event_id hace que un evento repetido falle el INSERT.
    $st = $pdo->prepare(
        'INSERT INTO webhook_eventos (event_id, payload, recibido_en)
         VALUES (:id, :payload, NOW())'
    );
    $st->execute([':id' => $id, ':payload' => $cuerpo]);
} catch (PDOException $e) {
    if ($e->getCode() !== '23000') {            // 23000: clave duplicada
        error_log('webhook: ' . $e->getMessage());
        http_response_code(500);               // el proveedor reintentará
        exit;
    }
    // Duplicado: ya lo teníamos, se responde 200 igual.
}

http_response_code(200);                       // respuesta rápida
// El trabajo pesado (actualizar el pedido, avisar al cliente)
// lo hace otro proceso que lee la tabla webhook_eventos.

La tabla necesita una clave única sobre el identificador del evento, por ejemplo event_id VARCHAR(64) NOT NULL PRIMARY KEY. Tres detalles importan más de lo que parecen: se firma el cuerpo crudo, no el JSON ya decodificado; la comparación usa hash_equals y no ==, para no filtrar información por tiempos de respuesta; y el secreto se lee del entorno. Si el proceso falla después de guardar el evento, el registro queda en la tabla y se puede reprocesar sin que el proveedor tenga que reenviar nada.

Mensajería con WhatsApp

Meta documenta la WhatsApp Business Platform y su Cloud API como la vía para enviar y recibir mensajes de forma programática. Es la opción oficial y la que conviene para avisos de una empresa. Las soluciones no oficiales, que automatizan una cuenta común o la versión web, quedan fuera de esa plataforma y exponen el número a que se lo restrinjan. Antes de elegir, revisá estos puntos.

• Plantillas: según la documentación, los mensajes de plantilla generalmente requieren aprobación previa y son los únicos que se pueden enviar fuera de una ventana de atención al cliente. Un aviso de entrega o un recordatorio de turno se diseña como plantilla.
• Consentimiento: la documentación exige obtener el opt-in de la persona antes de enviarle plantillas, con el nombre de tu empresa y para qué la vas a contactar. Guardá cuándo y cómo lo dio.
• Límites: existen límites de mensajería que acotan a cuántas personas distintas podés escribirles fuera de esa ventana. Se definen a nivel de la cuenta empresarial y conviene planificar los envíos masivos con ellos.
• Webhooks entrantes: los mensajes y estados llegan a tu URL, así que valen las mismas reglas de firma e idempotencia del ejemplo.

Los precios, categorías de plantillas y límites concretos cambian con el tiempo: no los tomes de una nota, consultalos en la documentación vigente. Esto tampoco es asesoramiento legal: para el uso de datos personales y de mensajes automáticos, además de las políticas de la plataforma, consultá a quien corresponda.

ERP y sistemas internos

Con un ERP el desafío casi nunca es técnico: es ponerse de acuerdo en qué significa cada campo. Un trabajo ordenado incluye:

• Mapeo de campos: una tabla que diga que el «código» del ERP es el «SKU» del sitio, en qué formato viaja cada fecha y qué se hace con los valores vacíos.
• Sincronización incremental: traer solo lo que cambió desde la última corrida (con una marca de fecha o un número de versión) y no el catálogo completo cada vez.
• Conflictos: una regla explícita para cuando el mismo dato cambia en los dos lados. Lo más simple es que cada dato tenga un solo dueño.
• Registro de errores y reintentos: cada fila que falla se guarda con su motivo y se reintenta con espera creciente. Nada de errores tragados en silencio.

Si tu ERP no ofrece API, suele haber alternativas como exportaciones programadas, acceso de solo lectura a una réplica o una base intermedia. Se evalúan caso por caso. En la nota sobre por dónde empezar a automatizar procesos en una pyme hay un criterio para decidir qué conectar primero.

Cómo no romper nada

• Entorno de pruebas: los proveedores suelen ofrecer credenciales y cuentas de prueba. Probá ahí el flujo completo, incluidos los pagos rechazados y los avisos duplicados.
• Credenciales por entorno: claves distintas para pruebas y producción, guardadas en variables de entorno y nunca en el repositorio. Una clave que se filtró se rota. La nota sobre OWASP Top 10 repasa cómo cuidar secretos y entradas.
• Monitoreo: un registro de cada evento recibido y enviado, y una alerta cuando hay una racha de errores o cuando no llega ningún aviso en un horario en que debería llegar.
• Plan para volver atrás: un interruptor de configuración que desactive la integración y deje el sistema funcionando como antes. Se prueba antes de necesitarlo.
• Mantenimiento: las APIs cambian de versión. Alguien tiene que leer los avisos del proveedor y actualizar la integración; conviene dejarlo acordado desde el inicio.

En resumen

Antes de dar por terminada una integración, comprobá que se cumpla esta lista:

• Está escrito qué datos viajan y quién es la fuente de verdad de cada uno.
• El pago se crea en el servidor y se confirma por notificación firmada, no por la redirección.
• La firma se verifica sobre el cuerpo crudo y con comparación en tiempo constante.
• Un evento repetido no produce un efecto repetido (idempotencia con clave única).
• El webhook responde rápido y el trabajo pesado se hace aparte.
• Los mensajes de WhatsApp salen por la plataforma oficial, con opt-in registrado y plantillas aprobadas.
• Hay entorno de pruebas, credenciales separadas, monitoreo y una forma de apagar la integración.

En INTEA desarrollamos este tipo de conexiones dentro de nuestro servicio de APIs e integraciones y las revisamos con el criterio de seguridad que aplicamos al resto de los proyectos. Si querés evaluar un caso concreto, escribinos. Las marcas mencionadas pertenecen a sus titulares y se nombran solo como ejemplos de integración.

Preguntas frecuentes

¿Puedo integrar sin cambiar de sistema?

En general sí. La integración se agrega como una capa que se comunica con tu sistema actual por su API, por una base intermedia o por archivos programados. Lo que hay que revisar es qué puntos de entrada ofrece tu sistema. Si no tiene ninguno, se evalúan alternativas caso por caso, y conviene poder desactivar la integración sin tocar lo demás.

¿Qué pasa si el pago se aprueba pero mi sitio no se entera?

No debería depender de la redirección del navegador. El proveedor avisa a una URL tuya y reintenta si no recibe confirmación, así que el aviso termina llegando. Además conviene una tarea periódica que consulte a la API los pedidos pendientes. Con idempotencia, procesar dos veces el mismo aviso no genera entregas duplicadas.

¿Es legal usar WhatsApp para avisos automáticos?

Depende del país, del tipo de mensaje y de los datos que uses. La plataforma de WhatsApp exige el consentimiento previo de la persona y plantillas aprobadas para escribirle fuera de una conversación activa. Esto no es asesoramiento legal: para tu caso conviene revisar las políticas vigentes de la plataforma y consultar a un profesional.

¿Quién mantiene la integración cuando la API cambia?

Tiene que quedar acordado desde el inicio, porque las APIs publican versiones nuevas y retiran las viejas. Alguien debe seguir los avisos del proveedor, probar los cambios en un entorno de pruebas y actualizar el código. Puede ser tu equipo o quien la desarrolló, pero no debería quedar sin dueño.

¿Cómo se protegen las credenciales de una integración?

Se guardan en variables de entorno o en un archivo fuera del directorio público, nunca en el código ni en el repositorio. Se usan claves distintas para pruebas y producción, con los permisos mínimos que necesita la tarea, y se rotan si hubo una filtración. El secreto de los webhooks se trata igual que una contraseña.