Cómo construir un marketplace de productos digitales con Drupal

La primera vez que monté un marketplace de plantillas para arquitectos en Drupal, el cliente me pidió algo que parecía sencillo: "que el vendedor cobre, nosotros nos quedemos un 15% y el comprador descargue el archivo solo tres veces". Tres requisitos. Tres semanas de arquitectura. Y al final, la decisión que más impacto tuvo no fue ninguna línea de código, sino elegir bien los módulos antes de empezar.

Esa es la trampa de cómo construir un marketplace de productos digitales con Drupal: el CMS te da casi todo lo que necesitas, pero combinar las piezas mal te puede dejar atrapado en una arquitectura que no escala. Aquí desgloso lo que funciona en proyectos reales, los módulos que merecen el espacio en tu composer.json y las decisiones técnicas que te ahorran reescrituras dolorosas.

Por qué Drupal sigue ganando cuando el modelo se complica

Si tu producto es "catálogo, carrito, gracias por su compra", probablemente Shopify te resuelva la vida. Drupal entra en juego cuando el modelo de negocio tiene aristas: varios vendedores, licencias con caducidad, descargas limitadas, perfiles fiscales diferentes, regalías por uso. Ahí WooCommerce empieza a ahogarse en plugins y Shopify te cobra una fortuna por funcionalidad que se queda corta.

Drupal Commerce está pensado desde el día uno para modelar entidades complejas. Una variación de producto puede tener su propio set de campos, su lógica de precio, su tipo de licencia y su archivo asociado. Sin hacks. Sin plugins encadenados que se pisan entre sí.

Lo que ganas en la práctica

• Tipos de contenido a medida: cada categoría de producto digital puede tener sus propios campos. Una plantilla de Figma no necesita los mismos atributos que un plugin de WordPress o un curso en vídeo.
• Permisos granulares de serie: los roles de Drupal son tan finos como necesites. No vas a depender de un plugin de membresías que rompa en cada actualización.
• Headless cuando toca: con JSON:API expuesto, el frontend puede ser Next.js o Nuxt sin tocar el backend. Útil cuando el equipo de producto pide experiencias muy cuidadas.
• RGPD sin sobresaltos: el equipo de seguridad de Drupal saca parches con disciplina militar, y eso en un proyecto que maneja datos fiscales de vendedores europeos vale oro.

La arquitectura, capa por capa

Un marketplace digital bien diseñado se sostiene sobre cuatro capas que conviene pensar por separado antes de tocar nada.

Catálogo y modelado de producto

Cada artículo se modela como un Commerce Product con variaciones. Una variación puede ser "licencia personal" y otra "licencia comercial extendida", con precios distintos y archivos distintos. Si el marketplace es multivendedor, Commerce Marketplace (o Multivendor Marketplace en versiones recientes) añade la noción de "tienda por vendedor" sin que tengas que inventarla.

Los campos que rara vez sobran en un producto digital: descripción larga con Paragraphs para bloques modulares, galería de capturas, archivo descargable (referenciado, nunca subido al campo del producto directamente), taxonomía de categoría, tipo de licencia, versión, changelog y precio. Si vas a vender bundles, Commerce Product Bundle te ahorra un dolor de cabeza.

Transacciones y dinero

Drupal Commerce lleva el checkout, los pedidos y los impuestos. Para producto digital, hay tres módulos que no negocio:

• Commerce File: genera enlaces firmados con expiración y cuenta las descargas. Tres descargas, siete días, lo configuras tú.
• Commerce License: si vendes software o plantillas con actualizaciones, esto te da licencias con caducidad, renovación automática y revocación.
• Commerce Tax con zonas fiscales por país: el IVA en la UE se aplica según el país del comprador, no del vendedor. Configúralo desde el principio o tendrás que recalcular pedidos a mano.

Usuarios y perfiles diferenciados

En un marketplace tienes comprador, vendedor y administrador, y cada uno necesita su propio flujo. Para el alta de vendedor uso Webform combinado con un workflow custom: el formulario captura datos fiscales y bancarios, un admin revisa, y al aprobar se asigna el rol con permisos sobre su propia "tienda" mediante Group (que ha desplazado prácticamente a Organic Groups en proyectos nuevos).

El panel del vendedor lo construyo casi siempre con Views filtrado por owner: sus productos, sus pedidos, sus pagos pendientes. Sin desarrollos a medida más allá de lo imprescindible.

Presentación

Dos caminos. Si el presupuesto manda, Drupal monolítico con un tema basado en Olivero o un tema Commerce como Belgrade, y Twig para la capa visual. Si el cliente quiere una experiencia tipo SaaS moderno, headless con JSON:API y un frontend en Next.js. La segunda opción duplica el coste inicial, pero la mantenibilidad a largo plazo lo compensa cuando el equipo de producto quiere iterar rápido.

Los módulos que merecen estar en tu stack

No todo lo que brilla en drupal.org sirve para producción. Esta es mi lista corta tras varios proyectos.

Núcleo comercial: Drupal Commerce, Commerce Marketplace, Commerce File, Commerce License, Commerce Product Bundle si toca.

Pagos: Commerce Stripe es la opción por defecto en Europa por SEPA, tarjeta y Stripe Connect. Para el mercado español conviene tener integraciones con Redsys y Bizum disponibles para checkout local; Stripe ya soporta Bizum desde 2024, lo que simplifica la vida. PayPal sigue siendo útil como secundaria.

