How to add an item to an existing BigCommerce order

Natively, you can't add an item to an existing BigCommerce order once payment has been captured. The platform can't charge the customer for the difference, so its own documentation tells you to create a new order instead. That's the short answer — but it leaves money and goodwill on the table, so here are the four real options, including the one that turns this limitation into revenue.

The request is one of the most common a store gets: "I forgot something — can you just add it to my order?" From the customer's side it sounds trivial. From BigCommerce's side it runs straight into how captured payments work.

Why the obvious way fails

In the control panel you can open a paid order and edit its products — but anything that raises the total has no mechanism to collect the extra money. The capture is already done, and BigCommerce won't re-authorize the card against the original transaction. Community threads asking "how does the customer pay for the added item?" have sat unanswered for years because the honest answer is: natively, they can't. Anything that increases an order's value after capture has to be collected some other way.

Option 1 — Create a second order (the official route)

Build a new order for the forgotten item and fulfill it alongside the first. It's the route BigCommerce recommends, and it works — but the downsides are real: a second shipping fee unless you zero it manually, a second transaction fee you absorb, two orders to pick, pack and reconcile, and a clunky experience where the customer gets two confirmations for what they think of as one purchase. Fine occasionally; painful as a daily pattern.

Option 2 — Send a payment link

Invoice just the difference through your gateway (most support a quick payment link or manual charge), then edit the order once it's paid. This keeps everything to a single fulfillment and collects the money cleanly. The cost is time: it's a manual back-and-forth on every request, and the customer has to act on the link before you ship.

Option 3 — The API (with a serious caveat)

The Orders API lets you append line items to an existing order programmatically. Two problems keep this from being a clean fix. First, it still doesn't collect payment for the difference — that's on you to arrange. Second, a PUT update clears all discounts and promotions on the changed line items, so a scripted "just add this product" can silently corrupt a discounted order's pricing. It's a tool for developers who understand those edges, not a general answer.

Option 4 — Let the customer add it themselves, and pay properly

This is the only option that scales. A self-service edit window lets the customer open their own order from the confirmation page or account, add the product, and pay exactly the difference — taxes and totals recalculated, the payment reconciled against the order automatically. No second order, no manual payment link, no API edge cases. And because the customer is doing it at the moment they're most engaged, the same surface doubles as a post-purchase upsell: a discounted complementary add-on, or an "add $40 for free shipping" threshold bar, presented exactly when they're most likely to say yes. Well-targeted post-purchase offers convert in the 5–15% range, so the request that used to be your most annoying ticket becomes one of your cheapest revenue channels.

What this costs you when you ignore it

It's tempting to treat "can you add one more?" as a minor annoyance, but the cost adds up. Every request handled as a second order means a duplicated shipping and transaction fee plus double the fulfillment handling; every one handled by email is staff minutes that scale with order volume; and every one you can't resolve quickly is a customer who either cancels and reorders or simply gives up — a quiet loss of the add-on revenue they were trying to hand you. The point of self-service isn't only convenience; it's recovering revenue and margin that the native workflow leaks.

Does this work with discounts and promotions?

It should, and it's exactly where the manual and API routes are weakest — recall that an API PUT wipes discounts on edited line items. A purpose-built edit layer recalculates the order correctly, preserving existing promotions and applying tax to the added item, so a customer adding to a discounted order doesn't lose their discount or get mischarged. Verify this behavior on any tool you evaluate; it's the difference between a clean add and a support ticket about a broken total.

Which option to choose

For a rare one-off, a payment link (Option 2) is fastest. If you're a developer with a controlled integration, the API (Option 3) can work with care. But if "can you add one more?" is a steady stream, Option 4 is the only one that removes the work instead of relocating it — customers self-serve, you collect the money correctly, and you capture upside in the process. That's what OrderEdit.io adds to BigCommerce, from $39/mo with a 21-day free trial.