Selling other people's themes and extensions: the author marketplace

Panel → Authors and Panel → Review. Other people publish the themes and extensions they have made in your shop, you review them before they go on sale, and every sale credits the author's share to their wallet.

An author is one more seller: they have their panel, their wallet and their commission. What changes is what they sell — a package that is downloaded, with a licence, versions and support — and that nothing is published until a person has looked at it.

This page is the market seen from your panel. The same thing seen by the person publishing in it — how they package, sign and price their work — is Selling the theme you built, and it is the page to send an author who asks how to start.

How an author gets in

There are two ways.

• You add them, like any other seller. See Selling with others.
• They apply. The storefront sends the application to POST /tienda/autores/solicitudes (in the commerce contract it is applyAsAuthor) and it reaches Panel → Authors, in a queue. The four factory themes serve that form at /vender, linked from the footer.

The application asks for a name, an email, what they will publish (themes, extensions or both) and a link to something they have made. Without that link it is not accepted: there would be nothing to review. They can add their country, website, the technologies they work with and their experience.

One email can only have one live application. If they send it again, they are told you already have it; if they are already an author, to sign in to their panel. If you reject it, they can apply again later.

The queue gives you three buttons:

• Mark that I am looking at it, so nobody else on the team picks up the same one.
• Accept. It creates the author as an active seller with the default 30 % commission: the author keeps 70 % of every sale. If there was already a seller with that email or that handle, that one is used instead of creating another. And it gives them access to their panel: the account is created and they get a welcome email with a link to set their password, valid for seven days (a normal password reset expires in half an hour, and an invitation like that would expire before it is read). The link goes to the seller panel, the one at PCC_VENDEDORES_URL. If that email already belongs to someone on your team, it is not linked automatically: a user linked to a seller loses access to managing the shop, and that cannot happen without someone deciding it. The email tells them their access is being set up by hand.
• Reject. The panel asks you for the reason before saving it, and the author receives it by email.

The default commission lives in the code, not on the screen, so nobody signs up an author on a different split without noticing. If you want a different one for someone, change it afterwards on their seller page.

What the author uploads: the item and its versions

In their panel, under My items, the author creates an item: a theme or an extension, with a name, summary, description, price, demo, licence and the niche it is aimed at.

Then they upload a version: the package and a number.

• The package is a .zip. It is checked by its content, not its extension: a renamed .rar is rejected on upload, not during your review. A theme is packed with pcc-theme pack. For a plugin there is no pack command (pcc-plugin has nuevo, comprobar and dev): run pcc-plugin comprobar and zip the folder yourself, as it has to be copied into plugins/ — for example zip -r my-plugin-1.0.0.zip my-plugin.
• 60 MB limit per package. PCC_TOPE_PIEZA_MB changes it.
• The number has three parts, like 1.4.0, and can carry a pre-release suffix, like 1.4.0-beta.1. It must be higher than the last published one, by SemVer rules: 1.10.0 comes after 1.9.0 because they are compared as numbers, and a pre-release comes before its release (1.4.0-beta.1 < 1.4.0-rc.1 < 1.4.0).
• Every version carries its notes: what changes. They are what the buyer reads later.

And the screenshots, up to 8. The first one is the one shown in the listing, so the order matters and the author can change it. They are checked like any other image in the panel: by their signature, not their name.

To send it for review it needs an uploaded package, a written summary and a price, even if it is 0. While it is in the queue the author cannot touch it: what you review is what there is.

The review

Panel → Review is the queue of what authors have sent. For each item you have three outcomes:

• Publish.
• Request changes, saying what has to change. The author fixes it and sends it again; they do not have to start from scratch.
• Reject, with the reason.

Requesting changes or rejecting without saying why is not allowed: a rejection with no reason is useless to whoever gets it.

Open the item before deciding. The queue shows the details; Open the whole submission also brings its screenshots, its versions and everything that has been decided about it before. Reviewing a theme without looking at its screenshots is approving blind, and an item with none is a reason to ask for changes, not to publish.

You do not have to be the author to open it, and you do not see any more of them than a buyer would: their public name, not their address and not where they get paid. To review a theme you do not need to know where its author banks.

From a tool of your own, that is GET /gestion/mercado/operador/piezas/{id}, in the Marketplace area of a service token. The same area gets you GET /gestion/mercado/operador/licencias, every licence in the marketplace, with the buyer's address masked. What an author gets paid is not in that area: that is Pay authors, which you confirm on purpose when you create the token.

