TLDR
MTG proxy quantity pricing usually rewards a larger batch with a lower per-card rate, but that does not mean you should maximize the order. Build the smallest complete batch with a defined job: a proof set, one playable deck, a testing gauntlet, a Cube update, or a confirmed revision. Add sideboards, tokens, helper cards, and duplicate staples only when they will actually be used. Then compare the next quantity tier against the total checkout cost and the risk that speculative cards will become obsolete.
The practical decision is not “How many cards can I add?” It is “Which cards need to exist at the same time?” That question separates a useful batch from a pile of discounted filler. A slightly higher unit price can be the better deal when it prevents sorting problems, stale deck versions, and an avoidable reprint.
How MTG proxy quantity pricing works
A quantity tier assigns a per-card rate according to the total number of cards in an order. When the order crosses a breakpoint, the published rate may fall. Before relying on that change, confirm that the live cart applies the new rate to every card rather than only to cards above the threshold. Also check shipping, taxes, optional work, and any other checkout charges.
The PrintMTG pricing page in the supplied October 4, 2026 research snapshot published the following tiers. These figures are a dated planning reference, not a permanent quote; verify them in the live PrintMTG ordering flow before approving a project. PrintMTG also stated that it had no minimum order and displayed free shipping for orders over $75. Because “over $75” may exclude a subtotal of exactly $75, do not plan around that boundary without checking the cart.
| Order quantity | Published price per card |
|---|---|
| 2–9 cards | $2.00 |
| 10–29 cards | $1.50 |
| 30–49 cards | $1.25 |
| 50–74 cards | $1.00 |
| 75–99 cards | $0.80 |
| 100–199 cards | $0.55 |
| 200–499 cards | $0.45 |
| 500–999 cards | $0.38 |
| 1,000+ cards | $0.33 |
The breakpoints can produce unintuitive totals if the displayed rate applies to the entire order. At the published rates, 99 cards would have a card subtotal of $79.20, while 100 cards would have a subtotal of $55. That is a reason to test the live cart—not a reason to add a random hundredth card without confirming the deck and every version. Prices and tier logic can change.
Count a usable project, not just card rows
Start with the list that must become physically playable. The headline deck count is only the beginning. Depending on the project, the order may also need a commander or companion, a sideboard, tokens, emblems, helper cards, alternate configurations, or duplicates that let multiple decks stay assembled.
- Main-deck cards, including basic lands if you want them printed rather than supplied separately
- Commander, companion, or other separately displayed game component
- Every sideboard or wish-board card you intend to test
- Tokens and emblems that carry information you regularly need
- Helper cards for double-faced or other awkward physical components
- Duplicate staples required by decks that will be played simultaneously
- A small number of confirmed revision cards, clearly separated from the current list
Do not count a shared staple once if two decks need to be on the table at the same time. Conversely, do not print five copies merely because five decklists contain it if your process intentionally moves one sleeved copy between decks. Simultaneous availability—not the number of digital lists—determines the physical quantity.
For a Commander project whose saved list contains 100 cards including its commander, the first planning number may be 100. The finished order could be higher once tokens and helper cards are included, or lower if basics and readily available cards are intentionally omitted. Record those exclusions so a smaller total is not mistaken for an import failure.
For a broader comparison of one deck, several decks, and a complete testing environment, use the order-size planning guide. If the main decision is whether to print everything or only selected cards, the whole-deck versus expensive-cards workflow addresses the ongoing swapping and sorting tradeoff.
Choose one of four batch models
| Batch model | Best use | Primary risk to control |
|---|---|---|
| Small proof batch | Checking readability, art choices, or an unfamiliar workflow before a large project | Treating a successful proof as approval for card versions that were not included |
| Stable full-deck batch | A settled list that should remain assembled and playable | Missing basics, commander components, tokens, or special cards |
| Multi-deck or Cube batch | A gauntlet, Cube, group order, or several decks needed simultaneously | Duplicate errors, merged lists, and unclear ownership |
| Confirmed revision batch | Upgrades or corrections to a previously archived project | New cards failing to match the intended versions or organization |
Use a proof batch when uncertainty is concentrated
A proof batch is useful when one unresolved choice affects hundreds of cards: text size, a dark frame treatment, front-and-back pairing, or an import process you have not validated. Include representative problem cases rather than ten easy cards. A good proof set might contain a normal card, a borderless version, a card with dense rules text, a double-faced card, a token, and the darkest artwork in the project.
Use a full-deck batch when the list is stable
A complete deck reduces the need to move cards between shells and makes setup easier. It is usually more valuable when the deck will see repeated play, when several people use the testing pool, or when version consistency matters. Printing only missing or expensive cards can still be sensible for a volatile brew, but it creates an ongoing inventory task: every change must be matched against the cards already owned and the cards already printed.
Combine projects only after each list is independently clean
Multi-deck and Cube batches can reach lower price tiers naturally, but combining unfinished lists magnifies small mistakes. Clean, count, and approve each deck separately. Only then merge the quantities and deduplicate cards where sharing is intentional. Keep the source identity in a separate manifest so the combined order can later be split back into decks.
Should you add cards to reach the next tier?
Add cards only when they are confirmed project components. Good additions include omitted tokens, a real sideboard, duplicates needed for simultaneous play, or an already-approved upgrade package. Poor additions include speculative cards, random variants, and “maybe someday” staples selected only to cross a breakpoint.
Use this decision test: calculate the card subtotal on both sides of the tier, add the current delivery and tax amounts, and ask whether every added card has an assigned deck, Cube section, token package, or testing role. If the larger order costs less overall and the additions are useful, crossing the tier is reasonable. If its apparent savings depend on cards with no job, keep the smaller batch.
The same rule applies when a shipping offer is nearby. Never assume that adding cards to reach a shipping threshold saves money. Compare the final checkout totals, and be careful with wording such as “over $75,” which may not include exactly $75.
Calculate usable-project cost instead of unit price alone
A practical comparison uses four parts: printed-card subtotal, checkout delivery cost, sorting and proofing effort, and avoidable reprint risk. Only the first two appear as straightforward cart charges. The other two explain why a low per-card rate can still produce an inefficient project.
- Calculate quantity multiplied by the active per-card rate.
- Add shipping, taxes, and any selected paid options shown at checkout.
- Estimate the organizational burden: list cleanup, version review, deck separation, labeling, and storage.
- Identify likely reprints caused by unstable decklists, uncertain art choices, missing special cards, or poor archive records.
- Choose the batch with the lowest reasonable cost for cards that will be usable together—not automatically the lowest unit price.
For example, a stable testing gauntlet may justify a large combined order because every deck has a defined role. A newly brewed deck with twenty unsettled slots probably does not. In that case, printing a stable core or waiting for more testing can be cheaper than buying discounted versions of cards that leave the list next week. The competitive deck-testing workflow explains how to separate stable lists from revision batches.
Clean the list before the quantity discount matters
A quantity tier cannot rescue an incorrect import. PrintMTG states that its ordering workflow can accept pasted or uploaded decklists and then allow quantities and versions to be chosen. Its formatting guidance recommends one card per line with the quantity first, permits headings that begin with two slashes, and advises removing inline notes.
Before ordering, reconcile the imported count against the source list. Look for punctuation problems, split-card names, aliases, accidental duplicate sections, omitted sideboards, and basics that were included or excluded unintentionally. Then review versions. A correct card name with the wrong set, frame, language, or artwork is still a project error.
- Save the original exported decklist.
- Save a cleaned import copy without commentary or unsupported headings.
- Record the approved quantity, set code, collector number, or other version identifier where available.
- Keep special-card front and back decisions together.
- Export or capture the final approved print list after proofing.
- Date the archive and note which deck, Cube section, or group-order participant owns each quantity.
This archive turns a future reorder into a controlled revision. Without it, you may know that a card needs replacement but not which art or printing was selected. That problem becomes especially noticeable when replacement cards must fit into a previously organized deck.
Plan timing separately from pricing
A lower unit price does not compensate for missing a fixed game night. PrintMTG’s shipping policy states a typical production estimate of about two business days and estimates roughly five to nine business days total for most U.S. orders when production and transit are combined. It also warns that very large or complex orders may take longer. These are estimates rather than delivery guarantees, so check the current policy and available checkout options when a date matters.
Leave time for list approval before ordering and for sorting after delivery. A multi-deck batch is not ready for play merely because it arrived: cards still need to be checked against the manifest, divided into projects, and paired with tokens or helper components.
Casual play and sanctioned events are different projects
Proxy-style and playtest cards should be planned for the setting in which they will be used. Wizards’ published proxy policy distinguishes personal playtest cards from counterfeits and says sanctioned events require authentic Magic cards, apart from limited judge-issued proxies for cards damaged during that event. Confirm the current event rules before building a physical card project for organized play.
Frequently asked questions
How many proxies should I order for a Commander deck?
Start from the exact saved decklist, including the commander, and decide deliberately whether basics will be printed. Add tokens, emblems, helper cards, and any alternate cards you truly use. Do not force the total to remain at the deck-list count when the complete physical project requires extras.
Do sideboards and tokens affect the quantity tier?
If they are individual printed cards included in the same cart, they generally contribute to the order quantity under the ordering flow described by PrintMTG. Confirm the cart count and rate before checkout, especially if tokens or other components are handled differently by the current system.
When do shared staples need duplicate copies?
Print duplicates when the decks must remain assembled or be played simultaneously. One copy may be enough when you intentionally maintain a shared binder and accept the setup time required to move cards. Document that choice so a future organizer does not treat the missing copies as an error.
When is a proof batch smarter than a large order?
Use a proof batch when an unresolved import, version, readability, or special-card decision would repeat across many cards. Choose representative edge cases. If the uncertainty concerns only the decklist itself, continue testing the list before printing rather than using a physical proof to answer a deckbuilding question.
How can I avoid reprinting cards after the deck changes?
Separate stable cards from speculative slots, approve versions before checkout, and archive both the source list and final print list. Later changes can become a labeled revision batch instead of forcing you to reconstruct the original project.
Final preflight
Before chasing a lower tier, confirm that every card has a job. Reconcile the imported count, review versions, add required sideboards and tokens, check duplicate needs across simultaneous decks, and save the approved list. Finally, compare the live totals on both sides of the relevant breakpoint—including delivery and taxes. The best MTG proxy quantity pricing decision is the batch that creates a complete, repeatable play project with the fewest avoidable reprints.