Adding a fee to the Shopify cart, without a product

Why there is no native cart fee #

Shopify has no general-purpose way to add money to a cart that is not attached to a product. A Shopify staff member stated it plainly on the developer forums in June 2025: the official Function APIs “only allow you to reduce prices or block/validate, but not to add a fee.” That single sentence explains why an entire app category exists.

What Shopify does ship is three narrow mechanisms, each bolted to something else. None of them generalises.

Notice the shape of that table. Shopify clearly can render a money line in checkout that is not a product; tipping proves it. It just exposes exactly one, and hardcodes it.

What the hidden-product hack actually breaks #

The hidden-product hack is the most widely shipped Shopify fee workaround, and it is a product masquerading as a charge. You create a product called “Handling Fee” priced at the fee amount, leave it available to the Online Store channel (cart JavaScript cannot add a variant that is not), hide it everywhere you can, and add it to the cart with JavaScript when a condition is met. It works, in the narrow sense that money arrives. Then it leaks.

The leaks are not theoretical. A product is a product everywhere in Shopify, so every system that reads products picks it up:

• It appears where products appear. Automated collections with rules like “price is less than $5” will scoop it up. Internal search can surface it. Anything that generates a feed from the catalogue, including Google Shopping, has to be told about it explicitly.
• It distorts your reporting. Every fee-bearing order now contains an extra unit sold. “Products sold”, units per transaction, and best-seller rankings all shift, and the distortion grows with fee volume.
• It can change shipping cost. This is the expensive one. If the fee product has a weight and is marked as requiring shipping, it is fed into carrier-calculated rates as real cargo. A fee designed to recover cost quietly adds cost.
• The customer can edit it. It is a line item like any other, so a shopper can change its quantity or remove it entirely from the cart page unless you write code to stop them.
• Discounts treat it as merchandise. A 20%-off-everything code discounts your handling fee too.

Two of those five follow the fee no matter how it is built. A fee that becomes a real line item through the supported route is still caught by order-level discounts unless the discount logic excludes it, and it still adds a unit to the order. What the supported route actually fixes is the storefront exposure, the shipping weight and the editability; the discount and reporting behaviour come back later in this article.

Every one of these is fixable with enough guard code. That is the actual argument against the hack: you do not ship it and walk away, you ship it and then maintain a growing list of exceptions in collection rules, feeds, reports and shipping settings. Forever.

Can Shopify Functions add a line item to a cart? #

Yes, through the Cart Transform API's lineExpand operation, though the mechanism is a side effect rather than a designed feature. This is worth stating clearly because the highest-ranking answer to this question is stale: a Shopify staff reply from April 2023 says “There is no way to do this with Functions currently.” That predates the Cart Transform release that made it possible, and merchants are still finding it.

Cart Transform exposes three operations: lineExpand, linesMerge and lineUpdate. The one that matters takes a single cart line and replaces it with several component lines, each of which can carry its own fixed per-unit price:

The shape of a fee, expressed as an expand operation

{
  "lineExpand": {
    "cartLineId": "gid://shopify/CartLine/1",
    "title": "Ceramic mug",
    "expandedCartItems": [
      {
        "merchandiseId": "gid://shopify/ProductVariant/111",
        "quantity": 1,
        "price": { "adjustment": { "fixedPricePerUnit": { "amount": "24.00" } } }
      },
      {
        "merchandiseId": "gid://shopify/ProductVariant/999",
        "quantity": 1,
        "price": { "adjustment": { "fixedPricePerUnit": { "amount": "2.99" } } }
      }
    ]
  }
}

The original item keeps its price. A second component, the fee variant, is priced independently. Because component prices are arbitrary, the cart total goes up. This is a bundling API being used as a fee API, and Shopify's own documentation ships “add gift wrapping to cart items” as the worked example, so the usage is sanctioned even if the naming is not.

One thing to be straight about: variant 999 in that example is a real product variant. lineExpand cannot conjure a line from nothing, and Shopify returns component_merchandise_not_found when the ID does not exist. A fee app, ours included, keeps a hidden charge product in the store to serve as that component. The difference from the hack is everything around it: the charge variant never needs publishing to a sales channel because the function references it server side, it is created non-shippable so it cannot touch carrier rates, its price comes from the function at cart time rather than from the product record, and the shopper cannot edit or remove it as a line of its own. “Without a product” means without a product your storefront sells, not without a variant record in Admin.

The payoff is that the result is a real line item. It shows in the cart, survives to checkout, lands on the order and the receipt, and appears in payouts like anything else. Nothing is hidden in a subtotal.

Do you need Shopify Plus to add a cart fee? #

No, and the widespread claim that you do is wrong in a specific, checkable way. Several published guides state that Cart Transform functions require Shopify Plus. Shopify's documentation gates only one of the three operations, and it is not the one fee apps use.

That distinction is the whole reason fee apps are built on lineExpand rather than the more obvious lineUpdate. It is also why installing an App Store fee app works on Basic, while building the identical function yourself as a custom app does not.

You do not have to guess, either. The Admin API exposes the gate directly: ShopFeatures.cartTransform returns eligibleOperations with three booleans (expandOperation, mergeOperation, updateOperation) telling you exactly what a given shop may do before you write any code.

Why percentage fees are harder than they look #

