Integración Mercado Pago en Chile: API, Checkout, suscripciones y marketplace

Mercado Pago expone dos caminos principales para integrar pagos en un e-commerce chileno: Checkout Pro (botón redirigido a la pasarela de Mercado Pago, donde el comprador completa el pago y vuelve a tu sitio) y Checkout API (también llamado Checkout Transparente, donde la tarjeta se ingresa directamente en tu sitio bajo controles PCI-DSS y la transacción se procesa vía API REST sin redirección). Para un e-commerce chileno custom el flujo típico es: (1) el frontend tokeniza los datos de tarjeta usando el SDK oficial JS de Mercado Pago (esto evita que tu servidor toque PAN directamente y reduce el alcance PCI); (2) tu backend recibe el token y crea un payment vía POST /v1/payments con monto, descripción, datos del comprador y metadata propia (orderId, items, customerId); (3) Mercado Pago responde con un status (approved, pending, in_process, rejected) que tú interpretas para decidir si confirmas el pedido, lo dejas en espera o lo rechazas; (4) en paralelo configuramos webhooks (notifications de tipo payment y merchant_order) que notifican cualquier cambio de estado posterior (capturas, autorizaciones, contracargos). En Blackend construimos esta capa con cola persistente para webhooks, idempotencia por payment_id, capa de reconciliación contra Defontana o el ERP, y dashboard de salud que muestra approval rate, declines por motivo y latencia por endpoint. El alcance se cierra después de un discovery donde mapeamos métodos de pago habilitados (tarjeta crédito, débito, RedCompra, transferencia, tarjetas extranjeras), reglas antifraude y necesidad de 3DS.

En el mercado chileno, una integración custom con Mercado Pago parte desde $3.500.000 CLP y llega hasta $14.000.000 CLP según alcance. El rango se mueve por: (1) tipo de checkout: Checkout Pro embebido es la opción más barata (botón + retorno + webhook), Checkout API custom es más caro porque requiere tokenización en frontend, manejo de errores granular y validaciones PCI-DSS; (2) productos adicionales: integrar suscripciones recurrentes (Preapproval API), split-pay para marketplace (Payments Split / Marketplace), QR Pago presencial, Cards Vault para guardar medios de pago y Refunds API agregan complejidad y tiempo; (3) volumen: un sitio con 100 pagos/mes es distinto a uno con 50.000/mes en términos de paralelismo, idempotencia, reintentos y observabilidad; (4) conciliación: si necesitas que cada pago aprobado dispare emisión de boleta o factura electrónica (vía SII directo, OpenFactura, Haulmer, Defontana), el costo sube por la coordinación contable y por validaciones tributarias; (5) cumplimiento: pen testing, segmentación de red, vault de credenciales y revisión PCI-DSS suben el costo en clientes regulados. A esto se suma un mantenimiento mensual entre $300.000 y $1.200.000 CLP que cubre monitoreo de webhooks, alertas, adaptación a cambios en la API de Mercado Pago y bolsa de horas evolutivas. Una integración marketplace con split-pay multi-vendor y conciliación SII se ubica entre $9.000.000 y $22.000.000 CLP por la complejidad operativa.

Checkout Pro y Checkout API son dos productos distintos de Mercado Pago que resuelven el mismo problema (cobrar online) con enfoques opuestos. Checkout Pro es el flujo redirigido: tu sitio crea una preference vía API, redirige al usuario a una URL de Mercado Pago donde se completa el pago en sus servidores con su UI, y al finalizar el comprador vuelve a tu sitio con un parámetro que indica el estado del pago. Ventajas: rápido de implementar (un par de días si tu carrito ya está), Mercado Pago asume todo el riesgo PCI-DSS porque la tarjeta nunca pasa por tu servidor, y la pasarela se actualiza sola con nuevos métodos de pago. Desventajas: experiencia rompe el flujo (el comprador sale de tu marca), conversión cae respecto de un checkout custom, y los estilos no son personalizables más allá del logo. Checkout API (Checkout Transparente) es el opuesto: la tarjeta se tokeniza directo en tu frontend con el SDK oficial JS, tu backend procesa el payment vía API REST y el comprador nunca sale de tu sitio. Ventajas: conversión más alta (típicamente 5-15% mejor que Checkout Pro), control total del UX, posibilidad de A/B testear el formulario, y manejo granular de errores por tipo de decline. Desventajas: el alcance PCI-DSS aumenta (aunque la tokenización lo limita), el tiempo de integración es mayor (3-5 semanas para un proyecto típico) y la responsabilidad técnica también: si tu form falla, tu venta falla. En general recomendamos Checkout Pro para MVPs y emprendimientos chicos, y Checkout API para empresas con volumen donde 5% más de conversión justifica el costo de desarrollo y operación.

