Vender temas y extensiones de otros: el mercado de autores

Panel → Autores y Panel → Revisión. Otras personas publican en tu tienda los temas y las extensiones que han hecho, tú los revisas antes de que salgan a la venta, y cada venta le abona al autor su parte en su monedero.

Un autor es un vendedor más: tiene su panel, su monedero y su comisión. Lo que cambia es lo que vende — un paquete que se descarga, con licencia, versiones y soporte— y que nada se publica sin que lo mire una persona.

Esta página es el mercado visto desde tu panel. Lo mismo visto por quien publica en él —cómo empaqueta, firma y pone precio a su trabajo— está en Vender el tema que has hecho, que es la página que hay que pasarle a un autor que pregunta por dónde empezar.

Cómo entra un autor

Hay dos caminos.

• Lo das de alta tú, como a cualquier vendedor. Ver Vender con otros.
• Lo pide él. El escaparate manda la solicitud a POST /tienda/autores/solicitudes (en el contrato de comercio es applyAsAuthor) y te llega a Panel → Autores, en una cola. Los cuatro temas de fábrica sirven ese formulario en /vender, enlazado desde el pie.

La solicitud pide nombre, correo, qué va a publicar (temas, extensiones o las dos cosas) y un enlace a algo que haya hecho. Sin ese enlace no se admite: no habría nada que revisar. Puede añadir país, web, con qué tecnologías trabaja y su experiencia.

Un correo solo puede tener una solicitud viva. Si vuelve a enviarla, se le dice que ya la tenéis; si ya es autor, que entre en su panel. Si la rechazas, puede volver a pedirlo más adelante.

En la cola tienes tres botones:

• Marcar que la estoy mirando, para que nadie más del equipo se ponga con la misma.
• Aceptar. Crea al autor como vendedor, activo, con la comisión por defecto del 30 %: el autor se lleva el 70 % de cada venta. Si ya había un vendedor con ese correo o ese identificador, se usa ese en vez de crear otro. Y le da acceso a su panel: se le crea la cuenta y le llega un correo de bienvenida con un enlace para poner su contraseña, que vale siete días (un restablecimiento normal caduca a la media hora, y una invitación así caducaría antes de leerse). El enlace va al panel del vendedor, que es el de PCC_VENDEDORES_URL. Si ese correo ya es de alguien de tu equipo, no se enlaza solo: un usuario enlazado a un vendedor pierde el acceso a la gestión de la tienda, y eso no puede pasar sin que nadie lo decida. El correo le dice que su acceso se prepara a mano.
• Rechazar. El panel te pide el motivo antes de guardarlo, y al autor le llega por correo.

La comisión por defecto está fija en el código, no en la pantalla, para que nadie dé de alta a un autor con otro reparto sin darse cuenta. Si a uno le quieres poner otra, se la cambias después en su ficha de vendedor.

Qué sube el autor: la pieza y sus versiones

En su panel, en Mis piezas, el autor crea una pieza: un tema o una extensión, con nombre, resumen, descripción, precio, demo, licencia y el nicho al que va dirigida.

Después sube una versión: el paquete y un número.

• El paquete es un .zip. Se comprueba por su contenido, no por la extensión: un .rar renombrado se rechaza al subirlo, no en tu revisión. Un tema se empaqueta con pcc-theme pack. Para un plugin no hay orden de empaquetar (pcc-plugin tiene nuevo, comprobar y dev): pasa pcc-plugin comprobar y comprime tú la carpeta, tal como hay que copiarla en plugins/ — por ejemplo zip -r mi-plugin-1.0.0.zip mi-plugin.
• Tope de 60 MB por paquete. Lo cambia PCC_TOPE_PIEZA_MB.
• El número va en tres cifras, como 1.4.0, y puede llevar un sufijo de versión previa, como 1.4.0-beta.1. Tiene que ser mayor que la última publicada, con las reglas de SemVer: 1.10.0 va después de 1.9.0 porque se comparan como números, y una versión previa va antes que su versión (1.4.0-beta.1 < 1.4.0-rc.1 < 1.4.0).
• Con cada versión van sus notas: qué cambia. Son las que luego lee el comprador.

Y las capturas, hasta 8. La primera es la que se ve en el listado, así que el orden importa y el autor lo puede cambiar. Se comprueban como cualquier imagen del panel: por su firma, no por su nombre.

Para mandarla a revisar hace falta un paquete subido, el resumen escrito y un precio, aunque sea 0. Mientras está en la cola, el autor no la puede tocar: lo que revisas es lo que hay.

