TL;DR

Shopify Plus core charge implementation requires custom development using Shopify Functions, Checkout Extensibility, and webhook-based refund automation since no native deposit system exists.

The three core technical components are: a cart transform Function to apply the deposit, a Checkout Extensibility UI block for transparency, and a webhook-triggered backend that processes refunds when cores are received.

  • Shopify Functions replace legacy Shopify Scripts for custom surcharge logic and run serverlessly at the edge, making them the correct modern approach for dynamic core fee calculation.
  • Product metafields are the right architecture for storing core charge amounts, vehicle compatibility data, and refund eligibility rules at the SKU level.
  • B2B and wholesale core charge tiers require Shopify B2B price lists combined with custom Function logic that reads customer tags or company metafields to apply the correct deposit amount.
  • Multi-location core return tracking requires a webhook listener that updates order metafields when a return is processed at any location, feeding a unified liability ledger.
  • ERP integration is the final layer for enterprise automotive merchants; Shopify’s Admin API provides the order and refund data surface for middleware to sync core deposit status bidirectionally.

 

How to Implement Complex Core Charge Logic on Shopify Plus

Shopify Plus core charge implementation is a development problem before it’s anything else. The automotive merchants who try to solve it with a third-party app and a paired SKU eventually hit a ceiling, whether that’s at the B2B reconciliation layer, the POS return sync, or the YMM fitment mapping level. At that point, they need a developer and a plan.

This guide is written for that moment. It covers the full technical architecture for a custom Shopify Plus core charge system: how to calculate and apply the deposit using Shopify Functions, how to surface it transparently at checkout using Checkout Extensibility, how to automate refunds using webhooks and the Admin API, and how to connect the whole system to ERP and B2B catalog data. Think of it as a Shopify Plus development guide for the deposit layer of an automotive ecommerce stack. Every section is implementation-focused, not conceptual.

If you’re still evaluating whether to build custom or buy an app, the Shopify core charge app comparison covers that decision in detail. This guide assumes you’ve made the call to build.

Fyresite’s Shopify Plus development team has deployed this architecture across automotive stores with YMM fitment catalogs, multi-location POS, and B2B wholesale accounts. What follows is the approach that works at scale.

Shopify Plus Scripts for Dynamic Core Fee Calculation

Shopify Scripts are deprecated. If a developer or agency is quoting you a core charge implementation built on Shopify Scripts, that’s a red flag: Scripts are Shopify’s legacy Plus-only customization layer, sunset in favor of Shopify Functions. The correct modern approach is Functions, and here’s how they apply to the Shopify Plus core charge workflow.

Shopify Functions: what they are

Shopify Functions are serverless WebAssembly modules that execute within Shopify’s infrastructure at specific points in the commerce lifecycle. For core charge purposes, the relevant Function type is the Cart and Checkout Validation Function, specifically the cart transform extension that allows you to add, remove, or modify line items before checkout renders.

How dynamic core fee calculation works with Functions

The Function reads metafields attached to each cart line item. If a product has a core_charge_amount metafield with a value (e.g., 45.00), the Function generates an additional line item representing the core deposit and attaches it to the cart. The Function runs on every cart update, so if the customer changes quantities, the deposit scales accordingly.

// Simplified Function logic (AssemblyScript)

export function run(input: FunctionRunResult): CartTransform.FunctionResult {

  const operations = [];

  

  for (const line of input.cart.lines) {

    const coreAmount = line.merchandise.product.metafield?.value;

    if (coreAmount) {

      operations.push({

        expand: {

          cartLineId: line.id,

          title: “Core Deposit (Refundable)”,

          price: { adjustment: { fixedPricePerUnit: { amount: coreAmount, currencyCode: “USD” } } }

        }

      });

    }

  }

  return { operations };

}

 

Metafield schema for core charges

Set up a product metafield namespace and key at the store level:

  • Namespace: core_charge
  • Key: deposit_amount
  • Type: money

This allows merchants to set per-SKU deposit amounts through the Shopify admin or via bulk import, and allows the Function to read them at runtime without hardcoding values. For YMM fitment merchants, core charge metafields should be set at the variant level so deposit amounts can differ by vehicle application even within the same product.

Enterprise Solution for Managing Core Charges on Shopify Plus

