How to Withdraw Money After Selling on GGsel
Several mechanisms sit between a buyer paying and money landing in your account — a hold, a refund reserve, verification, and the rules of whichever withdrawal rail you chose. Sellers who model margin from the sale price regularly discover that the withdrawable amount is smaller and arrives later than planned. Below is a walkthrough of that journey and what you can actually control at each stage.
The fee structure that gets shaved off along the way is covered separately in our piece on GGsel commissions and payouts.
Where your money actually sits
GGsel is a storefront. The product and settlement backend is provided by the Digiseller platform: that is where the seller balance, sales statistics, code stock and withdrawal requests live. The practical consequences for an operator:
- You file withdrawal requests in the Digiseller dashboard, not on the storefront.
- Balance rules are inherited from the platform, not from the individual storefront.
- You operate under two rule sets at once — the storefront's and the platform's.
The backend itself is covered in more depth in our piece on selling digital goods through Digiseller.
The journey of a payment: four states
The classic beginner mistake is treating "sold" and "received" as one event. In reality the amount passes through several states:
| State | What it means | Withdrawable |
|---|---|---|
| Paid by buyer | Payment cleared, goods delivered | No |
| On hold | The dispute window is still open | No |
| Available | Hold cleared, fees withheld | Yes |
| In reserve | Retained against possible refunds | No, until the term expires |
We deliberately quote no durations as figures — hold periods and reserve rules are revised and depend on seller standing and product category. Check current values in the platform's terms before you build a cash-flow plan around them.
The hold — why it exists
Holds are often read as money withheld for no reason. The mechanics are actually simple: refunds to buyers come out of the seller's balance. If revenue were withdrawable instantly, the platform would have no source of funds to refund a buyer who wins a dispute, and the entire risk would land on the buyer.
That leads to a practical conclusion: hold duration is not a constant but a function of your risk. High-dispute categories and new accounts operate on more conservative terms. Consequently, lowering your complaint rate directly speeds up how fast your money turns over — this is not abstract reputation but a concrete cash effect. How to do that at the listing level is covered in our piece on setting up a GGsel product card.
The refund reserve
The reserve is a separate mechanism often confused with the hold. A hold is the time before an amount becomes available. A reserve is a share of revenue retained on top of that, to cover refunds on sales already considered closed.
The key point: a reserve is neither a penalty nor a fee. If no refunds occur, the money becomes available once the retention term expires. But for planning purposes it means a portion of your turnover is permanently out of reach, and working capital has to be calculated accordingly. Practices for reducing refunds are covered in our piece on avoiding chargebacks on digital goods.
Verification as the gate to withdrawal
An important asymmetry: you can usually sell before you can withdraw. Identity and payout-detail confirmation gates access to the withdrawal rails specifically. This follows from requirements imposed on payment intermediaries, not from platform whim.
Practical rules:
- Complete verification early, not once a meaningful balance has piled up.
- The account holder's name must match the verified account's details — a mismatch blocks the payout.
- Jurisdiction matters — the available rails and required documents differ by country.
Seller checking procedures are covered in detail in our piece on GGsel moderation and verification.
Withdrawal rails and how to pick one
Platforms of this type usually offer several ways to receive funds, and they are not equivalent. They differ along four axes:
- Cost. Different rails cost different amounts, and this is a layer on top of the sale commission.
- Settlement speed. From near-instant to several banking days.
- Jurisdictional availability. Some methods do not work everywhere.
- Reporting suitability. Some rails leave a clean documentary trail, others do not.
Always check the exact list of methods available to you, their cost and any minimums in your dashboard before your first payout: these terms change and vary by country. The fourth axis matters especially to anyone operating formally — a rail through which you cannot evidence the origin of funds creates a reporting problem, and the mechanics are covered in our piece on tax and VAT for digital-goods distributors.
Reconciliation — the step almost nobody takes
Payout reconciliation is a dull task that pays for itself in the first contested month. The minimum procedure: keep your own ledger of sales and, once per reporting period, match four figures — the sale amount, the fees withheld, the refunds, and the amount actually received.
A discrepancy almost always traces to one of two causes: a refund you forgot, or a fee layer your model never accounted for. Without that reconciliation you cannot correctly calculate either your real margin or your tax base — and you will discover the problem at the moment it is most expensive to fix.
What actually drives your revenue
Every mechanism above — hold, reserve, rail cost — determines when and how much you receive. But the number all of it is subtracted from is set by your purchase price. The FoxReload wholesale catalogue covers 900+ SKUs — game keys, gift cards, top-ups, subscriptions and software with multi-region items — over a single REST API with automatic delivery. Reliable availability and fast fulfilment additionally cut your dispute rate, and with it the volume of your own money sitting in hold and reserve.
On integration: ask your supplier how exactly you learn an order's status — with no callbacks available, status comes from polling. Verify webhook and idempotency-key support in that specific supplier's documentation rather than assuming it exists.