Virtual try-on cost per image: pay-as-you-go pricing compared

Start with the fixed license and actual AI usage

The shop license is $39 per month before tax and includes $10 in AI credit. Once that credit is used, the measured model-provider cost is passed through 1:1 without an added margin per generated image. At an illustrative cost of 1.1–2.5 cents per preview, $10 covers roughly 400–900 previews. This is a planning range, not a guaranteed image price: model, input images, quality, currency and provider changes affect each request.

The interface shows the usage-based estimate for each completed preview. This makes model changes and falling provider prices visible instead of hiding them in a fixed image tariff. The estimate remains a diagnostic value; the provider invoice and the merchant agreement are authoritative.

What does virtual try-on cost per image?

There is no honest universal lowest price without holding image quality, workflow and volume constant. VirtualTryOn.store is designed to avoid a per-image software margin: total monthly cost is $39 plus provider usage above the included $10 credit. At an illustrative measured provider cost of $0.015 per preview, 10,000 previews total $179 before tax: $39 + max(0, 10,000 × $0.015 − $10).

Public prices are not perfectly equivalent. FASHN publishes $0.075 per credit and states that Virtual Try-On v1.6 uses one credit; Perfect Corp cites about $0.096 per result at its starting subscription; TryPoint's Grow plan lists $99.99 for 1,000 images and $0.10 for additional images. These references explain why passing raw AI cost through can become especially economical at scale. Check the linked primary sources because plans and capabilities can change.

Separate traffic, adoption and generation demand

Begin with eligible product-page sessions in a defined period, not all store visits. Estimate the share that opens the preview, the share of openers that requests an image and the number of deliberate generations per generating session. Count comparisons of different products and repeated attempts separately. Record whether returning shoppers create new sessions so the denominator remains consistent. None of these assumptions is a forecast from this service. Start with a range and replace assumptions with observed pilot data.

Work a volume example without inventing a tariff

Suppose a month contains 20,000 eligible sessions, 8% open the preview, and 75% of those request a generation. Assume 1.5 deliberate generation requests per generating session and an additional retry allowance equal to 10% of those requests. The allowance is an explicit planning assumption, not a measured failure probability or an unlimited retry model. This produces the following illustrative workload; it is not a price quote or a promise that current public capacity will serve it.

Turn attempts into a complete cost model

Let c represent your verified average cost per billable attempt, q the share of attempts actually billed, and F the operating costs outside that charge. A planning expression is 1,980 × q × c + F. Do not enter a made-up service tariff: obtain the applicable commercial terms and confirm how failed, rejected or interrupted requests are treated. Input size, output settings, provider changes and currency conversion can alter actual costs. Missing usage data is unknown expenditure, not proof of a free request.

Include integration work, catalog preparation, hosting, monitoring and support. Separate one-time setup from recurring operating work, then choose an explicit period over which to allocate setup. Avoid double-counting provider charges if a service agreement already includes them. Report internal labor separately when it does not appear on a vendor invoice but still consumes business resources.

Keep estimates separate from invoices

The current backend derives estimates from reported provider usage and configured rates. Those estimates are useful diagnostics, not provider invoices or merchant pricing. Reconcile them with the relevant provider bills and the merchant's agreement, matching periods, credits, adjustments and currency treatment. Google Cloud distinguishes usage-period reporting from billing-period reporting. It does not validate the image provider's charges. Keep unexplained differences visible and assign someone to investigate them instead of silently replacing billed totals with lower estimates.

Stress-test adoption and operational limits

With the other assumptions unchanged, doubling adoption to 16% produces 3,960 attempts. Keeping adoption at 8% but increasing deliberate requests to 2 produces 2,640 attempts. Use these scenarios to plan peak load and support, not just monthly averages. Current public limits and concurrency settings are protective controls, not a merchant capacity commitment. Check the applicable limits before a campaign. Distinguish alert-only budgets from an implemented spending stop, verify which services are covered, and give an owner authority to pause the pilot.

Judge the net business outcome

Compare contribution after discounts, fulfillment and mature returns between comparable eligible groups, then subtract incremental preview and operating costs. As a purely illustrative accounting example, 900 contribution units minus 700 incremental cost units leaves 200 units; 500 minus the same 700 leaves a loss of 200. These are arbitrary units, not prices or predicted uplift. Include every assigned eligible session, not just enthusiastic preview users. Report uncertainty, errors and support workload alongside the result. Increased adoption can raise expenditure without increasing retained sales, so expansion needs evidence of a worthwhile net outcome.