Test blank, zero and service overrides in a branded AI workspace

A pricing form can save successfully while the customer journey still behaves differently from what the operator intended. One easy distinction to lose is a blank service markup versus an explicit zero: they represent different configuration states.

This guide is from the Ace Data Cloud team and uses the documented behavior of a white-label Studio. It provides a manual acceptance workflow for the selected site and service. Check the current configuration guide and actual checkout before applying it to a commercial offer.

In the site's Price settings, the site-wide markup is the default. A service-specific markup takes priority when it is explicitly set.

Record the configuration state as well as the visible number. If the site-wide markup is also zero, two different states may produce the same price. That observation alone cannot show whether the service is inheriting the default or using an explicit override.

If you need a more distinguishing configuration, use an authorized test site and record its starting settings. Change one relevant setting at a time. Avoid changing a live commercial offer just to make a test easier to observe.

Choose one service and a specific option within it. Enter through the site address customers will actually use, with an appropriate test account. Check the selected option, charging unit, displayed currency and price before moving to the checkout for that same purchase path.

Record the checkout amount and settlement currency separately. A number on a tool page and a number on a checkout page are not comparable until the service, option, quantity, charging unit and currency are aligned. Current offers or discounts can also affect the applicable price.

A screenshot of an administrator's form answers only part of the first question. It does not establish checkout behavior, a completed payment, actual usage or an operator reward.

Removing a service override restores its default display settings and makes its markup inherit the site-wide setting. That can affect more than price: an override can also hold the service's custom name, description, ordering or visibility.

Record those values before changing the override. If the task is to clear just the markup field, do not substitute deletion of the whole override. After a deliberate removal, recheck the service's presentation as well as the price.

Hiding the top-up entry does not clear an existing balance or stop a customer from buying shared packages through another entry point. Likewise, hiding a tool is a display choice, not proof that API access has been revoked.

Studio branding uses a shared account, balance and package system. A course budget written in a handoff note is an operating agreement unless a real spending limit has also been configured and verified. Describe only the controls you have actually checked.

Use pass, fail or not checked for each result. Keep the record in an authorized location and share only the parts appropriate to the recipient.

Test time and time zone: Site and intended customer entry: Test account role or non-secret reference: Service, selected option and quantity: Site-wide markup: Service state: absent / blank / zero / explicit percentage Expected applicable markup and its basis: Displayed price, charging unit and currency: Checkout amount and settlement currency, if checked: Saved configuration result and customer-path result: Actual usage or order evidence, if a paid test was necessary: Open issue, next check and owner: Enter fullscreen mode Exit fullscreen mode Inspect the page and purchase path before deciding whether a paid generation is necessary. If it is, confirm the current service price and agree a small test scope first. Record the actual result and usage; do not generate repeatedly just to improve a screenshot.

If a submission's outcome is unknown, reconcile the original task before deciding whether another request is needed.

This 45-second silent recap covers inheritance, explicit zero and a service-specific percentage:

For the current forms and rules, use the Studio capability and pricing guide.

Customer attribution, valid orders and distributable rewards need their own evidence. A successful task does not prove that a reward is payable; refunds and other applicable adjustments can change the records. Consult the customer attribution and earnings guide when checking those outcomes.