Track transactions for transaction-based billing

Optimizely Customized Commerce clients on page-view based billing should review documentation for Page view tracking for Optimizely Content Management System (CMS).

Billing transaction definition

Optimizely defines a billing transaction as an order that has gone through the ‘convert-to-order’ flow within Customized Commerce or its APIs in a production environment. This includes all instances when a user clicks “order submit” on the checkout screen in production environment and orders that are submitted to and processed in the order table with a headless API or other custom implementation.

📘

Note

Every order that is captured in the Customized Commerce production order database and passes through the order status of 'InProgress' will be included in the total count of transactions.

Updates, cancellations, and returns to orders that have already moved through the order status of 'InProgress' will not impact the total count of transactions.

Frequently asked questions

How are transactions 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 via a check for unique order IDs. Each month’s count of events are reported to the Customer Success Manager for each client for aggregation and billing purposes.

No customer, PII, or product information is included in the logging.

How are headless orders and other custom implementations handled?

Headless implementations of Customized Commerce that leverage the backend order table are counted as a transaction. Completely custom order flows that bypass the order APIs may not be tracked.

All clients must self-report transaction volume that bypasses the order table and/or the order APIs of Customized Commerce.

How are custom order IDs handled?

The system conducts a unique Order ID check when aggregating transaction events. Specifically, the TrackingNumber column of the OrderGroup_PurchaseOrder table is referenced when completing the unique Order ID verification. In the case of a custom implementation in which the TrackingNumber field is not used as a unique identifier for each transaction, the total number of transactions may be calculated incorrectly.

Clients who have a custom implementation that does not leverage that field must self-report their transaction volume for billing purposes.

How are custom statuses handled?

The query references orders that move through the ‘InProgress’ status. If a client uses a customer status to represent the ‘convert-to-order flow’, they must self-report their transaction volume for billing purposes.