Búsqueda y descubrimiento: Search API con backend Solr en cuanto el catálogo pasa de unos pocos cientos de productos. La búsqueda en SQL contra node se cae sola. Facets para filtros laterales combinables.

Experiencia: Flag para favoritos y wishlists, Voting API con Fivestar para reseñas, Message + Message Notify para las notificaciones (compra confirmada, nuevo producto del vendedor que sigues, etc.).

Seguridad: GDPR, Honeypot y Antibot en formularios públicos, y TFA obligatorio para vendedores y admins. Una cuenta de vendedor comprometida es un problema legal, no solo técnico.

El flujo de dinero: Stripe Connect en cristiano

La pregunta que más se repite en cómo construir un marketplace de productos digitales con Drupal es cómo se reparte el dinero. Stripe Connect resuelve el 90% de los casos.

El modelo que mejor me ha funcionado es "charge and transfer": el comprador paga a la cuenta de la plataforma, Commerce Marketplace calcula la comisión y Stripe transfiere el resto al vendedor según el calendario que configures (instantáneo, diario, semanal). Tu plataforma queda como merchant of record, lo que centraliza la responsabilidad fiscal pero también te obliga a emitir las facturas correctamente.

El onboarding del vendedor se hace vía Stripe Connect Express con OAuth. El vendedor pasa por el flujo de verificación de Stripe (KYC, cuenta bancaria, datos fiscales) sin que tu plataforma toque información sensible. Cuando vuelve, ya está listo para cobrar.

Si te toca diseñar esta capa desde cero, vale la pena pararse a pensarla bien antes de implementar: el modelo de comisión, el calendario de payouts, qué pasa con los reembolsos y cómo gestionas las disputas. En Tangram solemos acompañar esta fase con un equipo mixto de Drupal y producto, así que si necesitas mano experta en la arquitectura de pagos o en el resto del proyecto, podemos echarte una mano.

Proteger los archivos sin volverte paranoico

El cliente siempre pregunta lo mismo: "¿y si alguien comparte el enlace?". La respuesta técnica tiene varias capas.

Lo primero, archivos en private://, nunca en public://. Drupal sirve la descarga tras verificar permisos y el módulo Commerce File genera URLs firmadas con token y expiración. Tres descargas y siete días suele ser un punto razonable.

Para tráfico alto, S3 File System te permite mover el almacenamiento a Amazon S3 con URLs prefirmadas. Drupal sigue controlando el acceso, pero la descarga sale del CDN y no satura tu servidor. Si vendes PDFs o imágenes de alto valor, una marca de agua dinámica con el nombre del comprador inyectada en server-side disuade el 95% del compartir descuidado.

Rendimiento: dónde se rompen las cosas

Un marketplace que va lento es un marketplace muerto. Las palancas que uso en este orden:

Caché: Internal Page Cache y Dynamic Page Cache vienen de serie. Encima, Varnish como proxy inverso para servir páginas a anónimos antes de que toquen PHP. Redis para cache de objetos, y BigPipe activado para que el contenido personalizado aparezca progresivamente.

Búsqueda fuera de la base de datos principal: Solr o Elasticsearch vía Search API. La diferencia entre buscar en MySQL y en Solr con 50.000 productos es brutal: hablamos de pasar de varios segundos a decenas de milisegundos.

Infraestructura: contenedores en Kubernetes con autoescalado horizontal para los picos (lanzamientos, campañas), réplicas de lectura en la base de datos, CDN para assets. Cosas que parecen sobreingeniería al principio pero que evitan reescrituras cuando el tráfico crece.

Lo legal en España, sin saltárselo

Operar en España suma capas. RGPD con consentimiento granular y registro de tratamientos. LSSI-CE con aviso legal y política de cookies accesibles. Derecho de desistimiento de 14 días, con la excepción del contenido digital descargado siempre que el comprador haya dado consentimiento expreso (un checkbox en el checkout, bien redactado, lo cubre).

La facturación electrónica está entrando con fuerza en B2B y va a llegar a B2C. Commerce Invoice automatiza la generación. Para vender a otros países de la UE, el régimen OSS simplifica la declaración del IVA intracomunitario y evita tener que registrarse en cada país.

Hoja de ruta realista

Por fases, porque ir a por todo desde el día uno es la mejor forma de no lanzar nunca.

MVP (8-12 semanas): Drupal con Commerce y Commerce Marketplace, un tipo de producto digital, checkout con Stripe, Commerce File para entrega, alta de vendedor con aprobación manual, tema básico.

Crecimiento (4-8 semanas más): Search API con Solr, valoraciones, licencias con renovación, panel de vendedor con estadísticas en Views, notificaciones.

Escala (continuo): CDN, caché avanzada, marketing (cupones, afiliados), multilingüe con el módulo de traducción de Drupal core.

Para cerrar

Drupal te da los cimientos para construir un marketplace de productos digitales que no se queda corto cuando el modelo de negocio crece. La diferencia entre un proyecto que funciona y uno que se atasca casi nunca está en el código: está en haber elegido bien los módulos, modelado el contenido con cabeza y planificado las capas antes de teclear. Con esa base, el resto es trabajo de oficio.