WooCommerce ships with six built-in product types: simple, grouped, external/affiliate, variable, subscription, and virtual. These cover most e-commerce scenarios, but they do not cover all of them. If your store sells rental products with date-based pricing, event tickets with seat allocation, configurable bundles assembled to order, or service retainers billed by hours, none of the native types map cleanly to your business model. The fix is a custom product type.
Custom product types in WooCommerce are first-class extensions of the core product system. They inherit WooCommerce’s order management, tax calculation, inventory, and REST API, you only write the code that makes your product type different from the defaults. This guide walks through the complete implementation: the PHP class, type registration, admin UI, frontend templates, cart handling, and REST API support.
How WooCommerce Product Types Work
Every WooCommerce product is a WordPress post with post_type = product. The product type is stored as a term in the product_type taxonomy. When WooCommerce instantiates a product object, it reads the term, maps it to a PHP class via the woocommerce_product_class filter, and returns an instance of that class.
The class hierarchy is: WC_Data → WC_Product → WC_Product_YourType. You extend WC_Product (or one of its subclasses like WC_Product_Simple) and add whatever properties and methods your type needs. WooCommerce handles storage, retrieval, and caching through the parent class; you focus on business logic.
Custom product meta is stored in WordPress postmeta, read and written via the get_prop/set_prop pattern inherited from WC_Data. This pattern handles caching, dirty tracking (only write changed values), and the context system ('view' vs 'edit' contexts for REST API output). Using get_prop/set_prop correctly is what distinguishes a well-architected custom product type from a fragile one built on direct postmeta calls.
Step 1: Define the Product Type Class
The class definition establishes the type identifier, declares custom properties, and implements getters and setters. Our example builds a “Rental” product type that stores a rental period (days per booking unit) and calculates price based on the number of days a customer selects.
The get_extra_data_keys() method is critical. It tells WooCommerce’s data store which postmeta keys to read when the product is loaded. Without this, get_rental_period_days() will always return the default value because the data store never loads the meta from the database. Any custom property that maps to postmeta must be included in this method’s return array, using the property name without the underscore prefix (WooCommerce prepends _ when reading from postmeta).
Step 2: Register the Product Type
Registering the type with WooCommerce requires three hooks: load the class file before WooCommerce needs it, add the type to the product type selector dropdown, and map the type slug to the class name for instantiation.
The show_if_rental CSS class on the product data tab controls which admin UI panels are visible for the rental product type. WooCommerce uses a JavaScript-based show/hide system in the product editor: each data tab and panel has CSS classes that match product type slugs (e.g., show_if_simple, show_if_variable). Adding show_if_rental to your custom tab tells WooCommerce’s admin JS to show it only when the Rental product type is selected. You will need a small JavaScript snippet or CSS rule to make this work if WooCommerce’s default JS does not pick it up automatically, test in the admin after registration.
Step 3: Build the Admin Data Panel
The admin product editing interface is where store managers configure rental-specific options. WooCommerce’s product data panels use a tab-and-panel layout with built-in helper functions for consistent field rendering.
WooCommerce’s woocommerce_wp_text_input(), woocommerce_wp_select(), and woocommerce_wp_checkbox() helper functions render consistently styled form fields that match the native WooCommerce admin UI. Use these instead of raw HTML to ensure your fields look native and handle the description tooltip pattern correctly.
Sanitize all field values on save. The example uses absint() for a numeric field; use sanitize_text_field() for strings, wc_format_decimal() for prices, and wc_clean() for general input. Never use update_post_meta() with raw $_POST values.
Step 4: Cart and Checkout Handling
The cart is where custom product type logic has the most impact on the customer experience. For a rental product, the cart needs to collect the rental duration from the customer, calculate the total price based on duration, and display the rental details in the order summary.
The woocommerce_before_calculate_totals hook runs before WooCommerce calculates cart totals on every cart update. This is the correct place to modify cart item prices dynamically, do not use woocommerce_cart_item_price for this, which only affects display. The price set in before_calculate_totals is the price used for tax calculation, shipping, and order totals.
The rental days value must survive the full cart-to-order lifecycle: added in woocommerce_add_cart_item_data, preserved through cart serialization, used in price calculation, displayed in cart item meta, and saved to order item meta. If any step in this chain is missing, the data is lost. The woocommerce_checkout_create_order_line_item hook is the handoff point from cart data to order data, without it, the rental duration will not appear on the order or in the admin.
Step 5: Frontend Product Page Template
WooCommerce’s frontend product page uses template files that can be overridden per product type. The standard flow: WooCommerce looks for content-single-product.php and includes hook-based action templates inside it. To add rental-specific UI (a duration selector, a date picker), hook into the product page actions at the right priority.
/**
* Add a rental duration input to the product page for rental products.
* Hooks into woocommerce_before_add_to_cart_button, just before the Add to Cart button.
*/
add_action( 'woocommerce_before_add_to_cart_button', function(): void {
global $product;
if ( ! $product || 'rental' !== $product->get_type() ) {
return;
}
$period = $product->get_rental_period_days();
$price = (float) $product->get_price();
?>
For more complex product page UIs (date range pickers, seat selectors, configuration builders), enqueue a dedicated JavaScript file that enhances the form fields after DOM load. Keep the PHP template simple, output the data attributes and initial values that JavaScript needs, then let client-side code handle interactivity. This separation keeps the PHP template maintainable and allows the frontend to evolve independently.
REST API Support
WooCommerce's REST API exposes products at /wc/v3/products. Custom product type meta is not included in the default API response unless you register it explicitly. Use the register_rest_field() function to add your custom data to the product endpoint.
/**
* Add rental_period_days to the WooCommerce REST API product response.
*/
add_action( 'rest_api_init', function(): void {
register_rest_field(
'product',
'rental_period_days',
array(
'get_callback' => function( array $product_data ): int {
$product = wc_get_product( $product_data['id'] );
if ( $product && 'rental' === $product->get_type() ) {
return $product->get_rental_period_days( 'view' );
}
return 0;
},
'update_callback' => function( int $value, WP_Post $post ): void {
$product = wc_get_product( $post->ID );
if ( $product && 'rental' === $product->get_type() ) {
$product->set_rental_period_days( absint( $value ) );
$product->save();
}
},
'schema' => array(
'description' => __( 'Number of days per rental unit.', 'my-plugin' ),
'type' => 'integer',
'context' => array( 'view', 'edit' ),
),
)
);
} );With this registration, rental_period_days appears in the API response for rental products and can be updated via a PATCH request. Headless storefronts, mobile apps, and external integrations that consume the WooCommerce API will have access to your custom type's data through the standard API interface.
Handling Shipping and Tax for Custom Types
Custom product types inherit WooCommerce's shipping and tax systems by default. If your product type should never generate shipping (services, digital rentals, event tickets), mark it as virtual by overriding the is_virtual() method in your class:
public function is_virtual(): bool {
return true; // Rental products have no physical shipping.
}For tax, rental products often have different tax treatment than physical goods, some jurisdictions exempt service rentals from sales tax that applies to product sales. WooCommerce's tax class system handles this: set the product's tax_class property to a custom tax class you define in WooCommerce → Settings → Tax. This is done per-product in the admin or programmatically via set_tax_class(). The custom product type class can override the default tax class by setting it in the constructor if all instances of the type should use the same class.
Testing Custom Product Types
Custom product types require testing across the full purchase lifecycle. Run through these scenarios after implementation:
- Admin creation: Create a rental product in the WooCommerce admin. Confirm the Rental Options tab appears, the custom field saves correctly, and the product displays as "Rental product" in the product list.
- Frontend display: Visit the product page and confirm the duration selector renders correctly for rental products but not for other product types.
- Add to cart: Add a rental product with a custom duration. Confirm the cart item shows the rental duration in item meta and the price reflects the correct multiple.
- Checkout: Complete a test order. Confirm the order line item includes rental duration meta and the order total is calculated correctly.
- Admin order review: View the completed order in WooCommerce admin. Confirm rental duration appears in the order item details.
- REST API: Request
/wp-json/wc/v3/products/{id}for a rental product. Confirmrental_period_daysappears in the response.
Also test edge cases: adding a rental product quantity greater than 1, applying a coupon to a rental product, and placing an order that mixes rental and standard product types. The mixed-cart scenario is where cart price calculation hooks most commonly produce unexpected results if the type check in woocommerce_before_calculate_totals is not correct.
WooCommerce Blocks Compatibility
The modern WooCommerce checkout uses block-based templates that replace the classic shortcode checkout. Custom product types need to declare compatibility with these blocks to prevent checkout errors. WooCommerce 8.x introduced a feature flag system for block compatibility; declaring your product type compatible ensures it works with the Cart Block and Checkout Block without fallback to the classic shortcode experience.
// Declare cart and checkout blocks compatibility for your custom product type.
add_action( 'before_woocommerce_init', function(): void {
if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
\Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility(
'cart_checkout_blocks',
__FILE__,
true
);
}
} );Beyond the compatibility declaration, verify that your add-to-cart logic works with the Store API. The Checkout Block uses the Store API (/wp/v2/wc/store/v1/cart) rather than the classic WooCommerce cart system. If your product type uses custom woocommerce_add_to_cart_handler_* hooks or overrides the add-to-cart template, test the full flow with the Checkout Block enabled. Some classic hooks do not fire in the Store API path, if your rental days are collected via a custom form field, verify that the field data reaches the Store API's add-to-cart endpoint via the woocommerce_store_api_add_to_cart_data filter.
Custom Data Stores
For high-volume stores or custom product types with complex data structures, WooCommerce's data store abstraction allows you to store product data in custom database tables rather than postmeta. Custom data stores extend WC_Product_Data_Store_CPT and override its read, create, update, and delete methods to use your table schema.
Custom data stores are justified when: your product type has many properties (postmeta lookups for 20+ keys per product are inefficient at scale), you need to query products by custom properties with performant SQL (postmeta joins are slow for complex queries), or you want to enforce a strict schema with foreign keys and constraints.
// Register a custom data store for the rental product type.
add_filter( 'woocommerce_data_stores', function( array $stores ): array {
$stores['product-rental'] = 'WC_Product_Rental_Data_Store';
return $stores;
} );For most custom product types with fewer than 10 custom properties, the default postmeta data store is adequate. The overhead of maintaining a custom data store, schema migrations, table creation on plugin activation, handling WordPress multisite, is only justified when the query performance gain is measurable. Profile first with a tool like Query Monitor before building a custom data store as a premature optimization. If you find that product queries are slow, review WooCommerce's Store API caching patterns as a first optimization before adding custom tables.
Unit Testing Custom Product Types
Custom product types require targeted unit tests for the property system, price calculation logic, and cart handling. WooCommerce provides a PHPUnit test bootstrap in its tests/ directory that sets up a working WooCommerce environment for testing.
The most valuable tests for a custom product type are: property getter/setter round-trips (confirm that set_rental_period_days(5) followed by get_rental_period_days() returns 5 and that the value persists after $product->save() and a fresh wc_get_product() call), cart price calculation (confirm that the before_calculate_totals hook multiplies price correctly for various day counts), and type instantiation (confirm that wc_get_product($id) returns a WC_Product_Rental instance for rental products, not a generic WC_Product).
Also write integration tests for the admin save path: use WP_UnitTestCase to create a product via the WooCommerce product factory, update it via the woocommerce_process_product_meta hook as if the admin form submitted, and confirm the meta value was saved and sanitized correctly. This catches the common bug where postmeta keys use inconsistent prefixes between the save hook and the data store read path.
When to Use a Custom Product Type vs. Custom Fields
Not every non-standard product scenario requires a custom product type. Before building a full type extension, evaluate whether custom product meta fields on an existing type (typically Simple) can cover the requirement.
Use a custom product type when: the product's price calculation logic differs from the standard model (rental duration, seat count, hours consumed), the product requires unique add-to-cart behavior (date selection, configuration building), or the product type needs to be excluded from operations that apply to other types (e.g., bulk discount rules that should not apply to rentals).
Use custom fields on Simple products when: you are only adding display data (material, dimensions, care instructions), the field affects display but not pricing or cart behavior, or the store only has a handful of affected products and a full type is disproportionate.
The technical cost of a custom product type, class definition, registration, admin panel, cart handling, REST API support, is justified when the type's behavior genuinely differs from any existing type. If a Simple product with two custom meta fields covers the requirement, that is the right solution. Custom types are powerful but they add surface area to maintain across WooCommerce core updates. For a comprehensive look at WooCommerce's data architecture that custom types plug into, the WooCommerce Store API developer guide covers the full data model and how custom types integrate with the modern block-based checkout. For checkout-specific concerns when using custom types with the new checkout blocks, the checkout blocks migration guide is required reading.
Wrapping Up
Custom WooCommerce product types let you model business scenarios that the built-in types do not support without bolting workarounds onto Simple or Variable products. The architecture is well-designed: extend one class, hook into three registration points, and WooCommerce's order management, REST API, and admin infrastructure work with your type automatically.
The implementation pattern in this guide, class with get_prop/set_prop, registration with three hooks, admin panel with WooCommerce helpers, cart handling with before_calculate_totals, REST API with register_rest_field, is the correct approach for any custom type regardless of the specific business logic. Start with the rental example here, then adapt the property names, admin fields, and price calculation logic to your specific product model.
Compatibility with WooCommerce High-Performance Order Storage
WooCommerce 8.2 introduced High-Performance Order Storage (HPOS), which moves orders from WordPress posts to custom database tables. Custom product types are generally unaffected by HPOS because products remain in the wp_posts table, HPOS only changes order storage. However, if your custom product type reads order data during cart calculation or in post-purchase hooks, verify that your code uses WooCommerce's order abstraction layer (wc_get_order(), WC_Order methods) rather than direct post queries. Direct get_post() calls for orders break when HPOS is enabled because orders no longer exist as posts.
Declare HPOS compatibility explicitly in your plugin's or theme's initialization code, even if your custom product type does not directly interact with orders. Stores with HPOS enabled will see compatibility warnings in WooCommerce → Status for any extension that has not declared compatibility. The declaration is a single function call in a before_woocommerce_init hook that takes less than a minute to add and prevents stores from being blocked from enabling HPOS because of your extension.
Real-World Product Types to Build
The rental product example in this guide demonstrates the architecture, but the same pattern applies to a wide range of custom types. Here are common scenarios where a custom product type is the right solution:
Event tickets: a ticket product type stores event date, venue, and available seat count. The add-to-cart handler checks seat availability before adding, the cart displays event details in item meta, and the REST API exposes event data for ticketing integrations. The key difference from Simple products is that stock management is per-event-date, not a single inventory count.
Configurable bundles: a bundle product type stores a list of component products and their quantity rules (minimum, maximum, optional vs required). The cart handler adds component products as separate line items linked to the parent bundle. The REST API exposes the bundle configuration for headless storefronts that need to render component selectors.
Service retainers: a retainer product type stores hours-per-month, rate-per-hour, and billing cycle. The checkout handler creates a WooCommerce Subscription for recurring billing. The REST API integrates with time-tracking tools that deduct hours from the retainer as work is completed. This pattern is more common in B2B WooCommerce stores and requires the WooCommerce Subscriptions plugin for the recurring billing component.
Each of these types maps directly to the pattern established in this guide. The class, registration, and admin panel structure are identical; only the properties, price calculation, and cart handling differ. For architectural decisions on when to use custom types versus standard WooCommerce features, the existing custom product types overview on this site is a useful complement to the implementation detail covered here.
Across all of these examples, the underlying principle is the same: WooCommerce's product type system gives you clean extension points without requiring you to modify core files. Your custom type sits alongside the built-in types as an equal participant in WooCommerce's product lifecycle, order processing, and admin interface, without any hacks or overrides that will break on the next WooCommerce release.
