La guía del fundador para integrar pasarela de pago en tu app fintech

Toda app fintech se topa con el mismo muro: puedes diseñar el onboarding más fluido del mercado, pero en cuanto alguien intenta pagar, dependes de la infraestructura de otra empresa. Ahí entra integrar pasarela de pago, el paso que define tu alcance PCI, tus comisiones y la rapidez real con la que lanzas. Si delimitas mal la integración, te pasarás semanas rehaciendo el checkout en lugar de lanzar funciones que de verdad importan. Esta guía repasa qué hace una pasarela, en qué se diferencia de un procesador y qué cambia entre una clave de pruebas y una de producción.

Una pasarela de pago es la capa que recoge los datos de pago en el checkout, los cifra y envía la solicitud de autorización a quien mueve el dinero después. Piensa en ella como el cajero del mostrador, no como la bóveda: captura el número de tarjeta o el token de la wallet y devuelve una respuesta de aprobado, rechazado o 'necesita un paso más' casi en tiempo real. Técnicamente, una pasarela es una API, normalmente combinada con campos de checkout alojados que insertas en tu app. Tu app llama a la pasarela, la pasarela cifra y tokeniza los datos, y la autorización viaja por los rieles de la red de tarjetas hasta el banco del titular. Si está bien montada, los datos de la tarjeta no deberían tocar tus propios servidores, algo que importa cuando lleguemos al alcance PCI más adelante en esta guía. Para ver el resto de la pila alrededor de los pagos, consulta nuestra guía de desarrollo de software fintech.

Los fundadores usan 'pasarela' y 'procesador' como sinónimos, y el sector no ayuda a aclararlo porque la mayoría de proveedores difuminan la línea a propósito. La distinción sigue importando cuando estás investigando un rechazo o leyendo un contrato. La pasarela captura y cifra los datos de pago y enruta la solicitud de autorización. Es la puerta técnica de entrada: API, campos alojados, tokenización. El procesador es quien mueve de verdad la transacción por las redes de tarjetas (Visa, Mastercard y el resto) hasta los bancos emisor y adquirente, y gestiona la liquidación que deposita el dinero en tu cuenta unos días después. Hoy, proveedores como Stripe, Adyen y Braintree empaquetan pasarela, procesador y adquirencia en un solo contrato y una sola clave de API, por eso la mayoría de fundadores nunca piensan en la distinción hasta que algo falla. ¿Construyendo un exchange cripto en su lugar? Los rieles son distintos otra vez. Mira nuestra guía sobre cómo construir una app de exchange de criptomonedas como Coinbase.

La mayoría de fundadores fintech eligen Stripe por defecto, y para una primera versión es un instinto razonable: documentación sólida, un sandbox que no te complica la vida y suficientes métodos de pago para cubrir un lanzamiento en Estados Unidos o la Unión Europea. Aun así, esa opción por defecto merece una segunda mirada en cuanto tus necesidades se vuelven específicas. ¿Vas a escalar a mercados internacionales pronto, con preferencias de pago locales fuertes como iDEAL, Pix o UPI? Adyen, o un proveedor igual de completo, suele ahorrarte tener que añadir rieles locales después. Un marketplace, un vertical de mayor riesgo o cualquier cosa cercana a cripto implican un proceso de suscripción más largo sin importar la pasarela que elijas, así que reserva tiempo para eso. Sopesa cuatro cosas antes de firmar: los países y las divisas que necesitas desde el primer día, los métodos de pago que esperan tus usuarios, la experiencia de desarrollo para tu stack y cuánto se mantiene transparente el precio más allá de la tarifa de la portada. Ese último punto le cuesta a los fundadores más de lo que esperan. Más sobre esto en la sección de comisiones más abajo.

Integrar pasarela de pago suele seguir la misma forma sin importar qué proveedor elijas. Empiezas en un sandbox, pides claves de API de prueba y construyes contra los números de tarjeta ficticios que la pasarela publica para esto: uno que siempre rechaza, otro que siempre exige autenticación adicional. La decisión central es dónde tocan tus servidores los datos de la tarjeta, si es que lo hacen. Con campos alojados (Stripe Elements, el Drop-in UI de Braintree), el cliente escribe el número de tarjeta en un formulario que la pasarela renderiza dentro de un iframe en tu página. Esos datos van directos del navegador a la pasarela, y tu servidor solo recibe un token de vuelta. Si en cambio construyes tu propio formulario de tarjeta, manejas datos de tarjeta en crudo tú mismo, aunque sea brevemente, y eso cambia tu panorama de cumplimiento. La tokenización es lo que hace posible todo esto: la pasarela cambia el número real por un token que no sirve de nada a quien lo robe en otro lugar. Guardas el token y le cobras al cliente otra vez el mes que viene sin volver a tocar el número real.