La revisión

Panel → Revisión es la cola de lo que los autores han mandado. Para cada pieza tienes tres salidas:

• Publicar.
• Pedir cambios, con lo que hay que cambiar. El autor lo corrige y la vuelve a mandar; no tiene que empezar de cero.
• Rechazar, con el motivo.

Pedir cambios o rechazar sin decir por qué no se puede: un rechazo sin motivo no le sirve de nada a quien lo recibe.

Abre la pieza antes de decidir. La cola enseña los datos; Ver la pieza entera trae además sus capturas, sus versiones y todo lo que se ha decidido antes sobre ella. Revisar un tema sin mirar sus capturas es aprobarlo a ciegas, y una pieza que no tiene ninguna es motivo para pedir cambios, no para publicar.

No hace falta ser su autor para abrirla, y de él no ves más de lo que vería un comprador: su nombre público, ni su correo ni dónde cobra. Para revisar un tema no hace falta saber en qué banco está quien lo hizo.

Desde una herramienta tuya, eso es GET /gestion/mercado/operador/piezas/{id}, en el área Mercado de un token de servicio. Esa misma área da GET /gestion/mercado/operador/licencias, las licencias de todo el mercado con el correo del comprador tapado. Lo que cobra un autor no está en esa área: eso es Pagar a autores, que se confirma aparte al crear el token.

En los tres casos al autor le llega un correo con la decisión y, si la hay, tu nota. El correo sale solo si la revisión se guarda: si algo falla y se deshace, tampoco se manda. Un correo que dice «publicada» de algo que no lo está es peor que ninguno.

Qué pasa al publicar

Publicar no es cambiar un estado: es que la pieza pase a existir en tu catálogo.

• Se crea el producto, publicado, con el nombre, el resumen, la descripción y el precio de la pieza, y atado a su autor. Ese enlace es el que reparte el dinero al vender: sin él, la venta entraría entera en la tienda.
• El paquete queda como descarga del producto. El comprador lo baja desde su pedido.
• La primera captura es la imagen del producto, y las demás le siguen en su orden. Sin captura, la pieza saldría en el catálogo como un hueco gris.

A partir de ahí se vende como cualquier otro producto, y la parte del autor entra en su monedero al cobrar el pedido.

Una versión nueva sustituye a la anterior

Cuando publicas una versión nueva de una pieza que ya estaba a la venta, no se añade un fichero más: se sustituye el que había. Todos los que ya la compraron pasan a descargarse la nueva, sin pagar otra vez.

• A cada comprador le llega un correo, uno por pedido, con el número de versión, las notas de lo que cambia y el enlace a su pedido.
• Se le renueva la cuota de descargas. Quien ya había gastado las suyas, o dejado caducar el acceso, puede bajar la versión nueva.
• Se conserva cuándo descargó por primera vez. Ese dato prueba que empezó a usar el contenido, y de él depende el derecho de desistimiento.

Se hace así porque, si cada versión fuera un fichero distinto, el comprador se quedaría para siempre en la que compró.

Las licencias: una por compra, por sitio

Cada pieza comprada lleva una licencia. Se emite al cobrar, una por línea del pedido, y al comprador le llega un correo que le dice que la tiene en su pedido. Si el aviso de pago llega dos veces, no salen dos claves.

La clave es la credencial. No hay usuario ni contraseña: el tema o la extensión, ya instalado en la web del comprador, la usa para hablar con tu tienda.

Lo que hace falta saber:

• Vale para un sitio, salvo que la variante comprada diga otra cosa en pcc_licencia.sitios (una «licencia para 3 sitios» es otra variante). Para usarla en otro, se suelta primero la de antes.
• La dirección se normaliza. http://Ejemplo.com/, https://www.ejemplo.com y ejemplo.com son el mismo sitio, y el puerto no cuenta. Es el fallo número uno de estos sistemas: sin esto, una misma web gastaría varias activaciones y el comprador acabaría escribiendo a soporte.
• Reinstalar no gasta. Activar otra vez el mismo sitio devuelve la activación que ya tenía.
• Los sitios de pruebas no gastan: localhost, 127.*, 192.168.*, 10.*, los que acaban en .local o .test y los que empiezan por staging. o dev.. Si gastaran, un desarrollador se quedaría sin licencia antes de publicar nada.
• La respuesta de comprobar va firmada, para que la pieza pueda saber que la ha dado tu tienda y no otra.
• Si reembolsas el pedido entero, sus licencias se anulan. Con un reembolso parcial (solo los portes, por ejemplo) se quedan: es la misma regla que las descargas.