In all three cases the author gets an email with the decision and, if there is one, your note. The email only goes out if the review is saved: if something fails and it is rolled back, it is not sent either. An email that says "published" about something that is not is worse than none.

What happens when you publish

Publishing is not changing a status: it is the item coming into existence in your catalogue.

• The product is created, published, with the item's name, summary, description and price, and tied to its author. That link is what splits the money on a sale: without it, the whole sale would go to the shop.
• The package becomes the product's download. The buyer gets it from their order.
• The first screenshot is the product image, and the rest follow in order. Without a screenshot, the item would show up in the catalogue as a grey hole.

From then on it sells like any other product, and the author's share goes into their wallet when the order is paid.

A new version replaces the old one

When you publish a new version of an item that was already on sale, no extra file is added: the existing one is replaced. Everyone who already bought it now downloads the new one, without paying again.

• Each buyer gets an email, one per order, with the version number, the notes on what changes and the link to their order.
• Their download allowance is renewed. Someone who had used up their downloads, or let their access expire, can get the new version.
• When they first downloaded is kept. That fact shows they started using the content, and the right of withdrawal depends on it.

It works this way because, if every version were a separate file, the buyer would be stuck forever on the one they bought.

Licences: one per purchase, per site

Every item bought comes with a licence. It is issued when the payment is captured, one per order line, and the buyer gets an email saying it is in their order. If the payment notice arrives twice, two keys are not issued.

The key is the credential. There is no username or password: the theme or extension, once installed on the buyer's site, uses it to talk to your shop.

Worth knowing:

• It is valid for one site, unless the variant bought says otherwise in pcc_licencia.sitios (a "3-site licence" is a different variant). To use it on another, release the previous one first.
• The address is normalised. http://Example.com/, https://www.example.com and example.com are the same site, and the port does not count. It is the number one failure of these systems: without it, one website would use up several activations and the buyer would end up writing to support.
• Reinstalling costs nothing. Activating the same site again returns the activation it already had.
• Test sites cost nothing: localhost, 127.*, 192.168.*, 10.*, those ending in .local or .test and those starting with staging. or dev.. If they counted, a developer would run out of licence before publishing anything.
• The check response is signed, so the item can tell it came from your shop and not another.
• If you refund the whole order, its licences are cancelled. With a partial refund (just the shipping, say) they stay: the same rule as downloads.

Who can release a site

The number one support request of any store that sells per-site licences is "I moved to another domain". There are three ways to handle it, and all three record who did it in pcc_licencia_uso.soltado_por:

An author can release a site; revoking a licence is not theirs to do. Releasing gives a slot back to the buyer; revoking would take away something they paid for, and that is not in the hands of whoever sold it. A licence is only revoked when the whole order is refunded.

There are caps, and they count per licence no matter who presses the button: 6 a day and 12 a year per licence, 60 a day per author and 20 a day per buyer. They do not stop an attack: they stop release-and-reactivate from becoming the way to run a one-site licence on twenty sites.

Support expires; the licence does not

Every purchase includes 6 months of support from the author. PCC_MESES_SOPORTE changes it. The date is stored on each licence, and the check returns it together with whether support is still current.

After that date the licence is still valid and new versions keep arriving. The only thing that ends is the support commitment. Mixing the two up and switching someone's product off is the fast track to refunds.

Support between buyer and author

Questions about an item are answered by whoever made it, not your team. They go through their own channel, separate from the shop's support.

• It is private and per conversation, not a forum. In a forum, an angry buyer's complaint is read by the next person thinking about buying.
• The licence key is required to open a request. That is what stops it filling up with people who have not paid. A cancelled licence opens nothing.
• With support expired it still opens, but it is flagged, and the author decides whether to take it. Shutting the door on a customer is worse business.
• The buyer has no panel: they are emailed when their request is received and every time the author replies, with the link to the conversation. They identify themselves with the request's email.
• The author gets an email for every new request and answers them in their panel, under Support. Anything waiting more than 2 days for an answer is flagged as late. PCC_DIAS_SOPORTE changes it.
• It closes itself 14 days after the author replied if the buyer does not come back. Otherwise it would stay open forever and spoil the numbers of an author who did nothing wrong.
• Closed conversations are deleted after the same period as the rest of the shop's support (12 months out of the box), because they are the buyer's personal data.

Rating and reputation

On closing, the buyer is asked a single question: did it help? One, not a survey: as soon as you ask more, nobody answers.

