How to Create and Set Up a Product Card on GGsel
A GGsel product card does three jobs at once — it sells, it declares the terms, and it configures the delivery mechanics. Sellers usually treat it as paperwork, fill in the minimum fields, and then wonder why conversion is poor and disputes keep arriving. Below is a block-by-block breakdown: what belongs in each field, what moderation actually checks, and why card quality and refund rate are really the same number.
Before publishing it pays to settle your catalogue first — that is covered in our piece on what to sell on GGsel.
Anatomy of a card
A card is a set of blocks, each with its own job. Confusing them is the classic beginner mistake.
| Block | Function | Who reads it |
|---|---|---|
| Title | Identification and search placement | Buyer in search results |
| Region and platform | Legal declaration of terms | Buyer and arbitration |
| Description | Removing objections before payment | Buyer on the card page |
| Delivery type | Fulfilment mechanics | Platform system |
| Code stock | Source of what the buyer receives | Platform system |
| Buyer instructions | Reducing post-sale contacts | Buyer after the sale |
The key takeaway: different blocks are read by different audiences at different moments. The description works before payment, the instructions after, and region and platform work a third time as well — when a dispute opens and arbitration checks what was declared.
The title — three mandatory elements
The title decides whether a buyer clicks in search results, and it doubles as the first layer of declaration. The mandatory minimum:
- The exact product name — no abbreviations, no reordered words.
- The activation platform — where exactly the code is redeemed.
- The region of validity — where it works and, when it matters, where it does not.
Edition, denomination or term go in as well when the product has variants. Marketing inserts about value and speed, on the other hand, do not belong: they do not help search placement and they crowd out the information the buyer decides on.
A check you can run: read your own title through the eyes of someone who will later open a dispute. If the question "will this work in my region" survives the reading, the title is unfinished.
Region and platform — the most expensive part of the card
This block costs more than all the others because it determines dispute outcomes. Regional binding is the leading complaint driver across the whole key category, and nearly all such complaints resolve in the buyer's favour when the seller never declared the restriction explicitly.
Practical rules:
- Duplicate the region — in the title, in the description and in the system field. One place is not enough.
- Declare the negatives. "Does not activate in region X" works better than silence.
- Avoid blanket wording implying global validity when the product is in fact restricted.
The underlying mechanics are covered in our explanation of region-locked keys.
The description — objection handling, not a retelling
A good description answers the questions that would otherwise arrive in your inbox. A structure that works:
What the buyer receives
Concretely: product type, delivery format, what exactly arrives after payment — a code, a link, a voucher.
Terms and restrictions
Region, platform, account requirements, validity period, multi-device activation, renewal limits.
How to activate
A short sequence of steps. Obvious as it may look to you, for a share of buyers this is their first purchase of the kind.
What is not included
An underrated block. Explicitly listing what is NOT included removes the most common category of complaint — the buyer expected more than you were selling.
Delivery type and code stock
Here the card stops being text and becomes configuration. Auto-delivery means the product is a ready string loaded into the card's stock: the code releases to the buyer the moment payment clears, with no action from you. Manual fulfilment puts the order on hold until you act.
The difference is decisive for scaling:
- An auto-delivered item sells overnight, on holiday and at any volume.
- A manual item is capped by your personal hours and grows linearly with workload.
- Delivery speed feeds directly into ratings and dispute probability.
A separate task is preventing sales against empty stock. An exhausted or stale card stock produces the worst possible scenario: a paid order with nothing to deliver. How to build automated code supply is covered in our piece on automating digital code delivery.
What moderation checks
The card review reduces to three questions:
- Does the content match the name. A mismatch between title and actual product is the main rejection reason.
- Is the nature of the goods lawful. Categories with frequent rights-holder issues get closer scrutiny, so keep your sourcing documented.
- Are restrictions disclosed. A missing region or platform on a card where they are material sends it back for revision.
Requirements change, so always check the platform's current help pages before publishing in bulk. Seller and product verification procedures are covered in detail in our piece on GGsel moderation and verification, and Steam-specific scenarios in the guide to selling Steam keys on GGsel.
Buyer instructions — the second line of defence
Instructions attach to the delivery and work after payment. Their job is to close the cases where the product is fine but the buyer did not understand the procedure. Include the activation steps in order, the typical mistakes, and what to do if a code is rejected.
This is a cheap artefact with disproportionate returns: every contact absorbed by the instructions is time you did not spend and a refund risk that did not hit your balance. Once your first payout approaches it is worth understanding the settlement side too — the mechanics are in our piece on withdrawing money after selling on GGsel.
Where to source the goods behind your cards
No amount of card quality rescues an item with bad sourcing and unreliable availability. The FoxReload wholesale catalogue covers 900+ SKUs — game keys, gift cards, top-ups, subscriptions and software, including multi-region items, which lets you declare the region on the card precisely rather than approximately. Supply runs over a single REST API with automatic delivery, so card stock refills without manual work.
On integration: ask your supplier how exactly you learn an order's status — with no callbacks available, status comes from polling. Treat webhook and idempotency support as something to verify in that specific supplier's documentation, never as a given.