Quién puede liberar un sitio

La petición número uno de soporte de cualquier tienda que venda licencias por sitio es «me he mudado de dominio». Se atiende por tres caminos, y los tres dejan escrito quién fue en pcc_licencia_uso.soltado_por:

El autor puede liberar un sitio; anular una licencia, no. Liberar devuelve una plaza a quien compró; anular le quitaría algo que pagó, y eso no está en manos de quien vendió. Solo se anula con el reembolso del pedido entero.

Hay topes, y cuentan por licencia se aprete el botón donde se apriete: 6 al día y 12 al año por licencia, 60 al día por autor y 20 al día por comprador. No frenan un ataque: frenan que soltar y volver a activar se convierta en la forma de usar en veinte sitios una licencia de uno.

El soporte caduca; la licencia, no

Cada compra incluye 6 meses de soporte del autor. Lo cambia PCC_MESES_SOPORTE. La fecha se guarda en cada licencia, y la comprobación la devuelve junto a si el soporte sigue vigente.

Pasada esa fecha, la licencia sigue valiendo y las versiones nuevas le siguen llegando. Lo único que se acaba es el compromiso de soporte. Confundirlos y apagarle el producto a alguien es la vía rápida a los reembolsos.

El soporte entre comprador y autor

Las dudas sobre una pieza las contesta quien la hizo, no tu equipo. Van por un canal propio, aparte del soporte de la tienda.

• Es privado y por conversación, no un foro. En un foro, la queja de un comprador enfadado la lee el siguiente que se está pensando la compra.
• Hace falta la clave de licencia para abrir una consulta. Es lo que impide que se llene de gente que no ha pagado. Una licencia anulada no abre nada.
• Con el soporte caducado también se abre, pero sale marcada, y el autor decide si la atiende. Cerrarle la puerta a un cliente es peor negocio.
• El comprador no tiene panel: se le escribe por correo cuando se recibe su consulta y cada vez que el autor contesta, con el enlace a la conversación. Se identifica con el correo de la consulta.
• El autor recibe un correo por cada consulta nueva y las contesta en su panel, en Soporte. Lo que lleva más de 2 días sin respuesta se marca como tarde. Lo cambia PCC_DIAS_SOPORTE.
• Se cierra sola a los 14 días de haber contestado el autor si el comprador no vuelve. Si no, se quedaría abierta para siempre y le estropearía la estadística a un autor que no ha hecho nada mal.
• Las conversaciones cerradas se borran pasado el mismo plazo que el resto del soporte de la tienda (12 meses de fábrica), porque son datos personales del comprador.

La valoración y la reputación

Al cerrar, al comprador se le hace una sola pregunta: si le sirvió. Una, no una encuesta: en cuanto se piden más, deja de contestarlas nadie.

Con eso se calcula la reputación de soporte del autor, sobre los últimos 60 días: qué parte de las consultas valoradas se resolvieron y cuántas horas tarda de mediana en dar la primera respuesta. El porcentaje solo se enseña con al menos 3 valoraciones. Con menos no dice nada, y un solo comprador enfadado dejaría al autor en un 0 % que no se merece.

El autor ve su reputación en su panel, y va incluida en su ficha pública.

La ficha pública del autor

Cada autor tiene una página pública con su nombre, una presentación, su web, su país, sus enlaces y su logo. La rellena él, en Mi ficha. Los enlaces tienen que empezar por https://: un enlace en una ficha pública lo abre un comprador, y sin comprobarlo alguien podría colar uno que ejecuta código.

Lo que cuenta la plataforma va aparte y no lo edita el autor: desde cuándo está, cuántas piezas ha vendido y su reputación de soporte. Las ventas solo salen cuando hay alguna: un «0 ventas» espanta más que no enseñar nada.

En la ficha salen sus piezas publicadas que tu tienda vende de verdad, con el mismo precio que en su página de producto. Solo el tema base la sirve, en /en/autor/<identificador> y /es/autor/<identificador>, y enlaza a ella desde cada pieza de un autor. Los demás temas de fábrica no tienen página de autor.

El dinero del autor: dos relojes a propósito

El panel del autor enseña su dinero en dos pantallas, y un mismo mes puede no coincidir entre ellas. Es intencionado, y cada una lo dice con un enlace a la otra:

