Pagos de marketplace con Stripe Connect: tipos de cuenta, cargos y payouts (2026)

¿Cuándo necesitas Stripe Connect (y no Stripe normal)?

Stripe Connect es Stripe para plataformas y marketplaces que le pagan a vendedores terceros. La regla práctica para decidir si lo necesitas es estructural y muy simple: en el instante en que el dinero tiene que llegarle a alguien que no es tu negocio, cruzaste a territorio de Connect. Stripe normal asume que tú eres el único comercio cobrando para ti mismo —tu carrito, tu cuenta, tu liquidación—. Connect aparece cuando hay una plataforma o marketplace en medio que cobra al comprador y luego reparte ese dinero a vendedores que tienen su propio negocio.

Este es exactamente el problema que me topé construyendo Mercanto, un marketplace mayorista B2B. Los mayoristas necesitaban recibir su pago, yo necesitaba mi comisión por cada orden, y Stripe normal simplemente no puede modelar ese reparto: no hay forma de cobrarle a un comprador y mandar parte de ese dinero a la cuenta bancaria de un tercero sin Connect. En cuánto tu producto tiene “vendedores” que cobran, ya no estás integrando Stripe normal.

Connect agrega tres trabajos encima de Stripe normal. Primero, registrar vendedores y verificar su identidad (KYC). Segundo, decidir quién es el Merchant of Record en cada cargo —es decir, a nombre de quién se hace la venta y quién paga el fee de Stripe—. Tercero, mover el dinero hacia afuera, hasta la cuenta bancaria del vendedor (los payouts). Esos tres trabajos no existen cuando cobras solo para ti.

Lo que sí se mantiene idéntico es la disciplina de la fuente de verdad. La misma regla que sostiene una integración de un solo comercio aplica aquí: otorgas y liquidas solo cuando un webhook con firma verificada lo confirma, nunca confiando en un redirect del navegador. Si todavía no tienes clara esa base, empieza por cómo integrar Stripe en tu SaaS, que es Stripe para un solo comercio; Connect se construye encima de ese mismo cimiento. La referencia oficial está en la documentación de Stripe Connect.

Standard, Express o Custom: ¿qué tipo de cuenta de Connect te conviene?

La primera decisión de fondo es el tipo de cuenta conectada, y todo se reduce a un eje: control contra esfuerzo. Stripe te da tres opciones.

Standard. La cuenta conectada es una cuenta de Stripe completa, con su propio dashboard. El vendedor maneja su propio onboarding y sus propias disputas. Es el menor esfuerzo para ti como plataforma, pero la experiencia está claramente marcada por Stripe —el vendedor sabe perfectamente que está usando Stripe (piensa en Shopify)—. Funciona bien cuando tus vendedores son negocios sofisticados a los que no les molesta ver Stripe de frente.

Express. Stripe aloja el onboarding y le da al vendedor un dashboard ligero (el Express dashboard). Tú como plataforma controlas más de la experiencia que con Standard, sin tener que construir dashboards propios. Es la opción por defecto común para marketplaces.

Custom (también llamado Connect embedded components / controller configuration). La plataforma es dueña por completo de la UX, y el vendedor puede ni siquiera saber que Stripe está involucrado. Es el mayor control y, por mucho, el mayor trabajo: te toca construir prácticamente toda la superficie.

El eje, otra vez, es control contra esfuerzo. Standard es el extremo de menos esfuerzo y menos control; Custom es el extremo de más control y más trabajo; Express se queda en el punto dulce de en medio.

Mi recomendación —y aquí hablo de opinión, no de los hechos de arriba— es terminante: empieza con Express. Te da un flujo con suficiente marca propia y un KYC alojado por Stripe sin que tengas que construir dashboards ni ser dueño de la UI de disputas. Reserva Custom para cuando la experiencia del vendedor es tu producto y necesitas controlar cada pixel. Para la mayoría de los marketplaces, Express te lleva a producción más rápido y con menos superficie de bugs.

¿Cómo registras vendedores sin construir el KYC tú mismo?

La buena noticia: no construyes el flujo de identidad. Usas Connect Onboarding alojado por Stripe a través de account links, y Stripe carga todo el peso de KYC, verificación de identidad y cumplimiento. Esta es exactamente la parte que no quieres ser dueño —la regulación de identidad es un dolor enorme—, y Stripe la asume por ti.

La forma es de dos pasos. Primero creas la cuenta conectada. Luego creas un account link y rediriges al vendedor a la página de onboarding alojada de Stripe, donde captura sus datos y verifica su identidad:

// Paso 2: crea el account link y redirige al vendedor a Stripe
const link = await stripe.accountLinks.create({
  account: connectedAccountId,        // la cuenta conectada que creaste antes
  type: 'account_onboarding',         // flujo de KYC alojado por Stripe
  refresh_url: `${APP}/onboarding/refresh`, // si el link expira o se abandona
  return_url: `${APP}/onboarding/done`,     // a donde Stripe regresa al vendedor
});