At the enterprise level, the Shopify Plus core charge system is not a checkout feature; it’s a financial instrument that needs to integrate with order management, inventory, accounting, and customer service systems. The architecture has five layers:

Layer 1: Product data (metafields) Core charge amounts, return window definitions, condition requirements, and vehicle fitment bindings all live as product and variant metafields. This is the source of truth the Function, the storefront, and the ERP all read from.

Layer 2: Checkout (Functions + Extensibility) The cart transform Function applies the deposit. The Checkout Extensibility UI block surfaces it transparently to the customer. Both components are stateless: they read metafield data and render accordingly.

Layer 3: Order management (webhooks + Admin API) When an order is placed, a webhook fires to the backend listener. The Shopify core charge API surface here is the orders/paid webhook combined with the Admin API’s order metafields endpoint. The listener creates a core deposit record in your database, tied to the order ID, the deposit amount, and the return window expiry date. This is the liability record that everything downstream references. The full Shopify refundable deposit workflow runs through this record: create on purchase, update on return, close on refund or forfeiture.

Layer 4: Return processing (RMA + webhook) When the RMA platform marks a core as received and inspected, a webhook fires to the backend. The listener validates the core deposit record, checks the return window, and triggers a refund via the Shopify Admin API.

Layer 5: Accounting sync Refunded deposits are posted to the liability account. Forfeited deposits (expired window, failed inspection) are converted to revenue. The sync happens via middleware connecting Shopify’s Admin API to the ERP or accounting platform.

For merchants scaling into this architecture, Fyresite’s Shopify maintenance and support team provides ongoing monitoring of webhook health, Function versioning, and API rate limit management. These systems require active maintenance, not just a one-time build.

Core Charge Workflow Using Shopify Plus Checkout Extensibility

Checkout Extensibility is the approved path for customizing the Shopify Plus checkout on the current infrastructure. Legacy checkout.liquid is deprecated for new implementations. Any core charge workflow built on the new checkout must use Checkout Extensibility.

What Checkout Extensibility allows for core charges:

Shopify checkout extensibility core charge display includes a custom UI block that explains the refundable deposit to the customer inline at checkout, a banner or callout that states the return window and condition requirements, and a collapsible section that links to the full core charge policy. Shopify deposit automation at the display layer means this context renders automatically whenever a core deposit line item is present in the cart.

What it does not allow:

  • Direct modification of checkout pricing logic (that lives in the Cart Transform Function)
  • Native conditional refund logic
  • Access to external APIs at render time (all data must come from Shopify metafields or the session)

Implementation approach:

Build a Checkout UI Extension using Shopify’s @shopify/ui-extensions-react library. The extension renders in one of the defined placement slots (e.g., purchase.checkout.cart-line-item.render-after) and reads the core charge metafield from the cart line to display relevant deposit information.

import { reactExtension, Text, BlockStack, useCartLines } from “@shopify/ui-extensions-react/checkout”;

 

export default reactExtension(“purchase.checkout.cart-line-item.render-after”, () => <CoreChargeNotice />);

 

function CoreChargeNotice() {

  const lines = useCartLines();

  const coreLines = lines.filter(line => line.attributes.find(a => a.key === “_is_core_deposit”));

  

  if (!coreLines.length) return null;

  

  return (

    <BlockStack>

      <Text>This order includes a refundable core deposit. Return your old part within 30 days for a full refund.</Text>

    </BlockStack>

  );

}

 

This approach keeps the checkout explanation contextual: it only renders when a core deposit line is present. For automotive stores with large mixed catalogs, this prevents the notice from appearing on orders that don’t include core-eligible parts.

Advanced Core Fee Rules by Customer Type on Shopify Plus

Not all customers should receive the same core charge treatment. B2B wholesale accounts, retail D2C buyers, and internal or employee accounts may each need different deposit amounts, refund windows, or even core charge exemptions. Shopify Plus supports this through a combination of customer tags, company metafields (on B2B), and Function input variables.

Customer tag-based rules:

The cart transform Function can read the customer’s tags from the Function input object. Common rule patterns:

  • core_exempt: Customer is a remanufacturer or certified rebuilder; core charge is waived
  • wholesale_tier_1: Deposit amount is reduced (dealer-level pricing)
  • fleet_account: Extended 90-day return window applied via order metafield