That gives the author's support reputation, over the last 60 days: what share of rated requests were resolved and the median hours to first reply. The percentage is only shown with at least 3 ratings. With fewer it says nothing, and a single angry buyer would leave the author at a 0 % they do not deserve.

The author sees their reputation in their panel, and it is part of their public profile.

The author's public profile

Every author has a public page with their name, an introduction, their website, their country, their links and their logo. They fill it in themselves, under My profile. Links must start with https://: a link on a public profile is opened by a buyer, and without checking it someone could slip in one that runs code.

What the platform counts is kept apart and the author cannot edit it: how long they have been there, how many items they have sold and their support reputation. Sales only show when there are some: "0 sales" puts people off more than showing nothing.

The profile lists their published items that your shop actually sells, at the same price as on their product page. Only the base theme serves it, at /en/autor/<handle> and /es/autor/<handle>, and links to it from every item by an author. The other factory themes have no author page.

The author's money: two clocks on purpose

The author's panel shows their money on two screens, and the same month may not match between them. That is on purpose, and each screen says so with a link to the other:

• What's selling runs on the sale clock. A refund is taken off the row of the sale it came from, even if it was refunded months later. It answers "how much did what I sold in March really leave me?". Each sale also shows the buyer's billing country (what EU one-stop-shop VAT needs) and nothing else about them.
• My money runs on the statement clock. Each line sits on the day the money moved, and a refund is a negative line in the month it was refunded. That is what matches what gets paid out.

Envato and Apple make the same split and warn that their screens do not match. Each screen downloads its own CSV, with the dates being looked at, in a standard flavour and one for Excel.

The balance is split the same way everywhere: balance = available + on hold. What the sales of the last PCC_DIAS_ESPERA_PAGO days (30 by default) leave the author is held in case a refund or a chargeback comes in; after that it becomes available on its own. What is held is what the sale leaves the author, commission already taken, and never more than the balance.

The menu carries a count of the support threads waiting for the author, in amber if any is past the deadline (PCC_DIAS_SOPORTE, 2 days by default). Replying brings it down straight away.

What the storefront provides

Three buyer screens depend on your theme, because they belong to it: the licences inside the order, the support conversation and the form to apply as an author. The commerce contract offers them (getLicenses, support and applyAsAuthor), and the emails link to /pedido/<id> and /soporte/<conversation>.

The four factory themes have all three — base, mascotas, cinematografico and dulce-obrador — in English and Spanish:

Worth knowing if you are writing your own theme:

• The key is shown in full, not hidden behind a download. It is the credential the buyer pastes into their site, so making them open a certificate file to copy sixteen characters is friction for nothing.
• Opening a conversation carries the key by itself. The form is next to the licence and sends it hidden: a buyer who has to paste a purchase code by hand is a buyer filing a support ticket about the support form.
• Reading a conversation is a POST, on purpose. The buyer identifies themselves with the email they bought with, and an email in the address bar ends up in the server logs, in the browser history and in the Referer of the next link they click. The theme keeps it in a short-lived HttpOnly cookie (a sessionStorage entry in the static theme) and sends it in the body.
• /pedido/<id> and /soporte/<conversation> have no language prefix in the emails, on purpose: each theme hands them to the language that buyer was last using.
• The application's only extra required field is the portfolio link, because that is what gets reviewed. Everything else — country, site, stacks, experience — is optional, so the door stays short.

The order id is not a password

An order id travels by email, through the browser history, through Referer headers and in any screenshot a buyer sends to support. So it does not open the order on its own:

• GET /tienda/pedidos/<id> without proof answers a trimmed order: what was bought and how it is going, with no email and no address. The contract marks it partial: true.
• Licences, codes and downloads answer 403 without proof, always.
• The proof travels in the x-pcc-pedido header. It reaches the theme three ways: in the link the emails carry (?acceso=), in the answer to checkout.complete (so the thank-you page asks for nothing), or by the buyer writing the email they bought with (requestOrderAccess).

The factory themes take the token out of the address as soon as they read it and keep it in a cookie, and they fall back to asking for the email. A wrong email gets the same answer as the right one ("if that email is the one on this order, you now have access"): saying "that is not the email" would turn the form into a way of finding out whose an order is.

What you need

• Email configured (SMTP_*). Without it, review decisions, licences, new versions and support stay in the notification queue until there is a way to send them.
• STOREFRONT_URL, so the links in the emails lead to the order and the conversation.
• To pay authors, Paying authors and sellers.