return { url: link.url }; // redirige aquí; Stripe hace el KYC

Dos detalles importan. El refresh_url maneja un link expirado o abandonado —los account links no son eternos—, así que cuando el vendedor cae ahí, generas uno nuevo y lo reenvías al flujo. El return_url es a donde Stripe manda al vendedor cuando termina; pero ojo, igual que el success_url de Checkout, regresar es UX, no es prueba de que el onboarding terminó. El vendedor puede regresar a medio camino, o cerrar la pestaña justo antes del paso final.

Por eso aplica la misma disciplina de webhook-como-verdad de la integración de suscripciones: no le des a un vendedor la capacidad de recibir payouts hasta que un webhook confirme que su cuenta está completamente onboarded y con las capabilities activas. El redirect te dice “el usuario volvió”; el webhook te dice “Stripe verificó su identidad y puede recibir dinero”. Solo lo segundo es accionable. Para manejar esos eventos de forma confiable conviene entender webhooks vs polling vs API.

Direct, destination o separate charges & transfers: ¿qué tipo de cargo usar?

La segunda decisión de fondo es el tipo de cargo. Define quién es el Merchant of Record y quién paga el fee de Stripe. Hay tres.

Direct charge. El cargo se crea sobre la cuenta conectada. El vendedor es el Merchant of Record y paga el fee de Stripe; la plataforma se lleva su comisión vía application_fee_amount. Encaja cuando el vendedor es claramente el comercio de la venta (afín al patrón Standard, aunque no es obligatorio: los tipos de cuenta y los tipos de cargo son ejes independientes).

Destination charge. El cargo se crea sobre la plataforma, y los fondos se transfieren automáticamente a la cuenta conectada vía transfer_data[destination]. Aquí la plataforma es el Merchant of Record, y de nuevo se lleva su comisión vía application_fee_amount. Es el mejor encaje para la mayoría de los marketplaces.

Separate charges & transfers. La plataforma le cobra al comprador y luego emite transfers separados a una o más cuentas conectadas. Es el más flexible —te permite repartir una sola orden entre varios vendedores— y también el más manual.

Mi opción por defecto es terminante: destination charges para la mayoría de los marketplaces. Controlas la relación con el cliente y el checkout, el dinero igual aterriza con el vendedor, y tú eres el Merchant of Record con una sola llamada limpia. Solo reservas separate charges & transfers para cuando un único pago del comprador tiene que repartirse entre varios vendedores —un carrito multi-vendedor—, que es exactamente el caso de Mercanto: una orden con productos de tres mayoristas distintos necesita tres transfers. Los detalles finos de cada tipo están en cómo funcionan los cargos en la documentación oficial.

¿Cómo application_fee_amount se convierte en tu comisión? (el código)

Aquí está la mecánica del dinero. Tu comisión sobre un cargo es el application_fee_amount, y el detalle que más se malentiende: es un monto, no un porcentaje. Lo expresas en la unidad más pequeña de la moneda (centavos), y tú calculas el corte según tu propia regla de comisión.

Así se ve un destination charge con tu comisión incluida:

// Orden de $100 con 10% de comisión para la plataforma
const paymentIntent = await stripe.paymentIntents.create({
  amount: 10000,                    // $100.00 en centavos (el total al comprador)
  currency: 'usd',
  application_fee_amount: 1000,     // $10.00 = tu corte (un MONTO, no un %)
  transfer_data: {
    destination: connectedAccountId, // a donde va el resto: la cuenta del vendedor
  },
});

El reparto con números: en una orden de $100 con una comisión del 10%, pones amount = 10000 y application_fee_amount = 1000. La cuenta conectada del vendedor recibe el resto ($90.00), y tu plataforma se queda con los 1000 centavos. Stripe hace la transferencia automáticamente porque es un destination charge.

Dos reglas que no negocio. Primero: calcula el application_fee_amount del lado del servidor a partir de tu propia regla de comisión; nunca confíes en un número que venga del cliente —igual que nunca confías en un customer_id que mande el navegador en el flujo de suscripciones—. Segundo: reconcilia contra eventos de webhook con firma verificada antes de tratar un payout o una comisión como real. La mecánica del dinero se liquida de forma asíncrona; el cargo puede crearse y luego fallar, o requerir un paso adicional. La comisión es tuya cuando el evento firmado lo confirma, no cuando hiciste la llamada a la API.

¿Cómo funcionan realmente los payouts a los vendedores?

Una vez que un cargo se liquida, la parte del vendedor aterriza en el balance de su cuenta conectada, y Stripe paga ese balance a su cuenta bancaria. Stripe se encarga de los rieles del payout —tú no mueves dinero manualmente—. Esto es lo que hace que Connect valga la pena: no estás operando una tesorería ni haciendo transferencias bancarias a mano para cada vendedor.