const customerTags = input.cart.buyerIdentity?.customer?.tags ?? [];

const isCoreExempt = customerTags.includes(“core_exempt”);

 

if (isCoreExempt) {

  // Skip core charge attachment

  return { operations: [] };

}

 

B2B company metafields:

For Shopify B2B merchants, customer companies have their own metafield namespace. Core charge rules can be stored at the company level:

  • b2b.core_charge_multiplier: A decimal multiplier applied to the standard deposit (e.g., 0.75 for a 25% discount on the deposit amount)
  • b2b.return_window_days: Override the default return window for this account

The Function reads these metafields and applies account-specific logic before attaching the deposit line item. This allows a single Function to handle both D2C and B2B pricing without separate code paths.

B2B Core Charge Pricing Tiers on Shopify Plus Stores

B2B core charge pricing tiers add complexity at two levels: the checkout calculation and the refund reconciliation. Both need distinct handling for wholesale accounts.

Checkout tier logic:

Standard Shopify B2B price lists handle part pricing by customer segment. Core charge amounts, however, are not standard price list fields; they live in metafields. The Function must read both: the price list for the part price, and the metafield for the deposit. These are separate data sources with separate query paths in the Function input.

Refund reconciliation for B2B:

D2C refunds go back to the payment method. B2B wholesale refunds often need to go to a credit ledger instead. A shop account on net-30 terms doesn’t receive a card refund when they return a core; the credit is applied against their open invoice balance.

This requires a backend system outside of Shopify’s native refund flow:

  1. The RMA platform marks the core as received
  2. The webhook fires to the backend listener
  3. The backend checks whether the customer is a B2B company account
  4. If B2B: posts a credit memo to the ERP or accounting platform against the customer’s balance
  5. If D2C: triggers a Shopify Admin API refund to the original payment method

The B2B features available on all Shopify plans post-2023 introduced company accounts and metafields that make this architecture much cleaner than it was previously. Merchants who built their B2B core charge logic before those features shipped should evaluate whether a rebuild on the new B2B infrastructure is warranted.

Wholesale Auto Parts Core Charge Management on Shopify Plus

Wholesale automotive operations add a layer of complexity around catalog scale and order volume that consumer D2C stores don’t encounter. A wholesale buyer ordering 200 alternators on a single PO generates 200 core deposit records that all need to be tracked, reconciled, and potentially refunded independently as cores come in over the following weeks.

Order-level vs line-item-level deposit tracking:

At wholesale volume, tracking deposits at the order level is insufficient. Each line item in a wholesale PO may have a different core deposit amount, a different return window (if the customer negotiated extended terms on certain SKUs), and a different return status. The backend database schema needs to store deposits at the line-item level, keyed to both the Shopify order ID and the line item ID.

Bulk return reconciliation:

Wholesale accounts rarely return cores one at a time. A typical pattern is a monthly or quarterly “core sweep” where the dealer ships back a box of mixed cores from multiple invoices. The RMA or returns platform needs to support multi-order return reconciliation: one return shipment maps to line items across dozens of orders. Few off-the-shelf apps handle this; it almost always requires custom middleware.

Partial PO fulfillment:

If a wholesale PO is partially fulfilled (some line items ship immediately, others are backordered), the core deposit logic needs to apply at the time of fulfillment, not at the time of order placement. The orders/fulfilled webhook is the right trigger for deposit record creation in this scenario, not orders/paid. This is one of the more common implementation errors in wholesale core charge builds.

For merchants with high-volume wholesale operations also managing data integrations with distributors, the auto parts data structure guide is directly relevant to how SKU-level core charge metafields should align with supplier catalog data.

Can Shopify Plus Handle Multi-Location Core Charge Returns?

Multi-location core return tracking is one of the more technically demanding requirements in an automotive Shopify Plus build, and it’s often underspecified until a store opens a second physical location and the reconciliation breaks.

The problem:

A customer buys a remanufactured starter online. They want to return the core in-person at a retail counter. The return happens through Shopify POS at a specific location. The original order exists in the online channel. Shopify POS and the online channel share inventory but maintain separate transaction contexts. Bridging the core deposit record from the online order to the POS return requires explicit webhook handling.