Sí. Mercado Pago tiene Preapproval API (también llamado Suscripciones) que permite cobrar un monto recurrente a una tarjeta autorizada por el cliente, sin necesidad de pedirle que vuelva a digitar datos cada mes. Funciona bien para SaaS B2B chilenos, membresías de contenido, gimnasios, suscripciones de productos físicos (cajas mensuales, café, vino) y servicios profesionales con cobro mensual. El flujo es: (1) el cliente autoriza una preapproval indicando monto, frecuencia (mensual, semanal, anual) y plan; (2) Mercado Pago tokeniza la tarjeta y devuelve un preapproval_id que tú guardas asociado al cliente; (3) en cada ciclo Mercado Pago genera automáticamente un payment con ese token y notifica el resultado vía webhook (authorized_payment). Tu backend recibe el evento, actualiza el estado de la suscripción y dispara las consecuencias del negocio (activar el acceso, mantener el servicio, suspender por mora). En implementaciones serias hay que cuidar: dunning management (qué hacer cuando una tarjeta falla por fondos insuficientes o vencimiento, reintentos progresivos antes de cancelar), upgrade/downgrade de plan a mitad de ciclo con prorrateo, cancelación con periodo de gracia, pausas temporales, recuperación de tarjetas vencidas (Card Updater) y emisión automática de boleta electrónica por cada cobro exitoso para cumplir SII. En Blackend implementamos esta lógica con state machine explícita por suscripción, cola para reintentos y dashboard de churn técnico vs voluntario.

El split-pay (también llamado pagos divididos o Marketplace Payments) es la funcionalidad que permite que un solo pago del comprador se divida automáticamente entre varios receptores: el marketplace que cobra una comisión y uno o varios vendedores que reciben el neto. Mercado Pago lo soporta vía el campo application_fee dentro de la creación del payment, complementado con OAuth: cada vendedor del marketplace conecta su cuenta de Mercado Pago a tu plataforma vía flujo OAuth, autorizando a tu marketplace a operar pagos a su nombre y a retener una comisión. Cuando un comprador paga en tu sitio, tú creas el payment con el access_token del vendedor (no el tuyo), agregas application_fee con el monto exacto de tu comisión y Mercado Pago se encarga de transferir el neto al vendedor y la comisión a tu marketplace en cuentas separadas. Esto es crítico para evitar problemas regulatorios y tributarios: el marketplace no es agente recaudador, cada vendedor declara sus ingresos en su propio RUT y la trazabilidad queda clara. En implementaciones marketplace típicas hay que cuidar además: onboarding KYC de vendedores (validación RUT, datos bancarios, contrato), manejo de devoluciones que afectan el split (refund proporcional a marketplace y vendedor), retención de fondos en disputa, conciliación contable por vendedor para emisión de boleta o factura por comisión, y dashboard operacional para que el equipo del marketplace vea volumen, comisión generada y vendedores activos. Es uno de los proyectos más complejos del cluster, pero también el de mayor valor.

