How to Set Up Auto-Delivery of Digital Goods on FunPay
Auto-delivery is what separates a lot that sells itself from a lot that you sell. The buyer pays and gets the code immediately, and you are not sitting in chat at three in the morning. But not everything can be automated — part of the FunPay catalog simply does not fit the instant-delivery model. This guide covers which lot types can be switched over, how the goods pool works, how to avoid duplicates and expired codes, what to do on a stockout, and how to wire a wholesale source so the pool refills itself.
If you have not launched on the platform yet, start with the general FunPay seller guide and the listing creation walkthrough.
What auto-delivery actually does
The mechanic is simple. A pool is attached to the lot — a list of pre-loaded units of goods. After payment the platform pops the next entry, hands it to the buyer and decrements the stock count. The seller is not part of the transaction. Two hard constraints follow from that.
First, the goods must be text. A key, a pin, a promo code, an activation link — yes. An action performed inside a game account — no. Second, the goods must be interchangeable. Any unit in the pool has to work equally well for any buyer of that lot. If the code depends on account region, platform or game edition, that is not one lot with a shared pool but several separate lots with their own pools.
Which gives you a straightforward segmentation rule: one pool equals one interchangeable product. Mixing European and regional keys, different denominations or different platforms in a single lot guarantees disputes, because the buyer receives a technically valid code that is useless to them.
Which lot types automate and which do not
| Lot type | Auto-deliverable? | Delivery mechanism | Main risk |
|---|---|---|---|
| Game keys (Steam, platform) | yes | line popped from pool on payment | region lock, supplier revocation |
| Top-up card pins and gift cards | yes | code or pin from pool | denomination wrong for account region |
| Promo codes and subscription codes | yes | code from pool | expiry date passes before the sale |
| Top-up by account ID or nickname | no | manual sign-in and credit | wrong ID, wrong server |
| Boosting, leveling, services | no | negotiation and work in chat | timelines, scope disputes |
| Game accounts | partly | credential handover, usually manual | account recovery, ban |
A mixed catalog is normal. The practical strategy is to automate everything that can be automated and handle the rest by hand — the manual lots then get your full attention instead of whatever is left over.
Pool discipline that saves you refunds
One unit, one line
The storage format is primitive, which is exactly why it breaks: a trailing space, an invisible character pasted out of a spreadsheet, a blank line between blocks. All of it goes to the buyer exactly as it sits in the pool. Normalise every batch — trim whitespace, drop empty lines, unify line endings — before you upload.
Deduplicate against history, not the batch
The most common duplicate scenario runs like this: the supplier sends a file, you upload it; a day later you re-export the same order for reconciliation and upload it again. There are no duplicates inside the new batch — but the pool now holds two identical codes. Check every incoming batch against your entire historical set of issued and pooled codes. Keep a register: code, batch, upload date, delivery date, order number. That register is also your evidence in a dispute.
Expiry
Some goods have a shelf life — promo codes, seasonal campaigns, subscription codes with an activation window. Those must not be bought far ahead of demand. Tag each batch with an expiry date and drain the pool first-in-first-out, or codes will quietly accumulate at the bottom of the pool and die before they ever reach a buyer.
Buffers and refills
Running until it runs out is not a strategy. Set two numbers per fast-moving SKU: the threshold that triggers a refill, and the target volume the pool is topped up to. The threshold follows sales velocity and supply lead time. If a lot moves 20 units a day and your supplier delivers within the hour, a threshold of 10 is fine; if delivery takes a day, hold at least a full day of turnover plus headroom.
Refilling should be an event, not a habit. A configured threshold means you learn that the pool needs stock before it empties, rather than from a cancelled order. The refill mechanics, including real-time order notification over webhooks, are covered in depth in the digital code delivery automation guide.
Reconciliation
The lot pool and your own stock always drift apart — the only variable is how fast. Codes leave through routes other than sales: you handed a couple out manually to settle a dispute, you uploaded a batch twice, some codes turned out dead and were struck off. Reconciliation is therefore a routine, not a one-off.
Minimum procedure: once a day, compare the line count in the lot pool with the expected balance in your register, and chase down the reason for every discrepancy. An unexplained gap is nearly always either a duplicate or a lost delivery, and you would much rather find both yourself than hear about them from a buyer.
What to do when the pool empties
An empty pool on FunPay is not just a couple of lost orders. The lot stops selling, loses the position it accumulated in its category listings, and with it the flow of organic orders. If the pool managed to hand out dead codes first, add a refund wave and a hit to your rating.
Order of operations when the pool empties mid-sale:
- Unpublish or pause the lot immediately, not after the first order you cannot fill.
- Close pending orders honestly. If payment went through and you have nothing to deliver, a refund with an explanation beats silence. A dispute with a clear paper trail almost always closes more gently.
- Find the cause, not just the stock. A stockout is a symptom: the threshold did not fire, the supplier did not ship, demand doubled during an in-game event.
- Recalculate the buffer against the new demand instead of restoring the old threshold.
Supply-failure recovery patterns are covered separately in the stockout and supplier recovery breakdown.
Why instant delivery lifts conversion
Digital-goods buyers usually buy on impulse, right there. A lot with instant delivery closes the sale at the moment of decision; a lot with manual delivery sends the buyer off to wait for a reply, and some of those people go to a seller who is answering now. Then the compounding kicks in: fast, dispute-free sales produce reviews and seller status, status pushes the lot up the listings, and listings bring more orders. A manual lot with the same product at the same price moves through that cycle more slowly for one reason — it is bounded by your presence online. Which is why it makes sense to automate your fastest-moving code lots first — that is where the effect shows up soonest.
Where to source stock for the pool
Auto-delivery lives or dies on the source: you can refill a pool as fast as you like, provided there is somewhere to refill it from. FoxReload is a wholesale B2B catalog of digital goods — game keys, gift cards, top-ups, eSIM, subscriptions, software — with a REST API and instant fulfilment. One integration contour instead of chasing a dozen suppliers over chat: pull codes against actual demand, refill the pool on a threshold, and stop carrying dead stock that expires before it sells. To stand the integration up from scratch, see the API quickstart.
Related reading: