Home » Blog » Marketplace con pagos: qué hay que resolver antes de escribir código

Marketplace con pagos: qué hay que resolver antes de escribir código

Marketplace con pagos: qué hay que resolver antes de escribir código
Índice

Montar un marketplace con pagos no se parece a montar un catálogo con carrito. En cuanto la plataforma retiene dinero de terceros aparecen tres problemas que no tiene ningún otro proyecto web: hay que decidir quién custodia el importe hasta que se presta el servicio, hay que emitir facturas correctas para vendedores con figuras fiscales distintas y hay que demostrar que el profesional que aparece en el buscador es quien dice ser.

No es teoría. Es lo que nos encontramos al arrancar FotoNEX, un marketplace de fotógrafos profesionales que hoy usan más de 2.500 profesionales repartidos por toda España, desde Barcelona y Sant Cugat hasta Las Palmas, Cartagena o Rota. Este artículo cuenta qué hay que resolver antes de escribir código, qué decisiones técnicas sostienen un marketplace con pagos y cómo se organiza un proyecto de este tipo para que no se descuadre a mitad de camino.

Si buscas una visión más general del modelo de negocio antes de entrar en el detalle, tenemos una guía de marketplace para empresas y un artículo sobre por qué y cómo crear un marketplace.

Qué cambia cuando por el marketplace pasa dinero

Un marketplace de catálogo falla y alguien no encuentra un producto. Un marketplace con pagos falla y alguien se queda sin su dinero, o cobra dos veces, o emite una factura con un IVA que no le corresponde. La diferencia no es de grado.

Eso obliga a tomar tres decisiones antes de escribir código, y las tres son de producto más que de programación:

  • Quién custodia el dinero entre que el cliente paga y el profesional entrega.
  • Quién emite cada factura y con qué impuestos, que depende de cómo esté dado de alta el vendedor.
  • Qué pasa cuando una de las dos partes incumple: cancelaciones, reembolsos, disputas.

Si estas tres preguntas no tienen respuesta escrita, el desarrollo se para en la semana cuatro. Lo hemos visto lo suficiente como para preguntarlas en la primera reunión.

El pago retenido: quién tiene el dinero y hasta cuándo

El cliente paga al reservar, pero el fotógrafo no cobra hasta que entrega el material. Ese intervalo es el que sostiene la confianza de las dos caras del marketplace, y es también el que complica la integración.

La forma habitual de resolverlo es separar el cobro del reparto: la plataforma cobra la transacción completa y libera después la parte que corresponde al profesional. Stripe lo documenta como separate charges and transfers, y es el patrón que usamos en FotoNEX.

Lo que tiene que decidir el negocio, no el desarrollador

La integración es media tarde de trabajo. Lo que lleva tiempo son las reglas:

  • Cuánto tiempo puede estar retenido el importe antes de liberarse solo.
  • Qué se considera entregado y quién lo confirma.
  • Qué comisión se queda la plataforma y si cambia según el plan del vendedor.
  • Qué pasa con una cancelación a 48 horas de la sesión y qué pasa a 3 horas.

En FotoNEX el modelo de comisión cambió después del lanzamiento: hoy funciona con un plan gratuito y dos niveles de suscripción, con comisión decreciente según el plan. Ese cambio entró sin rehacer la plataforma porque la comisión estaba modelada como un parámetro, no repartida por el código.

La facturación automática, que es donde se ahoga un marketplace pequeño

Aquí es donde casi todos los proyectos se descubren cortos. Tres fotógrafos pueden cobrar lo mismo por el mismo servicio y generar tres facturas distintas, porque uno es autónomo, otro tiene sociedad y el tercero es socio de una cooperativa. Cada figura tiene su tratamiento de IVA y su retención de IRPF.

Si eso se resuelve a mano, el marketplace funciona bien hasta las cincuenta transacciones al mes y a partir de ahí alguien se pasa los viernes cuadrando facturas. En FotoNEX la facturación se automatizó contra Holded, con las tres casuísticas modeladas desde el diseño.

La regla práctica: el tipo fiscal del vendedor es un dato del perfil, se pide en el alta y se verifica, y la plantilla de factura se elige a partir de ese dato. Dejarlo para más adelante significa migrar perfiles ya creados, que es el trabajo más caro de todos.

Confianza: verificación, reseñas y fraude

En un marketplace de servicios el producto no se ve antes de comprarlo. Se compra un porfolio y una promesa. Lo que sustituye a ver el producto son tres mecanismos:

  • Insignias con verificación documental. El profesional sube titulación o certificados y administración los revisa antes de mostrar la insignia. Sin revisión humana, la insignia no vale nada.
  • Reseñas verificadas. Solo puede opinar quien ha pagado y ha recibido el material. Es la única forma de que la media signifique algo.
  • Prevención de fraude. Doble factor en las transacciones de mayor importe y procesamiento de pagos conforme a PCI DSS, que en la práctica se cubre delegando el dato de tarjeta en la pasarela y no tocándolo nunca.

Los tres mecanismos tienen coste de operación, no solo de desarrollo: alguien revisa documentos todas las semanas. Conviene contarlo desde el principio, porque cambia el dimensionamiento del equipo que va a mantener la plataforma.

Las decisiones técnicas de un marketplace con pagos

Con las reglas de negocio cerradas, la arquitectura casi se elige sola. Estas son las decisiones que tomamos en FotoNEX y el motivo de cada una:

