Pasarelas de pago para startups fintech: guía técnica

Para una startup fintech, la pasarela de pago no es un detalle de infraestructura: es una de las pocas piezas que toca al mismo tiempo el margen, la experiencia del usuario y el riesgo. Una decisión apresurada en las primeras semanas se paga durante años, tanto en costos por transacción como en la dependencia técnica de un solo proveedor.

La buena noticia es que la decisión se puede tomar con criterios concretos. La mala es que casi ningún comparador público los explica, porque el modelo de negocio de las pasarelas depende de que la integración sea fácil de empezar y difícil de abandonar.

Qué mirar antes de firmar con una pasarela

Antes de escribir la primera línea de código, conviene evaluar cada proveedor contra una lista corta y medible.

• Costo real por transacción. En Argentina y buena parte de LATAM, las pasarelas de tarjeta suelen ubicarse entre el 3% y el 6% más IVA por operación, con costos fijos adicionales y plazos de acreditación que van de 24 horas a varios días. Las internacionales tipo Stripe rondan un 2,9% más un fijo por transacción. El número de la home nunca es el número final: hay que sumar contracargos, retiros y conversión de moneda.
• Tasa de aprobación. Dos pasarelas con la misma comisión pueden diferir varios puntos en cuántos pagos aprueban. Cada punto perdido es facturación que no entra, así que este dato pesa más que la comisión nominal.
• Modelo de liquidación y conciliación. Cómo y cuándo se acredita el dinero, qué reportes entrega y si esos reportes cuadran contra su base de datos sin trabajo manual.
• PCI DSS y manejo de datos sensibles. Lo ideal es que la pasarela tokenice la tarjeta y su sistema nunca almacene el número completo. Eso mantiene a la empresa en el nivel de cumplimiento más liviano (SAQ A) en lugar de asumir toda la carga de auditoría.
• Lock-in. Qué tan atada queda la lógica de cobro a ese proveedor. Si migrar de pasarela implica reescribir medio backend, ya se perdió poder de negociación.

Por qué multi-pasarela deja de ser opcional

Cuando el volumen crece, depender de una sola pasarela es un riesgo de negocio, no solo técnico. Si ese proveedor tiene una caída, sufre una degradación o rechaza una franja de tarjetas, la facturación se detiene por completo.

Una arquitectura multi-pasarela resuelve dos problemas a la vez:

1. Failover. Si la pasarela primaria rechaza o no responde, el cobro se reintenta contra una secundaria de forma transparente para el usuario.
2. Enrutamiento inteligente. Se puede dirigir cada pago hacia la pasarela que mejor aprueba ese tipo de tarjeta o emisor, o hacia la de menor costo para ese medio. En la práctica, enrutar por emisor y sumar un segundo proveedor de respaldo suele recuperar entre 2 y 5 puntos de tasa de aprobación.

El costo de construir esto es real, pero se amortiza rápido: en una fintech que procesa volumen, recuperar tres puntos de aprobación equivale a un aumento directo de ingresos sin gastar un peso más en adquisición.

Reintentos inteligentes y conciliación: donde se gana o se pierde plata

Un rechazo no es igual a otro. Hay rechazos "duros" (tarjeta robada, cuenta cerrada) donde reintentar no tiene sentido, y rechazos "blandos" (fondos insuficientes momentáneos, límite temporal) donde un reintento en el momento adecuado recupera el cobro. Reintentar a ciegas quema costos y puede disparar bloqueos antifraude; reintentar leyendo el código de respuesta recupera ingresos que la mayoría de los productos enlatados dejan sobre la mesa.

La conciliación es la otra mitad silenciosa. Cada pago debe cruzarse contra lo que la pasarela efectivamente liquidó, contemplando comisiones, contracargos y reversas. Cuando esto se hace a mano en una planilla, se rompe apenas el volumen sube. Cuando se automatiza con webhooks idempotentes (es decir, que procesan el mismo evento una sola vez aunque llegue duplicado), el equipo financiero deja de perseguir descuadres.

Split de pagos y modelos de marketplace

Si el producto reparte dinero entre varias partes (un marketplace, una plataforma de servicios, un modelo de comisiones), aparece el requisito de split de pagos: cobrar una vez y liquidar automáticamente a cada beneficiario, reteniendo la comisión de la plataforma. No todas las pasarelas lo soportan de forma nativa, y las que lo hacen imponen su propia lógica. Diseñar esta capa por encima de las pasarelas, y no atada a una sola, es lo que permite cambiar de proveedor sin rehacer el modelo de negocio.

Cuándo la integración a medida gana a lo enlatado

Un botón de pago prearmado es la opción correcta para validar una idea la primera semana. Deja de serlo cuando el negocio escala y la lógica de cobro se vuelve una ventaja competitiva.

La integración a medida gana cuando la empresa necesita orquestar varias pasarelas, aplicar reglas propias de reintento y enrutamiento, conciliar de forma automática, soportar split de pagos y, sobre todo, no quedar rehén de un proveedor. Una integración multi-pasarela con conciliación y webhooks bien resueltos suele tomar entre 4 y 10 semanas según el alcance, y esa inversión se recupera en márgenes y en resiliencia operativa.

En PairProgramming abordamos la integración de pasarelas de pago como una capa de orquestación propia del producto, no como un plugin: la empresa mantiene el control de sus reglas de cobro y puede sumar o cambiar proveedores sin reescribir su backend. Ese mismo criterio de datos y automatización es el que aplicamos en proyectos de vertical financiero como el portal de cotización de seguros miseguro.com.ar.

La pasarela más barata del comparador rara vez es la más rentable a doce meses. Lo que mueve la aguja es la arquitectura alrededor de ella.

Escrito por Esteban Aleart, founder & lead engineer en PairProgramming.