Moving From AccsMarket: The Three Things That Actually Change

If you have used AccsMarket you already know the shape: many sellers, similar stock, funds held while an order settles. Anyone arriving here from there is not asking what a marketplace is. They are asking what breaks in their week if they move.

An earlier version of this page answered that by listing five things AccsMarket allegedly does badly and scoring both sites in a table. We have no access to their code, no way to verify any of it, and neither do you, so all of it has been removed rather than reworded. What follows is only what can be measured on this side, on 31 August 2026, against the live database. Run the same three questions wherever else you sell and you will have a comparison worth something.

One: the money clock, in both directions

A buyer's payment is held against the order rather than passed to the seller. Confirming receipt releases it. If the buyer never clicks, an hourly job releases it anyway after a waiting period counted from when the order was placed, one to three days depending on the seller's level. Nobody reviews anything in between; it is a timer, not a queue.

In practice the timer does most of the work. Of 86,072 completed orders that reached a confirmed state, 73,511 were confirmed automatically and 12,561 by the buyer. Two things stop the timer: a live dispute, and an open support ticket on the order.

Going the other way, of 1,994 withdrawal requests, 1,892 have been paid, at a median of four and a quarter hours from request to processed. 1,880 of them cleared inside a day and exactly two in the site's history took longer than forty eight hours. Splitting by seller, every one of the ten highest-volume sellers sits under eight hours, so that is not one favoured account flattering the average.

On what it costs: nothing is deducted from an order. The platform's cut is applied once, at payout, as a percentage of the amount withdrawn, and each method carries its own minimum. Two numbers to compare, not one. Withdrawing earnings has the figures and the enabled methods.

Two: three product models, not two

A catalogue here is not all one thing, and which model a listing uses changes who has to be awake when an order lands.

• Automatic fills from a pool the system draws from without you. 12,129 of the 16,894 visible listings, and 58,020 orders to date.
• Inventory is stock you upload in advance, assigned row by row as orders arrive. 3,051 listings, 31,027 orders.
• Made to order is filled by you, by hand or through the API, with the order status moving as you work. 1,714 listings, 7,228 orders.

The distribution is the useful part. Roughly seven in ten live listings never need a person, but made-to-order is not a rounding error either, and it is what lets a catalogue carry things that are not a credential in a text file. How order delivery works covers which route a given order actually takes, which is decided per order rather than per listing.

There is no listing fee. There is a cap on how many listings an account can hold active at once, which rises with seller level, and that is the constraint worth planning around instead. Listing limits covers how it is counted.

Three: the API, which is the real migration cost

Everything above is policy. This part is work, and it is usually the reason a move stalls.

There are two documented interfaces and both are live pages you can open before committing anything. The supplier API is an interactive panel: it lists the endpoints, generates the key, signs requests with a key header and a timestamp, and lets you fire each call from the browser and read the response. It also carries the order-paid webhook, configured from your shop settings, which is what removes polling from a made-to-order workflow. The customer API is the buying side: placing orders, checking stock before you commit, reading the category tree, and the separate SMS verification flows.

The manual-orders API guide walks the made-to-order loop end to end, which is the one worth testing first because it is the one with a human in it.

Test with one product and one webhook before moving a catalogue. The panel exists so that costs an afternoon rather than a week.

Things this page will not tell you

Four claims came off this page and are worth naming, because their absence is the point.

• That the reviews prove anything. A review requires a paid order, confirmed, from the buyer who placed it. But where a buyer says nothing after confirming, the system files a silent five-star entry, and almost all of them are exactly that. The site shows a separate count of reviews someone actually wrote; that is the number with information in it. Judging a supplier works through both.
• That purchases are anonymous. They are not. You can check out without an account, but as soon as payment completes an account is created from the email you used. Guest checkout is real; anonymity is not on offer and we should not have implied it was.
• Anything about how a competitor works inside. See above.
• Anything about encryption or network security. We have no measured claim, so there is no section.

If you are actually moving

1. Open the supplier API panel and run one endpoint against a test product before anything else. If the integration is going to hurt, it hurts there.
2. Move one product line first and watch a full cycle: order, delivery, confirm, payout. It takes days, not weeks, and the timings above are what you should see.
3. Set your warranty hours deliberately. They are per listing, they start at delivery rather than payment, and buyers read them.
4. Keep both catalogues live until the payout cycle has completed once. There is no reason to make the migration and the first withdrawal the same experiment.

If you are arriving as a buyer rather than a seller, what actually protects an order here is the more useful page.