Qué es un marketplace de contenidos digitales y por qué construirlo con Drupal

Lo defino así cuando me siento con un cliente: un marketplace de contenidos digitales es una plataforma donde varios vendedores publican productos intangibles (ebooks, plantillas, cursos, fotografía, música, software, assets gráficos) y los compradores los adquieren mediante licencias. La diferencia con una tienda online clásica es que aquí no hay un único dueño del catálogo: conviven dos actores con intereses distintos. El vendedor sube y mantiene su inventario; el comprador navega, paga y consume. Esa dualidad rompe muchos MVP cuando llega producción.

Drupal entra en la conversación por motivos concretos. Su arquitectura modular permite extender sin tocar el core, su sistema de roles y permisos es de los más granulares del ecosistema CMS, y Drupal Commerce aporta un motor transaccional sólido sobre el que apoyar la lógica de negocio. A eso sumo una ventaja que casi nadie pondera: la facilidad para modelar tipos de contenido con metadatos específicos como formato, tamaño, versión o licencia. En un marketplace digital, ese modelado es la mitad del producto.

Arquitectura general del proyecto

Antes de abrir el terminal conviene pintar el mapa. La arquitectura mínima viable incluye estos bloques:

• Catálogo de productos digitales con tipos de contenido a medida.
• Sistema de roles que separe capacidades de vendedor y comprador.
• Flujo de compra gestionado por Drupal Commerce (carrito, checkout, pago).
• Entrega digital automatizada tras la confirmación del pago.
• Panel de vendedor para subir productos, ver ventas y gestionar licencias.
• Capa de reseñas y valoraciones que construya prueba social.
• Seguridad y control de acceso sobre los archivos descargables.

Con ese esquema delante el desarrollo se ordena solo: primero el núcleo transaccional, después las capas de valor añadido. Quien se salta este paso acaba reescribiendo el módulo de roles dos veces.

Instalación y configuración inicial de Drupal Commerce

El punto de partida es una instalación limpia de Drupal 10 o superior. Commerce entra por Composer:

composer require drupal/commerce

Habilitamos los submódulos esenciales con Drush:

drush en commerce commerce_cart commerce_checkout commerce_payment commerce_order commerce_product -y

Después toca crear una Store que actúe como entidad contenedora del marketplace. En /admin/commerce/config/stores se fija la moneda por defecto, la zona fiscal y los datos del operador. Aquí surge la primera decisión de arquitectura: aunque tengamos múltiples vendedores, la Store puede ser única si la comisión y la liquidación se gestionan externamente, o replicarse por vendedor cuando se necesita aislamiento fiscal. La diferencia son semanas de desarrollo y un dolor de cabeza con Hacienda. Decídelo con tu asesor antes de tocar nada.

Configuración de métodos de pago

En /admin/commerce/config/payment-gateways se añaden las pasarelas. Para un marketplace con vendedores independientes las opciones reales son:

• Stripe Connect: split payments donde la plataforma retiene su comisión y el vendedor recibe el resto de forma automática. Mi opción por defecto para contenidos digitales.
• PayPal Commerce Platform: modelo equivalente con onboarding de sub-merchants.
• Adyen for Platforms o MangoPay: cuando el volumen, el KYC o la operación europea regulada lo justifican.
• Commerce Payment genérico para sandbox y pruebas.

La pasarela condiciona el flujo de liquidación, las comisiones efectivas y la complejidad del KYC. En contenidos digitales lo habitual es retener entre un 8% y un 15% por transacción, y ese número tiene que cuadrar con los fees de la pasarela. Es una decisión de negocio, no técnica, y por eso debe tomarse antes de escribir código.

Definición de roles: vendedor y comprador

Drupal gestiona roles en /admin/people/roles. Para el marketplace creamos al menos dos roles adicionales:

• Vendedor (vendor): crea, edita y elimina sus propios productos; accede a un panel de ventas; consulta estadísticas de descargas; responde reseñas.
• Comprador (buyer): navega el catálogo, añade productos al carrito, completa el checkout, descarga archivos adquiridos y deja reseñas.

Permisos granulares

En /admin/people/permissions se reparten capacidades por rol. Algunos permisos clave:

Permiso	Vendedor	Comprador
Crear contenido tipo Producto Digital	Sí	No
Editar contenido propio	Sí	No
Ver catálogo de productos	Sí	Sí
Realizar compras	No	Sí
Acceder al panel de vendedor	Sí	No
Dejar reseñas	No	Sí
Descargar archivos comprados	No	Sí

Donde de verdad cambia el juego es al introducir Group o Domain Access, y muchas veces Role Delegation para que vendedores premium puedan invitar editores a su espacio sin tocar la administración global. Esta capa convierte el marketplace en una colección de tenants, no en un foro con permisos pintados.

Tipos de contenido para productos digitales

Creamos un tipo de contenido a medida, por ejemplo digital_product, con estos campos:

• Título (texto): nombre comercial del producto.
• Descripción (texto largo con formato): detalle e instrucciones de uso.
• Imagen de portada (imagen): miniatura para el catálogo.
• Archivo digital (file, privado): el descargable real, almacenado en el sistema privado de Drupal para impedir acceso directo.
• Formato (lista): PDF, EPUB, MP3, ZIP, PSD, etc.
• Precio (campo Commerce Price): vinculado a la variación de producto.
• Categoría (referencia a taxonomía): permite filtrar por temática.
• Tipo de licencia (lista): personal, comercial, extendida.
• Versión (texto): útil para software o plantillas actualizables.
• Autor/vendedor (referencia a usuario): vincula el producto con su creador.