Aquí está la recompensa de cumplimiento por construirlo así: los campos alojados y la tokenización pueden reducir tu alcance PCI DSS de forma drástica, muchas veces hasta el nivel de autoevaluación más simple, SAQ A, en lugar del mucho más pesado SAQ D. Ese es un beneficio real, que vale la pena diseñar desde el primer día. Sin embargo, eso no equivale a estar totalmente en cumplimiento PCI de forma automática, y cualquier proveedor que asegure que la tokenización por sí sola te lleva hasta ahí se está saltando pasos. SAQ A sigue significando dar fe de prácticas reales: que los datos de tarjeta nunca toquen tus propios servidores ni tus registros, un entorno parcheado y con acceso controlado, y una integración que se comporta como asumes. Una configuración de 'campo alojado' puede caer en silencio en una captura insegura durante un estado de error o un despliegue apresurado, y nadie se da cuenta hasta que llega una auditoría. Si tocas datos de tarjeta en crudo en tu propio servidor, aunque sea brevemente, tu alcance salta a un nivel SAQ más pesado. Para la lista completa de requisitos, consulta nuestro checklist de cumplimiento PCI DSS para startups.

Toda pasarela te da un sandbox: claves de prueba y números de tarjeta ficticios que simulan aprobaciones, rechazos y casos límite como fondos insuficientes o una tarjeta caducada. Úsalos todos, no solo el camino feliz. Pasar a producción suele implicar más que cambiar una clave de prueba por una real. La mayoría de las pasarelas exigen antes un proceso de suscripción, a veces llamado KYB (know your business): documentación, datos bancarios y, en ocasiones, una revisión de tu web. Esto puede tardar desde el mismo día hasta un par de semanas, así que empiézalo antes de tu fecha de lanzamiento objetivo. Verifica varias cosas antes de darle al interruptor: que los webhooks se disparen en cada evento que necesitas, que la lógica de reintentos maneje una entrega duplicada sin cobrarle dos veces a nadie y, si atiendes a clientes de la Unión Europea, que el checkout complete la autenticación reforzada del cliente (SCA) bajo PSD2 en lugar de aprovecharse de la aplicación más laxa del sandbox.

La tarifa que se anuncia nunca es toda la historia. La tarifa estándar de Stripe en Estados Unidos, 2.9% más $0.30 por transacción exitosa, es el número que todo el mundo cita, y es correcto como punto de partida. Lo que agarra desprevenidos a los fundadores es todo lo que se suma encima: la conversión de divisas que añade entre un 1 y un 2% extra en tarjetas internacionales, las comisiones por contracargo que suelen rondar entre $15 y $25 por disputa, se gane o se pierda, y los tiempos de pago que dejan un par de días de hueco en el flujo de caja. Hay algunos costes fáciles de pasar por alto hasta que llega la primera factura. Algunas pasarelas cobran aparte por las herramientas antifraude. Reembolsar a un cliente no siempre devuelve la comisión de procesamiento, así que un modelo de negocio con muchos reembolsos puede erosionar en silencio un margen que nadie presupuestó. Las comisiones de la pasarela tienen sentido en contexto: mover dinero de forma segura cuesta infraestructura real de mantener. Presupuesta la pila completa al calcular lo que cuesta construir y mantener una app fintech más allá del desarrollo inicial.

Antes de apuntar tráfico real a una pasarela en producción, repasa esta lista:

• Confirma que tu pasarela cubre lo que necesitas desde el primer día. Los países, las divisas y los métodos de pago son más difíciles de añadir después.
• Prueba cada camino de fallo en el sandbox, no solo las aprobaciones: una tarjeta rechazada, un timeout, un webhook duplicado.
• Empieza el proceso de suscripción o KYB pronto. Casi nunca es rápido, y suele ser el verdadero cuello de botella entre el código terminado y el lanzamiento.
• Confirma que tu alcance PCI coincide con tu integración real (campos alojados frente a cualquier cosa que toque tus propios servidores) y documéntalo.
• Configura el manejo de webhooks para cada evento del que dependes, con lógica de reintentos que sobreviva a una entrega duplicada.
• Mapea toda tu pila de comisiones, no solo la tarifa anunciada.
• Define quién es responsable de las disputas en cuanto estés en producción. Alguien tiene que serlo, y 'quien se dé cuenta primero' no es un plan.

Hazlo bien y la pasarela se convierte en infraestructura de fondo en la que rara vez vuelves a pensar.