---
title: Transaction-based billing
slug: commerce-connect-15/docs/transaction-based-billing
docTags: 
createdAt: 2026-07-30T20:34:43.000Z
---

This page applies to transaction-based billing. Optimizely Commerce Connect clients on page-view-based billing should see [Deploy tracking script with CMS NuGet package](docId\:ml3n3zj1ceyt2V3eygrCZ).

## Transactions counted for billing

Optimizely defines a billing transaction as an order that has gone through the *convert-to-order* flow in Commerce Connect or its APIs in a production environment. This includes all instances when a user clicks **Order submit** on the checkout page in a production environment, and orders submitted to and processed in the order table by a headless API or other custom implementation.

:::hint{type="info"}
**Note**
Every order captured in the Commerce Connect production order database that passes through the `InProgress` order status is included in the total count of transactions.
:::

Updates, cancellations, and returns to orders that have already moved through the `InProgress` order status do not affect the total count of transactions.

### How transactions are captured

Optimizely reviews the client's order database daily and counts the number of lines in the order table. Before aggregating the transaction count, duplicate orders are removed by checking for unique order IDs. Each month's event count is reported to the customer success manager for aggregation and billing.

No customer information, personally identifiable information (PII), or product information is included in the logging.

### When you must self-report

Self-report transaction volume in these cases:

- Custom order flows that bypass the order table or order APIs. Headless implementations of Commerce Connect that use the back-end order table are counted as transactions. Completely custom order flows that bypass the order APIs may not be tracked.
- Custom implementations that do not use the `TrackingNumber` field as a unique order ID. The system runs a unique order ID check when aggregating transaction events. The `TrackingNumber` column of the `OrderGroup_PurchaseOrder` table is referenced during the order ID verification. If a custom implementation does not use the `TrackingNumber` field as a unique identifier for each transaction, the total number of transactions may be calculated incorrectly.
- Custom order statuses used in place of `InProgress` in the convert-to-order flow. The query references orders that move through the `InProgress` status, so orders that move through a custom status are not counted.