The architecture:

  1. Online order placed: Backend creates a core deposit record keyed to order ID, line item ID, and customer ID. A unique return reference code is generated and emailed to the customer.
  2. Customer arrives at counter: Staff enters the return reference code into the POS or a companion admin app. The system pulls the core deposit record.
  3. Core inspected: Staff marks the core as accepted or rejected in the admin interface.
  4. Refund triggered: If accepted, the backend calls the Shopify Admin API to issue a refund on the original online order. The POS transaction is logged as a zero-dollar exchange for the core return.
  5. Liability cleared: The core deposit record is marked as refunded and removed from the outstanding liability ledger.

Shopify POS does not natively support this flow. The companion admin interface for step 2 and 3 is custom-built, typically as a Shopify Admin app or an embedded POS UI extension. For merchants evaluating POS hardware alongside this implementation, the Shopify POS hardware setup guide covers the physical setup layer that this digital architecture sits on top of.

Shopify Plus Customization for Taxable Core Fees and Refunds

Tax handling for core charges varies by state, and Shopify’s native tax engine does not have a built-in “refundable deposit” tax category. Developers need to handle tax exclusion explicitly.

Making core deposits non-taxable:

The simplest approach is to set the core deposit line item as non-taxable at the product level. When the Function generates the deposit line, it can set taxable: false on the expanded line item. Shopify will respect this flag and exclude the deposit from tax calculation.

operations.push({

  expand: {

    cartLineId: line.id,

    title: “Core Deposit (Refundable)”,

    taxable: false,

    price: { … }

  }

});

 

State-specific tax rules:

Some states treat forfeited core deposits (ones where the customer never returns the core) as taxable income at the point of forfeiture rather than at the point of collection. This distinction requires accounting-level handling, not Shopify-level handling. The ERP or accounting platform needs to flag forfeited deposits and apply the appropriate tax treatment at period close.

Environmental fees and recycling fees:

Some automotive stores also collect Shopify environmental fees alongside or instead of core charges for certain part categories (lead-acid batteries being the primary example). Environmental fees in many states are mandated, non-refundable, and subject to their own tax and remittance rules entirely separate from core deposit handling. These should be implemented as a separate line item type with their own Function logic, not merged with the core charge flow.

Always consult a CPA with multi-state ecommerce experience before finalizing tax configuration. The implementation is straightforward; the compliance requirements are not.

Integrating ERP Core Charge Data With Shopify Plus Storefront

ERP integration is the last mile of a complete Shopify Plus core charge system and the layer that separates a working implementation from an auditable one. Without it, core deposit liability exists in your Shopify order data but not in your financial records.

Data flow architecture:

The integration runs bidirectionally:

  • Shopify to ERP: Core deposit records (amount, order ID, line item ID, return window, status) sync from the backend database to the ERP when a deposit is created, refunded, or forfeited.
  • ERP to Shopify: Customer credit balances for B2B accounts, return window extensions granted by the account team, and core condition approvals from the inspection team sync back into Shopify as order or customer metafields.

API surfaces used:

  • Shopify Admin API (Orders): Read order and line item data, trigger refunds via POST /orders/{id}/refunds
  • Shopify Admin API (Metafields): Write deposit status and return window data to order metafields
  • Shopify Webhooks: orders/paid, orders/fulfilled, refunds/create for event-driven triggers
  • ERP API (NetSuite, QuickBooks, or custom): Write liability entries, credit memos, and forfeiture revenue postings

Middleware options:

For smaller implementations, a serverless function layer (AWS Lambda, Vercel Edge Functions) handles the webhook-to-ERP pipeline with minimal infrastructure overhead. For larger enterprises with existing iPaaS tooling (MuleSoft, Boomi), the Shopify-to-ERP connection fits within the existing integration framework.

The Shopify AWS infrastructure that Fyresite deploys for enterprise clients provides the serverless compute layer for webhook processing, the database for deposit record storage, and the monitoring stack that keeps the integration healthy over time.

Why Custom Core Charge Builds Outperform Apps at Scale

The merchants who start with a third-party core charge app and migrate to a custom build later almost universally say the same thing: they wish they had built custom sooner. The app works at low volume. The problems surface incrementally, a B2B account that needs a credit memo instead of a card refund, a POS return that doesn’t close the online order’s deposit record, a wholesale PO where the deposit fired at order creation instead of fulfillment, and by the time the technical debt is visible, the migration cost is significant.

