How a Sale and Delivery Works on Plati.market
To the buyer a sale on a digital storefront looks like a single click; to the seller it is a chain of six or seven states, each of which can go wrong. What follows is the full order lifecycle — from payment to the close of the guarantee window — with what the seller actually sees at each step and how to fix the standard delivery failures.
If you have not launched yet, start with building the product card.
Who does what: engine versus storefront
The key to the whole mechanic is the split of responsibilities between Digiseller and Plati.market. Digiseller is the engine: it accepts the payment, stores the listings and code pools, performs delivery, keeps the seller balance and handles claims. Plati.market is the storefront on top of that engine: search, categories, reviews, the product page.
The practical consequence for a seller is simple. If delivery is broken, you fix it in the engine dashboard, not in the storefront settings. And conversely, if the product cannot be found in search, the problem is the listing presentation, not the auto-delivery config. Half the time lost in support goes to looking for the fault on the wrong layer.
The order lifecycle, stage by stage
| Stage | What happens | What the seller sees | Where it breaks |
|---|---|---|---|
| Listing view | Buyer opens the product | View counter only | Region and platform not stated |
| Checkout | Buyer picks a payment method | Nothing | Payment method unavailable to that buyer |
| Payment | Payment clears and is confirmed | Order appears as paid | Processor decline, slow confirmation |
| Issuance | Engine pulls a unit from the pool or the external source | Order moves to delivered state | Empty pool, source API error, timeout |
| Receipt | Buyer sees the code and instructions | Order marked as delivered | Unreadable code, missing instructions |
| Redemption | Buyer redeems on the platform | Nothing, if all is well | Wrong region, code already redeemed |
| Guarantee window | Claim window is open | Order is not final yet | Claim, dispute, funds reversal |
| Close | Guarantee expires | Revenue counts as settled | — |
What the table makes visible is that the seller does not observe the whole process. Between issuance and redemption there is a blind spot where the buyer already holds the code but has not yet confirmed that it works. Every dispute is born in that blind spot, which is exactly why the quality of your code source matters more than any storefront setting.
What actually happens at issuance
Issuance is the one step you genuinely control from a technical standpoint, and it runs in one of two modes.
Delivery from a pool. You upload a list of codes to the listing in advance. On payment the engine takes the next free unit, marks it as used and hands it to the buyer. Fast, but the pool is finite — and it empties at night.
Delivery from an external source. On payment the listing calls your backend or a supplier API and obtains a code at order time. The pool is effectively unlimited for as long as the supplier has stock. This requires a working endpoint, a sane timeout and a defined fallback behaviour when the call fails. The mechanics are unpacked in automating digital code delivery.
A note on webhooks. Some suppliers push order-status notifications; others offer only scheduled polling. This is not a universal standard, so before you design your delivery logic around callbacks, verify whether your specific supplier actually implements them and what happens when a callback never arrives. Polling on a sensible interval is more reliable than an elegant webhook architecture that does not exist.
The guarantee window, claims and disputes
Once the code is received, a guarantee window opens — the period in which the buyer may report a non-working item. Its length is configured per listing, and the platform sets the outer bounds in its own rules; confirm the currently permitted values before configuring anything.
The practical meaning for a seller is that money inside that window is not yet yours. While the guarantee is open, an order can turn into a claim, a claim into a dispute and a dispute into a refund. Funding your next purchase order out of revenue whose guarantee has not closed is a well-worn route to a cash gap.
A claim plays out like this: the buyer reports a problem, the seller responds, and the two either settle it or escalate to platform arbitration. The outcome is almost always decided by two things — response speed and evidence. A seller who answers within minutes and offers a replacement wins even ambiguous cases. A seller who stays silent for a day loses even the ones they were right about.
Refund or replacement
Replacement almost always wins. A refund costs you the item, the revenue and the listing position; a replacement costs one unit of cost of goods and preserves everything else. So the working rule is straightforward: hold reserve stock specifically for replacements rather than planning to cover them out of your next purchase.
A refund is the right call where you objectively cannot deliver a working item — for example the regional restriction only surfaced after purchase and you have no version for that region. There, a fast voluntary refund is cheaper than a lost dispute, because it leaves no negative mark on the account history. Keep the payment layer in mind too: some reversals arrive through the buyer's bank rather than the platform dispute flow, and at that point nobody is listening to your arguments.
Four failure modes and how to recover
Empty pool
Symptom: orders hang pending or the listing errors out. Detection: alert on a stock threshold, not on zero — the warning has to arrive before the fact. Recovery: pull the listing, fulfil open orders manually from an alternative source, restore stock. Systemically, replace the manual pool with an external source. See recovering from a supplier stockout.
Duplicate code issued twice
Symptom: a second buyer receives an already-used unit. This usually follows a manual upload containing duplicates, or two sources operating in parallel without shared accounting. Detection: deduplicate the list before upload and reconcile issued units against the order log. Recovery: immediate replacement plus an audit of the whole batch, not only the complaint.
Wrong region
Symptom: the buyer gets an activation error although the code is technically valid. This is not a defective item, it is a mismatch between the listing region and the buyer's region. Detection: state the region in the title, not at the bottom of the description. Recovery: swap for the regional version if you have one, otherwise refund. Details in region-locked keys explained.
Code already redeemed upstream
Symptom: the platform reports the code as used even though you issued it for the first time. That is a supplier-side signal — a batch resold twice, a revocation, or a compromised source to begin with. Detection: several complaints from one purchase in a short period. Recovery: stop selling that entire batch before more complaints arrive, replace the units already issued and raise a claim with the supplier. For mass revocations see handling code revocation and region locks.
Where to source inventory so delivery stops breaking
Most of the failures above are not platform problems, they are source problems. FoxReload covers exactly that layer: a wholesale catalog of 900+ SKUs (game keys, gift cards, in-game currency top-ups, eSIM, subscriptions, software licences), instant delivery, multi-region SKUs and a single REST API that your listing calls at order time. The pool stops being finite, and night-time stockouts and cancellations stop being routine.