• Qué se vende lleva el reloj de la venta. Un reembolso resta en la fila de la venta de la que sale, aunque se devolviera meses después. Contesta a «¿cuánto me dejó de verdad lo que vendí en marzo?». Cada venta enseña también el país de facturación de quien compró (lo que hace falta para el IVA de ventanilla única) y nada más de esa persona.
• Mi dinero lleva el reloj del extracto. Cada apunte va el día en que se movió el dinero, y un reembolso es una línea negativa en el mes en que se devolvió. Es lo que cuadra con lo que se cobra.

Envato y Apple hacen la misma separación y avisan de que sus pantallas no cuadran. Cada pantalla baja su CSV, con las mismas fechas que se están mirando, en estándar y para Excel.

El saldo se parte igual en todas partes: saldo = disponible + en espera. Lo que dejan las ventas de los últimos PCC_DIAS_ESPERA_PAGO días (30 por defecto) espera por si llega un reembolso o un contracargo; después pasa solo a disponible. Espera lo que la venta le deja al autor, ya descontada la comisión, y nunca más que el saldo.

El menú lleva un contador de los hilos de soporte que esperan al autor, en ámbar si alguno pasa del plazo (PCC_DIAS_SOPORTE, 2 días por defecto). Contestar lo baja en el momento.

Lo que pone el escaparate

Tres pantallas del comprador dependen del tema que uses, porque son suyas: las licencias dentro del pedido, la conversación de soporte y el formulario para pedir ser autor. El contrato de comercio las ofrece (getLicenses, support y applyAsAuthor), y los correos enlazan a /pedido/<id> y /soporte/<conversación>.

Los cuatro temas de fábrica traen las tres —base, mascotas, cinematografico y dulce-obrador—, en inglés y en español:

Lo que conviene saber si escribes tu propio tema:

• La clave se enseña entera, no escondida detrás de una descarga. Es la credencial que el comprador pega en su sitio: obligarle a abrir un certificado para copiar dieciséis caracteres es fricción a cambio de nada.
• Abrir una consulta lleva la clave dentro. El formulario está junto a la licencia y la manda escondida: un comprador que tiene que pegar a mano su código de compra es un comprador abriendo una consulta sobre el formulario de consultas.
• Leer una conversación es un POST, a propósito. El comprador se identifica con el correo de la compra, y un correo en la barra de direcciones acaba en los registros del servidor, en el historial del navegador y en el Referer del siguiente enlace que pulse. El tema lo guarda en una cookie HttpOnly corta (en el tema estático, en sessionStorage) y lo manda en el cuerpo.
• /pedido/<id> y /soporte/<conversación> van sin prefijo de idioma en los correos, a propósito: cada tema los reparte al idioma que ese comprador estaba usando.
• El único campo obligatorio de más de la solicitud es el enlace al trabajo, porque es lo que se revisa. Todo lo demás —país, web, stacks, experiencia— es opcional, para que la puerta sea corta.

El id de un pedido no es una contraseña

El id de un pedido viaja por correo, por el historial del navegador, por las cabeceras Referer y en cualquier captura que el comprador mande a soporte. Así que no abre el pedido él solo:

• GET /tienda/pedidos/<id> sin prueba contesta el pedido recortado: qué se compró y cómo va, sin correo y sin dirección. El contrato lo marca con partial: true.
• Licencias, códigos y descargas contestan 403 sin prueba, siempre.
• La prueba viaja en la cabecera x-pcc-pedido. Le llega al tema por tres caminos: en el enlace que llevan los correos (?acceso=), en la respuesta de checkout.complete (así la página de gracias no pregunta nada), o escribiendo el comprador el correo con el que compró (requestOrderAccess).

Los temas de fábrica quitan la prueba de la dirección en cuanto la leen y la guardan en una cookie, y si no la tienen piden el correo. Un correo que no es el del pedido recibe la misma respuesta que el bueno («si ese correo es el de este pedido, ya tienes acceso»): decir «ese correo no es» convertiría el formulario en una forma de averiguar de quién es un pedido.

Lo que hace falta

• Correo configurado (SMTP_*). Sin él, las decisiones de revisión, las licencias, las versiones nuevas y el soporte se quedan en la cola de avisos hasta que haya por dónde mandarlos.
• STOREFRONT_URL, para que los enlaces de los correos lleven al pedido y a la conversación.
• Para pagar a los autores, Pagar a autores y vendedores.