PiezaElecciónPor qué
FrontendNext.jsMiles de páginas de perfiles y categorías. El renderizado en servidor y el SEO son el canal de adquisición, no un detalle de rendimiento.
Backend y panelPayloadCMSReúne contenidos y lógica de servidor, y aporta el panel donde se moderan perfiles, insignias y reservas sin construirlo desde cero.
Base de datosPostgreSQLReservas, pagos y facturación necesitan integridad transaccional. No es sitio para una inconsistencia entre lo cobrado y lo reservado.
PagosStripeCobro con tarjeta y retención del importe hasta la entrega, sin custodiar dinero con desarrollo propio.
FacturaciónHoldedAutomatiza las tres casuísticas fiscales y evita el trabajo manual que ahoga a los marketplaces pequeños.

Un apunte sobre el calendario, que suele subestimarse: disponibilidad en tiempo real, bloqueo de fechas, tiempos mínimos de aviso y sincronización en los dos sentidos con Google Calendar, Apple y Outlook. Es tan caro de construir como la pasarela de pago y casi nadie lo presupuesta.

La infraestructura también entra en el presupuesto

El acceso se resolvió con OAuth 2.0 para entrar con Google y Apple, y doble factor en las transacciones de mayor importe. El despliegue va con integración continua sobre GitHub Actions y contenedores, con objetivos de respuesta por debajo de 200 ms y capacidad para más de 5.000 usuarios simultáneos.

Fijar esos números al principio cambia decisiones de arquitectura que luego no se pueden deshacer barato. Un marketplace que tiene que aguantar picos de tráfico en temporada de bodas no se diseña igual que uno que crece plano todo el año.

Si estás comparando cifras, en cuánto cuesta crear un marketplace desglosamos las partidas con rangos orientativos.

Cómo se organiza un proyecto así

FotoNEX llegó con un documento de requisitos funcionales de más de veinte páginas: los recorridos de las dos caras, el sistema de insignias, la lógica de facturación, los filtros y la política de cancelación. Aun así, el propio documento reconocía que la implementación tendría que ajustarse según el criterio del equipo de desarrollo. Esa frase es la que separa un proyecto que sale de uno que se atasca.

El desarrollo se dividió en cuatro hitos ligados a entregables verificables, y cada hito se cobró contra entrega aceptada, no contra tiempo consumido. El plazo estimado fue de 14 semanas, con sprints de dos semanas y un equipo de project manager, frontend, backend, QA, DevOps, dos diseñadores senior y un perfil de marketing.

La fase 1 no fue de código: definición, marca y diseño. FotoNEX no tenía identidad visual, así que el mismo equipo creó logo, tono, guía de estilo y librería de componentes, y a partir de ahí los wireframes y el diseño de alta fidelidad. Construir marca y producto a la vez es más lento al principio y mucho más rápido después.

El lanzamiento no es el final del proyecto

Un marketplace vacío no sirve de nada, así que la última fase incluyó captación para las dos caras a la vez: campañas en redes dirigidas a fotógrafos por un lado y a clientes por otro, una estrategia de contenidos con blog optimizado para buscadores y la analítica montada para medir captación y conversión. El foco inicial se concentró en las ciudades españolas con más demanda de servicios fotográficos.

Y el MVP no se cerró como producto terminado. Quedaron contempladas desde el diseño dos evoluciones: campañas de promoción de pago para que los fotógrafos ganen visibilidad dentro del marketplace, con coste por clic, por impresión o por periodo, y respuestas automáticas con IA para las consultas estándar de la mensajería.

Una cosa más sobre la propiedad: al cerrar el proyecto, el código fuente y los derechos pasaron a FotoNEX, sin licencias que aten al proveedor, con seis meses de garantía sobre errores no detectados en pruebas. Si tu contrato no dice esto, revísalo antes de firmar.

Puedes ver el proceso completo, con las cuatro fases y lo que se entregó en cada una, en el caso de éxito de FotoNEX.

Por dónde empezar

Si tienes un marketplace con pagos en la cabeza, el primer trabajo no es buscar desarrollador. Es contestar por escrito quién custodia el dinero, quién factura y qué pasa cuando alguien incumple. Con eso resuelto, el desarrollo es caro pero predecible. Sin eso, es imposible de presupuestar.

El segundo trabajo es elegir a quién lo construye. Un buen equipo de desarrollo web no sirve automáticamente: hace falta experiencia real en marketplaces de dos caras y en pagos con retención de fondos. En Yeeply no desarrollamos con equipo propio; seleccionamos entre más de 150 empresas tecnológicas certificadas la que encaja por perfil técnico y experiencia previa, presentamos varias propuestas y supervisamos el desarrollo hasta la entrega. Puedes ver otros proyectos que hemos puesto en marcha.

Cuéntanos qué quieres construir: haz clic en Solicitar presupuesto, arriba a la derecha, o escribe a sales@yeeply.com. Te responderemos con propuestas de empresas que ya han hecho algo parecido.

Álvaro Montes Serrador
Álvaro Montes Serrador
Gerente de Negocio en Quental

Es un profesional en el campo de la informática y la ingeniería de sistemas, con una sólida carrera en la gestión de negocios y relaciones dentro del sector tecnológico. Actualmente, ocupa el cargo de Gerente de Negocio en Quental, donde su enfoque está en gestionar y desarrollar proyectos innovadores que contribuyan al crecimiento y consolidación de la empresa.

Etiquetas