Los payouts llegan a más de 50 países, lo cual importa de verdad para un marketplace cross-border donde tus vendedores no están todos en el mismo país. Esa cobertura es justamente la razón por la que una plataforma de Latinoamérica puede tener vendedores cobrando en distintas geografías sin construir banca local en cada una.

El tipo de cargo determina quién retiene los fondos primero. Con direct, los fondos arrancan en la cuenta conectada. Con destination, arrancan en la plataforma y se auto-transfieren. Con separate charges & transfers, tú emites el transfer explícitamente. En los tres casos, el destino final del payout es el banco del vendedor; lo que cambia es el camino.

El timing del payout y el balance de la cuenta conectada se manejan dentro de Stripe. Para Express y Custom puedes exponer esa información en tu UI; con Standard, el vendedor la ve en su propio dashboard de Stripe.

Una nota práctica de Mercanto: a los vendedores les importa el timing del payout más que casi cualquier otra cosa. “¿Dónde está mi dinero?” fue la pregunta número uno de soporte de vendedores, por mucho. Configura expectativas claras desde el onboarding y expón el estado del payout en tu interfaz —saber cuándo llega su dinero le baja la ansiedad al vendedor y le quita carga a tu equipo de soporte—.

¿Cuánto cuesta realmente Stripe Connect en 2026?

Hablemos de números reales, con la misma honestidad que aplico al costo de Stripe normal. Al momento de escribir (2026), confirma el precio actual en la página de Stripe, porque estos fees cambian y varían por región y configuración.

El stack de costos es el procesamiento estándar más los fees de Connect encima:

La conclusión honesta: tu costo real es procesamiento + por-cuenta + payout, así que modela el stack completo antes de fijar tu take rate. Tu application_fee_amount tiene que cubrir todo ese stack y todavía dejarte margen. Si pones una comisión del 10% sin contar el fee por cuenta activa y el fee de payout, tu margen real es menor de lo que crees —y en órdenes chicas, el fee fijo de $0.30 + $0.25 se come una tajada desproporcionada—.

Los payouts llegan a más de 50 países, pero los detalles cross-border y por región cambian la cuenta, así que confírmalos en la página oficial en lugar de confiar en estos números. La referencia es el pricing de Connect; trata todas estas cifras como sensibles al tiempo y verifícalas. Si estás dimensionando todo el costo de construir un MVP de SaaS tipo marketplace, este stack de fees es una parte real del presupuesto que casi nadie modela a tiempo.

Preguntas frecuentes: Stripe Connect para marketplaces

¿Standard vs Express vs Custom en una línea? Standard = el vendedor es dueño de su cuenta y dashboard de Stripe (menor esfuerzo); Express = onboarding alojado por Stripe + dashboard ligero (la opción por defecto de marketplace); Custom = tú eres dueño de toda la UX y el vendedor puede no saber que existe Stripe (más trabajo).

¿Qué tipo de cargo debería usar por defecto? Destination charges: la plataforma es Merchant of Record, los fondos se auto-transfieren al vendedor y tú tomas application_fee_amount. Usa separate charges & transfers solo para repartir un pago entre varios vendedores.

¿Tengo que construir el KYC / la verificación de identidad? No. Connect Onboarding alojado por Stripe, vía account links, maneja KYC y cumplimiento; tú rediriges al vendedor y Stripe hace la verificación de identidad. Esa carga regulatoria no la quieres ser tú.

¿Cómo cobro mi comisión? Pones application_fee_amount (un monto, no un porcentaje) en el cargo; en un destination charge, el resto se transfiere al vendedor automáticamente. Calcúlalo del lado del servidor según tu regla de comisión.

¿A cuántos países puedo pagar? Los payouts llegan a más de 50 países (confirma la cobertura actual y los fees por región en la página de pricing de Stripe).

Cierre: lanza el marketplace aburrido y correcto

El recap en una sola respiración: Express para empezar, onboarding alojado por Stripe para el KYC, destination charges para la mayoría de los marketplaces, application_fee_amount es tu comisión, y Stripe hace los payouts. Eso es el 90% de la arquitectura de pagos de un marketplace.

El webhook como fuente de verdad sigue mandando aquí, igual que en Stripe normal: confirma el onboarding y liquida las comisiones solo sobre eventos con firma verificada, nunca sobre un redirect del navegador. El vendedor está listo para recibir payouts cuando el webhook lo dice, no cuando volvió a tu return_url.

Esta es la arquitectura detrás de los payouts reales de marketplace que lancé en Mercanto —no es teoría de tutorial, es lo que aguantó en producción con dinero de verdad repartiéndose entre vendedores—. Aburrido y correcto es lo que mantiene el dinero fluyendo a las cuentas correctas mientras duermes. Si estás construyendo un marketplace y los pagos son el corazón del producto, así es como lo haría yo: así trabajo el desarrollo de SaaS, y si vas a cobrar en México conviene revisar también las pasarelas de pago en México y la base de cómo integrar Stripe en tu SaaS.