Los webhooks (notifications IPN) de Mercado Pago son el corazón de cualquier integración seria, y al mismo tiempo el punto de fallo más común si no se manejan bien. Mercado Pago notifica cambios de estado de payments, merchant_orders, subscriptions y refunds vía POST a una URL que tú configuras. Hay tres problemas clásicos: (1) duplicación: Mercado Pago puede enviar el mismo evento varias veces (especialmente si tu endpoint demora en responder 200), por lo que toda la lógica debe ser idempotente: validar contra payment_id que el evento no se haya procesado antes; (2) pérdida: si tu servidor está caído cuando llega el webhook, Mercado Pago reintenta pero no infinitamente, así que conviene tener un job de reconciliación periódico que consulte vía API el estado de payments que tu sistema cree pendientes para no quedar desfasado; (3) latencia: webhooks pueden demorar entre segundos y minutos en llegar, por lo que la UX del comprador no debe depender del webhook sino del retorno síncrono del API call. En Blackend resolvemos esto con: cola persistente (SQS, RabbitMQ o Redis Streams) que recibe el webhook, responde 200 inmediato a Mercado Pago y procesa el evento en background; deduplicación por payment_id + status + last_modified; reintentos con back-off exponencial; dead letter queue con alerta para eventos irrecuperables; job de reconciliación cada 15 minutos que consulta payments pendientes y cierra los desfases; y dashboard de salud con latencia de webhook, tasa de duplicados y eventos en DLQ. Sin esta capa, una integración con MP funciona hasta el primer pico de tráfico o caída de red.

Sí, y es uno de los patrones más comunes en e-commerce chilenos serios. Cada pasarela tiene fortalezas distintas: Webpay (Transbank) es la pasarela bancaria oficial de Chile y captura el segmento que confía solo en el sello Transbank, además de procesar débito y RedCompra con menor fricción; Mercado Pago lidera en métodos alternativos (tarjeta extranjera, billetera Mercado Pago, cuotas sin interés con campañas), y tiene fuerte penetración en el segmento más joven y en compradores que ya tienen saldo en MP; Khipu y Fintoc cubren transferencia bancaria sin tarjeta, ideal para tickets altos donde el costo de la tarjeta es prohibitivo. Una buena estrategia combina las tres: muestra al comprador las opciones según contexto (monto, tipo de cliente, dispositivo, historial) y deja que él elija. La implementación técnica requiere abstraer una capa de payment provider en tu backend, donde cada pasarela es un adapter con el mismo contrato (crear payment, consultar estado, hacer refund, recibir webhook), y la lógica de negocio del e-commerce no sabe qué pasarela se está usando. Esto te da flexibilidad para A/B testear pasarelas, sumar nuevas (PayPal para extranjeros, Klap para retail) sin tocar el carrito, y conciliar todos los pagos contra una sola tabla unificada en tu base de datos. En Blackend este patrón lo implementamos en casi todos los proyectos serios de e-commerce; el costo incremental por agregar una segunda pasarela suele ser entre 30-50% del costo de la primera porque la capa de abstracción ya está hecha.

Una integración custom con Mercado Pago tarda entre 3 y 16 semanas según alcance. Los rangos típicos: (1) Checkout Pro embebido en un e-commerce que ya funciona: 2-4 semanas (incluye discovery, configuración de credenciales, integración del botón, manejo de retorno, webhook básico, pruebas y QA). (2) Checkout API custom con tokenización frontend, manejo granular de declines y emisión automática de boleta SII: 6-10 semanas (incluye diseño del formulario, integración con SDK JS, capa anti-corruption en backend, cola de webhooks, dashboard de pagos y conexión con OpenFactura o Haulmer). (3) Suscripciones recurrentes con dunning management y state machine de suscripción: 4-8 semanas adicionales sobre cualquier checkout. (4) Marketplace con split-pay, OAuth de vendedores, KYC y conciliación por vendedor: 10-16 semanas porque es prácticamente un producto en sí mismo. Los factores que más impactan el plazo son: claridad del alcance (un cliente que sabe qué métodos quiere y qué casos borde acepta avanza el doble de rápido), disponibilidad del equipo del cliente para validar (UAT toma 2-3 iteraciones en proyectos serios), dependencias con sistemas legacy (si hay que conectar con ERP o sistema interno, sumar tiempo), y aprobaciones internas de seguridad y compliance. Lo crítico no es solo entregar la integración sino entregarla con monitoreo, runbook de incidentes, documentación y soporte; saltarse esa fase reduce el plazo pero genera una integración que se cae en producción la primera semana.