Stripe Product

The fields on a Product, and which ones reach your books

The Product object is short. Beyond its ID and timestamps, Stripe documents a name "meant to be displayable to the customer", a description for "a long form explanation of the product being sold", up to 8 images, up to 15 marketing features for pricing tables, metadata, a URL, and shipping fields (shippable and package_dimensions) for physical goods.

Four fields do most of the accounting work.

tax_code is the tax category ID for Stripe Tax. Stripe says Stripe Tax uses the tax code to calculate and collect sales tax during purchase, so it is the Product, not the Price, that decides whether an item is taxed as SaaS, an e-book or pet grooming, to use Stripe’s own examples.

unit_label is "a label that represents units of this product", up to 12 characters. When set, it is printed on receipts, invoices, Checkout and the customer portal, which is where a line reading 40 seats rather than 40 comes from.

statement_descriptor is narrower than its name suggests. Stripe says it is "only used for subscription payments", and that when several products are billed at once, "the first statement descriptor will be used". A one-off charge never reads it.

active is "whether the product is currently available for purchase". It is the archive switch, and it controls new sales only.

Product or Price: one test, and what it does to your invoices

Stripe’s catalog guidance gives four reasons to create a new Product rather than another Price: a distinct name on your pricing page, different features or entitlements, a different tax code, or a need to appear as a separate line item. It gives three reasons to add a Price to an existing Product instead: the same plan at a different billing interval, the same plan in a different currency, and a price change.

Its worked example is a SaaS business with Starter, Professional and Enterprise plans, each sold monthly and annually. The right model is three Products with two Prices each, not one Product with six Prices.

The reason is on the documents. Stripe warns: "Don’t attach prices for different tiers to a single product. Line items that share a product share its name and description on receipts and invoices. This means only the amount differs."

For anyone who has to report revenue by plan, the one-Product model is the expensive one. Every line says the same thing, so separating Starter revenue from Pro revenue means grouping by price ID or by amount. Amount breaks as soon as a discount or a price change lands. A Product per plan makes the plan visible on every line without any lookup at all.

What an invoice line keeps, and what it only points to

When you invoice with Prices, Stripe says the invoice "retrieves the product associated with the price and uses product.name when rendering the invoice as a web page or PDF". Checkout and Payment Links do the same: they compute the total from the Price and render the page from the Product’s name and image.

The invoice line item object records the result, not a copy of the catalog. Its pricing details carry two IDs, the price and the product, alongside the amount, currency, quantity and a description field Stripe describes as "an arbitrary string attached to the object".

That shape has a consequence people meet when they reconcile old periods. A Product’s name can be edited at any time through the update endpoint. If you look up the product ID from a two-year-old line today, you get today’s name, not the one the customer saw. The ID is the stable key. The name is a label that can move.

So when a revenue report has to be reproduced exactly, group by product ID and treat the name as a display value. A renamed plan and a new plan look identical in a name-based report and completely different in an ID-based one.

Archived is not deleted

Stripe keeps catalog history on purpose. Its guidance is direct: "In general, you can’t delete products or prices, you can only archive them." Archiving means setting active to false, and Stripe says it stores "the archived product and price information indefinitely to maintain records of past transactions."

The delete endpoint enforces the same rule. Deleting a Product "is only possible if it has no prices associated with it". Since the Dashboard requires at least one Price to save a Product, almost every Product you have ever sold through the Dashboard is archive-only.

Archiving changes what can happen next, not what already happened. Stripe says an archived Product cannot be added to new invoices or subscriptions, that existing subscriptions using it "remain active until they’re canceled", and that existing Payment Links using it are deactivated.

The practical reading for your books: a subscription can keep billing a Product that no longer appears in your active catalog. If a charge arrives for a plan you thought was retired, check the Archived tab before assuming it is an error.

Products you never created in the Dashboard

Not every Product on your account came from someone clicking Add product.

When an integration passes price_data to create a Checkout Session, Payment Link or Subscription, Stripe generates Price and Product objects for that transaction. Stripe notes that these Price objects are temporary and do not appear in the Dashboard’s product searches or lists, and that "the associated Product objects aren’t always temporary." Stripe also supports inline prices on subscriptions and invoices, created only through the API, for businesses that manage their catalog outside Stripe.

The symptom is a product ID on an invoice or charge that you cannot find by browsing your catalog. It is not missing data. It is a Product created by code, and it can still be opened directly by its ID.

An integration that creates Products this way can leave many more product IDs on an account than anyone created by hand. Each one is a separate ID to anything that groups revenue by product, so it is worth knowing which of your integrations do it.