Transaction-based billing

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.

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.

📘

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.