How Card Harbor's repricing actually works.
Repricing tools have a reputation problem: sellers picture a black box that races prices to the bottom or cuts a listing loose while nobody's watching. This page is the opposite, checked against the actual source code: the exact formula, the floor it will not cross, and the clicks that stand between any computed price and a live TCGplayer listing.
The strategy, named plainly
Card Harbor's reprice engine is a fixed rule, not a model that learns or adapts. There's no AI or machine learning involved. For each SKU, it starts from its own capture of TCGplayer's competitor-pricing export for your account, the same data you'd see in the seller portal, not a number bought from a third-party pricing API.
The formula: find the lowest competing listing, subtract the amount you've told it to beat that price by, and that's the proposed new price. It never matches a competitor and it never moves a listing that is already at or under the low. The comparison only fires when a competitor comes in strictly cheaper than what a buyer pays you today; a tie counts as nobody to undercut, because the export cannot tell a genuine tie from your own listing being the low. It only ever moves a price down to stay competitive, or back up to your floor if the price had already fallen below it; it never chases a rising market upward.
You choose what "lowest" is measured against. By default it's the buyer-facing total, price plus shipping (adjusted for a free-shipping-over-$5 setting if you use one), which is what a buyer actually compares. Switch the price basis to item-only and it compares listed prices alone and leaves shipping out of both sides.
The floor and the guardrails
You set a minimum price floor once, and it's enforced on every price the reprice engine touches on TCGplayer, and on the mirrored price Card Harbor pushes to ManaPool. A computed price is clamped up to the floor, and a listing already priced below the floor gets raised to it, even with no competitor data at all. A row telling ManaPool to stop offering a card is the one exception, since nothing is being sold at that price.
A second guardrail watches the size of the drop itself. If a computed price would cut the current price by more than a percentage you configure, that row keeps its computed price and is flagged for your review in the plan and in the export, so you decide whether it goes. The drop limit ships off: until you set a percentage, nothing is flagged on that basis. A SKU with no usable competitor data, or one that isn't currently listed, is skipped and named to you, never priced at zero or a guess.
See the fee and profit calculator to check what floor still nets you a profit before you set one.
Who actually pulls the trigger
Repricing is never part of any unattended cycle, under any settings combination. It only exists as something you start by hand, and every price change has to clear the same sequence of explicit steps: preview the plan, select which rows to include, export a CSV, upload it to TCGplayer's staged import area, then move it live. Nothing in that chain fires on a timer.
The last step, moving staged prices live, carries its own guardrail: it checks that the TCGplayer account you're signed into matches the store name you configured, refuses to resend a file it's already uploaded (checked by an exact content hash), and confirms TCGplayer is holding at least as many staged rows as you exported before publishing anything.
Sync safety
Background sync, checking orders, pulling ManaPool and TCGplayer inventory, is off until you turn it on. Even once it's on, anything that could reduce or change a live listing, TCGplayer delisting and the entire ManaPool push, sits behind a second, separate opt-in that also defaults off, and applies the same way on a timer or when you click "Run sync now" yourself.
- Demotions wait for you. When a card looks sold on one marketplace but is still shown live on another, Card Harbor never removes it automatically. You review and resolve it, on the Sync tab, every time.
- Unattended delisting is capped. A single unattended run can pull at most 200 units. If the computed plan would remove more than that, the whole run is refused, not partially applied.
- Stale data blocks a delist. If your inventory snapshot is too old, the delist step refuses to run against it rather than guessing. Background sync refreshes your TCGplayer snapshot for you, at most once every 30 minutes, so this normally only comes up when your TCGplayer sign-in has expired. Orders that arrive after a snapshot don't block anything: their copies are subtracted from the snapshot's counts first, matching the reduction the marketplace already made when the order came in.
- Duplicate sends are blocked twice over. TCGplayer takes a little while to apply a delist, and staged quantities add rather than replace, so a snapshot taken too soon after one would show the old numbers and invite the same reduction again. Two guards prevent that: a delist won't act on a snapshot taken within 15 minutes of the previous delist publishing, and an exact-byte CSV hash check refuses rows that have already been uploaded. Both have to agree before a reduction goes out.
What this will never do without a click
No price changes on a timer. No listing removed because another marketplace looked like it sold. No reduction sent to TCGplayer or ManaPool without the delist opt-in you turned on yourself. No publish without the account-identity and duplicate-file checks passing first. For the fuller picture of what data the app captures to make any of this possible, see the telemetry page.