Custom Shopify Functions give you control that no app can replicate. The deposit logic reads exactly the metafields you define, applies exactly the rules your operation requires, and integrates with exactly the systems your ERP and accounting team need. It also doesn’t disappear when an app developer decides to pivot their product or raise prices by 300%.

The Shopify Plus core charge API surface is mature enough now that a well-architected custom build is achievable in four to eight weeks of focused development. Functions, Checkout Extensibility, the Admin API, and webhooks together cover every layer of the deposit lifecycle.

The trade-off is real: apps launch in days, custom builds launch in months. But the operational ceiling on apps is also real. For merchants at $5M+ GMV with wholesale accounts, multiple locations, and a YMM fitment catalog, the ceiling is not a future problem, it’s a current one. A custom Shopify core charge system built on Functions and the Admin API is the only Shopify Plus auto parts solution that scales cleanly through B2B, multi-location POS, and enterprise ERP integration. The Shopify core refund process on a custom build is also more reliable at volume: no app dependencies, no third-party rate limits, no risk of an app deprecation breaking your refund queue. Build the system that fits the operation you’re running, not the one you started with.

Let’s Talk

If you’re at the point where an app isn’t cutting it and you need a proper Shopify Plus core charge system built, Fyresite has the development team and the automotive ecommerce experience to build it right. Start the conversation or review our automotive work to see what a production-grade implementation looks like. You can also submit a service request if you already know what you need.

Frequently Asked Questions About Shopify Plus Core Charge Implementation

How do you build a custom core charge workflow on Shopify Plus? 

A custom Shopify Plus core charge workflow requires three components: a cart transform Function that applies the deposit at checkout using product metafield values, a Checkout Extensibility UI block that explains the deposit to the customer, and a webhook-triggered backend that creates deposit records and processes refunds through the Admin API when cores are returned and inspected.

Can Shopify Plus support refundable core deposits? 

Shopify Plus supports refundable core deposits through custom development, not native features. The implementation uses Shopify Functions for deposit application, the Admin API for refund processing, and webhooks for automation triggers. Standard Shopify lacks the Plus-tier APIs and Functions access required for a fully automated refund workflow.

What APIs are needed for a Shopify core charge system? 

A complete Shopify Plus core charge API implementation requires the Admin API for order data access and refund processing, the Storefront API for metafield reads in headless contexts, webhooks for event-driven automation (orders/paid, orders/fulfilled, refunds/create), and the Functions API for cart-level deposit application. ERP integration adds a fifth API layer for accounting sync.

How do developers automate core charge refunds in Shopify? 

Automated core charge refunds on Shopify use a webhook listener that fires when an RMA platform updates core return status. The listener validates the deposit record, confirms the return window hasn’t expired, and calls the Admin API refund endpoint with the correct line item amount. Shopify Flow can serve as a no-code alternative for simpler automation paths.

What is the best way to implement core charges on Shopify Plus? 

The best Shopify Plus core charge implementation uses a cart transform Function for deposit application, product metafields for per-SKU deposit amounts, Checkout Extensibility for customer-facing transparency, and a webhook-to-Admin-API pipeline for refund automation. B2B merchants need additional logic for credit memo reconciliation instead of card refunds.

Can Shopify Checkout Extensibility handle core fees? 

Shopify Checkout Extensibility handles the display layer for core fees, surfacing deposit information and return policy details to the customer at checkout. It does not handle pricing logic; that lives in the cart transform Function. Together, the two components cover both the calculation and communication requirements for a transparent core charge checkout experience.

How do auto parts merchants customize core charge workflows in Shopify? 

Auto parts merchants on Shopify Plus customize core charge workflows through a combination of product metafields (storing deposit amounts and return window data), Shopify Functions (applying deposits at cart level), customer tags and company metafields (enabling B2B tier logic), and Shopify Flow or custom webhooks (automating refunds on core return). Each layer is independently configurable.

Which Shopify Plus features support advanced surcharge workflows? 

The Shopify custom surcharge workflow for core charges relies on four Plus-tier features: Shopify Functions for cart transform logic, Checkout Extensibility for UI customization, the Admin API for programmatic refund processing, and Shopify Flow for no-code automation. B2B on Shopify adds company metafields and price lists that extend the surcharge architecture to wholesale account management.