How to Add a Digital Product on Plati.market: a step-by-step listing guide
Creating a listing on Plati.market takes fifteen minutes; rebuilding it after your first wave of disputes takes weeks of damaged rating. The problem is not interface complexity. It is that three decisions get made right at the start and then govern everything afterwards: product type, delivery method, and how the region is described. Below is the working order of operations and the failure modes that actually break listings.
If you have not set up a seller account yet, start with seller registration on Plati.market.
Engine vs storefront: where the product is really created
The first thing that confuses newcomers is that the product is not created on the storefront. Plati.market is the front end that shows buyers a catalogue and takes payment. The listing, the stock, the delivery rules and the statistics all live in the Digiseller seller panel — the engine the storefront runs on.
Practical consequences:
- The add-product button lives in the Digiseller seller panel, not in the storefront UI.
- One listing can surface on several storefronts in the network — you do not recreate it per storefront.
- Delivery settings are attached to the product in the engine, not to the marketplace it appears on.
- Balance, statistics and order history are shared as well.
Step 1. Choose the product type
The product type determines which fields you get next and how the engine hands content to the buyer. Options come down to three families:
- Unique code from a pool — keys, gift cards, promo codes. Each buyer receives their own line from an uploaded list, with no repeats.
- The same text or file for everyone — guides, templates, access to materials. Stock is not consumed.
- Individually fulfilled product — anything requiring an action from you or an external system after payment: top-ups by player ID, account operations, services.
Getting this wrong is expensive. List keys as the same text for everyone and you will sell one identical code to ten buyers. That is not a hypothetical — it is a recurring cause of mass refunds among new sellers.
Before you pick a type, confirm the product is permitted at all; category restrictions are covered in what you can sell on Plati.market.
Step 2. Delivery method — three options and what each really costs
This is the decisive choice in the listing. There are formally three options, and they differ less in features than in how much of your time they consume.
| Delivery method | How it works | Best for | Where it breaks |
|---|---|---|---|
| Code pool | You pre-upload a list; the engine hands out one line per order | Small catalogue, predictable demand | The pool empties overnight — sales stall or turn into cancellations |
| Manual issuance | After payment you send the code yourself | Products that genuinely cannot be automated | Buyer waits, opens a ticket, leaves a bad review |
| External API fulfilment | The engine requests a code from your source at order time | Permanent catalogue, wholesale supplier relationship | Source outage or timeout — you need a fallback |
Code pools are the fastest start and the most common source of overnight stockouts. If you go this route, set a top-up rule based on a remaining-stock threshold rather than on running dry.
Manual issuance feels free because it needs no setup. It is not free: you pay with time, response speed and reviews. Digital-storefront buyers treat instant delivery as the baseline, and an hour of waiting reads as deception rather than delay.
External fulfilment means the engine calls your code source the moment payment clears and hands the buyer whatever the source returned. It is the only option that scales without scaling your manual work. The practical setup is covered in automating digital code delivery.
If you integrate an external source, ask the supplier up front how retries and delivery confirmation work on their side. Some supplier APIs offer callbacks and duplicate protection, others do not — verify this against that specific supplier's documentation rather than assuming it by default.
Step 3. Uploading stock
For a code pool, stock goes in as a list — line by line or as a file. Three rules that save money:
- One code per line, no stray spaces or invisible characters. Lists copied out of a spreadsheet frequently carry a trailing space, and the buyer ends up with a code that fails validation.
- Never mix regions or editions in one pool. This is the single most common reason half your buyers are happy and the other half open disputes.
- Check the batch before uploading, not after. Retroactive code revocation hits the seller, not the person who sold them to you.
A useful habit is to keep a buffer separate from the live pool and top up on a threshold rather than on zero. Measure that threshold in days of sales, not units: a hundred codes means something very different at three sales a day versus thirty.
Step 4. Region, platform and the mandatory fields
A digital listing sells on its headline. The title needs the product itself, the platform, the edition and the activation region. Not game key, but specifics.
What must be filled in:
- Activation platform. Game service, console ecosystem, app store, publisher site — the buyer needs to know where the code goes.
- Region. If the code does not activate everywhere, that restriction goes in before payment. The mechanics are in region-locked keys explained.
- Edition and contents. Base version or edition with add-ons, subscription length, card denomination.
- What the buyer actually receives. A code string, a link, a file — the format must match what the headline implied.
A title without a region is not saved characters, it is a pre-paid dispute. A buyer whose code failed to activate is almost always right when the restriction was invisible before payment.
Step 5. Buyer instructions
The post-purchase information block is the most underrated field in the listing. It reduces support load and changes dispute outcomes. Minimum contents:
- Step-by-step redemption — where to go, where to enter the code.
- What to do if the code is rejected — concrete steps, not a request to contact you.
- Restrictions — region, expiry, account binding.
- Contact channel and expected response time.
Write it so it can be read on a phone in thirty seconds. A wall of text is not read at all.
Step 6. Test purchase before going live
Do not publish a listing without buying your own product first. It is the only way to see the whole path: how the page looks, what arrives after payment, how the code is formatted, whether the instructions are legible.
This step routinely exposes:
- a pool that is uploaded but a product still flagged as out of stock;
- codes arriving truncated or glued to a stray character;
- an external source returning errors while the listing sits active;
- instructions inherited from a donor listing describing a different platform;
- a price calculated without marketplace fees, payment-method costs and withdrawal.
Check that last item separately. The marketplace fee is only the first layer of cost; payment method, withdrawal and a reserve for compensations stack on top. Always check the current tariff page before you price.
What a normal order looks like from payment to delivery is covered in the Plati.market sale and delivery flow.
Failure modes that actually break listings
The pool ran out overnight. Orders turn into cancellations, and rating falls faster than it recovers. Fixed by a threshold top-up rule or external fulfilment.
Duplicate code. Caused by the wrong product type, or by uploading a spreadsheet where a line appears twice. Result: two buyers, one working code, one guaranteed refund.
Wrong region. The buyer redeems in the wrong region and opens a dispute. Prevention is region in the headline plus an explicit warning before payment.
Revoked batch. Codes of questionable origin get cancelled retroactively by the publisher, and the compensation comes out of the seller's margin, not the margin of whoever sold them to you.
Chargeback after delivery. The code is out, the payment is disputed. What helps is a recorded delivery event and unambiguous terms inside the listing itself.
Cloned listing. You duplicated an existing product and forgot to change the region, edition or instructions. The cruellest failure mode, because it looks fine right up to the first sale.
Where to source inventory for your listings
A listing is configured once; availability is needed every single day — and availability is what breaks most new sellers. FoxReload covers that part: a wholesale catalogue of 900+ SKUs (game keys, gift cards, in-game currency top-ups, eSIM, subscriptions, software licences), multi-region SKUs, instant delivery and a single REST API. You connect the external source once and stop hand-loading codes into a pool before every weekend.