AnyTry - AI Virtual Try-On for WooCommerce

The widget sends photos to AnyTry for processing by the selected AI providers, including Google. Browser images, server images and Size Advisor records have separate lifecycles. Closing the fitting room does not immediately erase every copy. See the privacy information above and the service Privacy Policy for processing details.

Most try-ons finish in 15–20 seconds. The plugin does not paste the garment onto the photo — it generates an entirely new image with generative AI, which is a genuinely heavy computation. The widget shows a live progress estimate while it works, and the customer can minimise the window and keep browsing; the finished result is picked up as soon as it is ready.

Best results come from full-body photos with good lighting on a plain background.

The plugin stores its WooCommerce configuration options (API key, button style, size advisor mode, etc.) and a small amount of WooCommerce order metadata for conversion attribution. No customer photos are ever stored on your site. AI processing and the analytics reports themselves are handled by the AnyTry cloud service; on your site the plugin keeps only the bookkeeping records described below, which let it deliver those reports reliably. Version 1.0.36 stores each new purchase, cancellation or refund as a complete operation before background delivery. A confirmed purchase snapshot is retained while the order exists so later order edits do not replace its recorded facts. Delivered cancellation and refund payloads become eligible for minimization after 30 days; undelivered operations and incomplete refund groups after 90 days. Ready purchases held because analytics consent is off follow the existing 14-day default. Minimal records remain to prevent duplicate operations and distinguish confirmed delivery from unconfirmed expiry. After permanent order deletion is verified in both WooCommerce stores, a maintenance pass removes the purchase facts from records older than 24 hours. Moving an order to trash does not do this. The personal-data eraser removes per-order records. Cleanup requires the scheduler and database to be available. For older queued events and the other local records, the existing rules remain: Three small database tables are used for bookkeeping only. One prevents the same cancellation being reported twice; these records have no age limit. The outbox records purchase, refund and cancellation work before it is sent to AnyTry in the background, so temporary network or server problems can be retried. Delivered purchase and return entries become eligible for removal 30 days after delivery. Queued purchase and return entries in the ready phase age out at 90 days from admission once due; failed or quarantined purchase and return entries become eligible for removal at 90 days from admission. Return entries are only removed after their refund accounting has been preserved; if that repair cannot complete, they remain without an age limit. Two kinds are removed sooner, by default after 14 days from admission: ready purchases while analytics consent is off, and ready deferred refunds whose readable order shows no AnyTry activity and has no purchase still owed. Unresolved refund reservations and pending refund or attribution receipts have no age limit. Legacy staged purchases can remain without an age limit, including while held for an unknown or different account; an unreadable legacy order's staged batch can be retired after 90 days when recovery runs. New purchases keep one fixed declaration of the products and try-on identities being reported, so interrupted recording resumes the same purchase. After publication, this declaration retains product and order-line identifiers and attribution, without product names or amounts. It has no age limit while the order remains; after the order is permanently deleted and its absence is verified in both WooCommerce stores, a later maintenance pass reduces a declaration older than 24 hours to a minimal order and ownership marker. Moving an order to trash is not permanent deletion. Pending cancellation records retain a snapshot of the order lines and attribution; resolved reports also keep their exact outgoing content until acknowledged. Purchase declarations awaiting publication and cancellation work stop automatic attempts after 12 failures or when due work reaches 90 days, and remain for operator review. Consent or account holds consume no attempts. These new records are not removed merely because they are old. An acknowledged cancellation leaves the duplicate-prevention record; interrupted cleanup is retried. Orphaned cancellation content is diagnosed separately and retained for review. The outbox also keeps permanent per-order refund ledgers and ownership records: they preserve refund amounts and coverage, order and refund ids, the owner's key fingerprint and, when known, account id, without customer names, contact details or photos. Key-to-account mappings are kept as options containing key fingerprints, account ids and validation times, without order or customer data; they remain until uninstall because other orders may still refer to them. An option also registers purchases that could not be queued: it keeps at most 200 outstanding orders and sheds the oldest on overflow — except an entry whose ownership could not yet be recorded (for example during a database outage), which is kept until it can be, and stops retrying after 24 unsuccessful recovery attempts; account holds use no attempts and have no age limit. The third table, submit-answer escrow, briefly keeps hashes, a job id, an encrypted job access token and a small status response so the answer to one try-on submission can be recovered; it stores no photos and becomes eligible for hourly cleanup 25 hours after its last update. Cleanup depends on the background scheduler and database being available. Changing to another API key of the same AnyTry account changes nothing about ownership or delivery. Purchase, refund and cancellation data known to belong to a different account is never sent to the new account and follows the same retention rule as any undelivered entry of its kind, including the kinds with no age limit. When account ownership cannot be verified, history remains held: two known different accounts on one legacy order cannot be resolved automatically or by CLI assertion, an unmapped legacy key remains held until mapped, and a read failure before an ownership candidate is verified leaves unknown provenance that never resolves automatically; an operator may explicitly assert ownership of genuinely unknown history through the CLI, but cannot override known conflicting accounts, and during a storage outage the refused-purchase register may exceed its usual 200-order limit because entries whose ownership cannot be preserved are retained. All three tables and the key-to-account mappings are removed on uninstall. The plugin's WordPress personal-data eraser removes the shopper's per-order rows, including purchase declarations, permanent refund and ownership records, pending and acknowledged cancellation records, refused-purchase references and order metadata, regardless of WooCommerce's "remove order data" setting; shared key-to-account mappings are retained until uninstall. One non-personal marker (a timestamp) is retained per erased order so erased analytics cannot be silently re-created and re-sent.

Only when the merchant has enabled analytics consent (default OFF). When enabled, anytry_session and anytry_tried cookies persist for 90 days on visitor browsers — both store a random session ID and a list of product IDs the visitor has tried on, used to attribute purchases to try-on sessions. See the "External services" section for full disclosure.

Yes. The plugin is fully compatible with WooCommerce High-Performance Order Storage (HPOS).