Variaciones de producto y licencias

Drupal Commerce trabaja con product variation. En un producto digital aprovechamos esa abstracción para mapear cada tipo de licencia a una variación. Un mismo pack de iconos puede tener "Licencia personal" a 9 euros y "Licencia comercial" a 29 euros, cada una con su archivo adjunto si la entrega cambia. Modelarlo así desde el día uno evita el típico parche posterior con campos booleanos y reglas condicionales que nadie quiere mantener.

Gestión de descargas y entrega digital

El módulo Commerce File vincula archivos a variaciones de producto y abre la descarga solo cuando el pedido pasa al estado completado. Su configuración define cuántas descargas permite cada compra y durante cuánto tiempo permanece activo el enlace.

Para archivos pesados o tráfico alto, sirvo las descargas vía X-Sendfile (Apache) o X-Accel-Redirect (Nginx), delegando al servidor web la transferencia y liberando al proceso PHP. En /admin/config/media/file-system se fija la ruta del directorio privado, que debe vivir fuera del document root público. Si esto se ignora, el primer pico de descargas te tumba el FPM.

Protección contra accesos no autorizados

El directorio privado de Drupal ya impide la descarga directa por URL, pero conviene reforzar:

• Reglas .htaccess o directivas Nginx que bloqueen el acceso al directorio de archivos privados.
• Límite en el número de descargas por token.
• Registro de cada descarga en un log auditable, base para resolver disputas con vendedores.

Panel de vendedor (vendor dashboard)

Los vendedores necesitan un espacio propio. Con Views combinado con Panels o Layout Builder se monta un dashboard que incluya:

• Listado de productos propios con acceso rápido a editar o despublicar.
• Resumen de ventas: pedidos, ingresos brutos, comisiones retenidas.
• Gráfico de descargas por periodo (integrable con el módulo Charts).
• Notificaciones de reseñas pendientes de respuesta.
• Formulario de perfil de vendedor visible en la tienda pública.

El acceso se restringe al rol vendedor con permisos de vista y ruta protegida. Commerce Marketplace y Commerce Dashboard sirven como base; encima añadimos un workflow de moderación con Workbench cuando el cliente quiere revisar publicaciones antes de que salgan al catálogo.

Sistema de reseñas y valoraciones

La confianza es la moneda del marketplace. Commerce Product Review, o Voting API con Fivestar, permite a los compradores dejar puntuación y comentario tras la compra. Lo que recomiendo:

• Solo aceptar reseñas de usuarios que hayan completado un pedido del producto en cuestión. Se valida con reglas de acceso o un hook a medida.
• Moderar antes de publicar o aplicar filtros anti-spam con Honeypot o Antibot.
• Mostrar la media de valoraciones en la ficha y en los listados: es el dato que más mueve la conversión.

Consideraciones de seguridad

Un marketplace mueve datos financieros y archivos con valor comercial, lo que cambia el listado de riesgos:

• HTTPS obligatorio en todo el sitio, especialmente en checkout y descarga.
• Actualizaciones frecuentes de Drupal core y módulos contrib. Suscripción a los Security Advisories oficiales.
• Validación de archivos subidos por vendedores: extensiones restringidas, escaneo con ClamAV cuando sea viable, tamaños máximos.
• Rate limiting en endpoints críticos (login, checkout, descarga) para frenar fuerza bruta y abuso.
• Backups automatizados de base de datos y directorio privado con política de retención.
• Roles mínimos: nunca conceder al rol vendedor permisos de administración global. Principio de mínimo privilegio aplicado en serio.
• CSP y cabeceras HTTP de seguridad configuradas a nivel de servidor o con Security Kit (SecKit).

A esto le sumo un plan de disputas y chargebacks: qué pasa cuando un comprador reclama, cómo se congela la liquidación al vendedor en Stripe Connect y quién decide. Esa parte no es un módulo, es un proceso, y si no existe el escrow lo acabas inventando a mano.

Escalado y rendimiento

Cuando el catálogo crece y el tráfico aumenta, el rendimiento pasa de detalle a prioridad:

• Activar la caché de página de Drupal y considerar un proxy inverso como Varnish.
• Usar Search API con Solr o Elasticsearch para búsquedas rápidas y facetadas.
• Servir imágenes mediante un CDN aplicando estilos de imagen para reducir peso.
• Desacoplar tareas pesadas (thumbnails, correos transaccionales) con Drupal Queue y un worker externo.

Un marketplace es un producto vivo, no un catálogo

Si me preguntas cómo crear un marketplace de contenidos digitales con roles de vendedor y comprador en Drupal que aguante producción, la respuesta no se agota en una lista de módulos. Pasa por planificar la arquitectura de roles y permisos desde el día uno, elegir una pasarela que soporte split payments y un KYC razonable, y blindar la entrega de archivos con un esquema seguro. Drupal Commerce, Commerce Marketplace, los roles nativos y la flexibilidad de los tipos de contenido te dan la base; el resto es criterio de producto.

Cada proyecto tiene su giro: unos piden suscripciones recurrentes, otros un preview parcial del contenido antes de la compra, muchos terminan añadiendo afiliados para empujar crecimiento. Drupal absorbe esos requisitos sin que tengas que migrar a otra plataforma, siempre que la arquitectura inicial lo haya previsto.

Si quieres revisar la arquitectura de tu marketplace, elegir los módulos adecuados o desarrollar piezas a medida sobre Drupal, hablemos sin compromiso en Tangram Consulting.