Cart Transform's percentage adjustments can only move prices down. The only percentage field the API exposes is percentageDecrease, and its validation error, invalid_price_adjustment_percentage_decrease, pins it to discounts: “the percentage decrease value must be less than or equal to 100.” A percentage increase is not so much rejected as inexpressible.

So a “2.9% + $0.30” surcharge is not a percentage operation at all. The function has to read the line costs, compute the amount itself, and emit the result as a fixed per-unit price. Percentage fees are arithmetic you own, not a flag you set, which is why they tend to sit in paid tiers.

Multi-currency compounds it. The function's input exposes presentmentCurrencyRate, and every output is processed in the presentment currency. A fee denominated in shop currency has to be multiplied by that rate by hand. When a fee app advertises “Shopify Markets support”, this is the work being described: real, necessary, and not something the platform does for you.

What a cart fee collides with #

A fee line does not live alone in the cart, and the collisions are the part that surprises people after launch. Shopify runs functions in a fixed order: cart transform first, then cart line discounts, then fulfillment and delivery methods, then delivery discounts, then payment customizations, with validation last.

Four consequences follow directly from that ordering and from the API's own limits:

• Discounts see the fee. Because the transform runs first, the fee line already exists when discounts are calculated. An order-level “all products” code will discount it unless the discount logic excludes that line deliberately.
• Apps can silently cancel each other. Each app gets one cart transform, but several apps' transforms all run, and collisions resolve by activation time, and the first activated wins. A store running a bundle app and a fee app can lose the fee, and which one survives depends on install order.
• Subscriptions are excluded. Shopify rejects lineExpand, linesMerge and lineUpdate outright when a selling plan is present on the line. You cannot attach a Cart Transform fee to a subscription item, and the same compatibility table lists pre-order and try-before-you-buy as unsupported and POS as only partially supported, so deferred and in-person flows cannot be counted on to carry the fee either.
• Failure mode is a choice you make. The activating mutation takes a blockOnFailure flag. Leave it false and a crashing function means fees silently stop being collected. Set it true and a bug in your function takes down checkout. Neither is comfortable; pick on purpose.

There are hard caps too: a maximum of 150 expanded cart items, and either all components carry prices or none do.

The consent rule that reshaped the category #

Since February 2025, Shopify's App Store requirements have forbidden apps from adding optional charges without explicit buyer consent. Requirements 1.1.9 and 5.6.5 carry identical text: apps “can't automatically add or pre-select optional charges to a buyer's cart that increase the total checkout price,” and may only add them “after displaying the additional cost in a manner that is clear to the buyer, and upon obtaining explicit buyer consent.”

Two further clauses, written for the post-purchase upsell section, show the pattern Shopify expects any optional charge to follow. Requirement 5.8.2 says the buyer “must be provided preset accept and decline options.” Requirement 5.8.8 says the price must update dynamically when quantity or variant changes. They bind post-purchase offers directly; read them as Shopify's clearest statement of what consent UI should look like. Non-compliance risks rejection or removal from the App Store.

In practice that settles a design argument that used to be contentious. An optional charge defaults to unchecked. The requirement's wording bans pre-selecting outright, so do not design a pre-ticked box and plan to collect consent afterwards. A pre-ticked fee is the pattern that App Store review and chargeback disputes punish alike.

Note the rule governs optional charges. A genuinely mandatory fee, such as a statutory bag charge or a bottle deposit, is a different compliance posture and is usually enforced with a validation function rather than a checkbox.

Build it or install an app? #

Build it if the fee logic is genuinely unusual and you have a developer who will still be there in a year. The function itself is the small part. The rest of the surface is what takes the time:

1. A Cart Transform function, plus the Admin mutation to activate it and the write_cart_transforms scope.
2. A theme app extension that renders the opt-in control and finds the cart in whichever theme the merchant is running, then keeps finding it after they change themes.
3. Consent UI that satisfies requirements 1.1.9 and 5.6.5, following the accept-and-decline and dynamic-price pattern of 5.8.2 and 5.8.8.
4. Currency conversion against presentmentCurrencyRate.
5. An admin surface for the rules, and reporting so someone can tell whether any of it is working.

If the fee logic is ordinary (handling, shipping protection, gift wrap, a rush charge, a seasonal surcharge), that is a solved problem and buying it back is the cheaper decision.

The honest version of the pitch: this article describes the mechanism, and TackOn is our implementation of it. If you would rather build your own, the sections above are the map. If you would rather not, that is what we sell.

Questions merchants actually ask #

Sources #

Every platform claim above traces to primary documentation or a linked staff answer. Where Shopify's docs and a vendor's marketing disagree, the docs win.

• Cart Transform API reference. Operations, plan gating, collision rules, limits and error codes.
• Shopify Functions overview. Public vs custom app plan requirements.
• CartTransformEligibleOperations. Querying a shop's eligibility.
• New buyer consent requirement and the App Store requirements. Clauses 1.1.9, 5.6.5, 5.8.2 and 5.8.8.
• Understanding shipping rates. The native handling fee and its limits.
• Checkout tipping. The one hardcoded non-product money line.
• cartTransformCreate mutation. The blockOnFailure flag and the write_cart_transforms scope.
• Staff answer on adding fees via Functions, June 2025. The quote in section 01.
• Staff answer on adding cart lines via Functions, April 2023. The stale reply corrected in section 03.
• TackOn guide to Shopify surcharges. Our own documentation of the implementation described here.