This skill is Pro-only. Verify FluentCart Pro is active and the license module\nis enabled before using its models, routes, tables, or hooks.
\nRead licensing-protocol.md before extending\ngeneration, activation, update delivery, or client compatibility.
\nUse the Licensing module's product settings and LicenseManager/LicenseHelper\nservices. Do not create keys or activation rows with ad-hoc SQL. The module\nrelates licenses to customer, order, product, variation, subscription, sites,\nactivations, and meta, and applies lifecycle rules to those relations.
\nFeature-detect ModuleSettings::isActive('license') and Pro classes after\nfluent_cart/init. A product being downloadable or subscription-based does not\nitself mean licensing is enabled for that variation.
\nThe built-in handler generates licenses after fluent_cart/order_paid for\ninitial payment/subscription orders; extends validity on subscription renewal;\nreactivates where appropriate; and disables/expires/deletes licenses according\nto payment failure, full refund, validity expiry, order deletion, and module\npolicy.
\nListen to license-specific hooks for addon side effects instead of duplicating\ngeneration. Make extensions replay-safe: payment/webhook and repair flows may\nre-enter lifecycle code. Preserve the distinction among active, disabled, and\nexpired plus the stored reason and previous status.
\nDo not revoke automatically on every transient renewal failure unless that is\nthe explicit access policy. Subscription grace, next billing date, cancellation\nat period end, EOT, refund, and manual administration are separate decisions.
\nLicense keys and activation hashes are secrets. Never log them in full, expose\nthem in public REST serializers, place them in analytics/referrers, or accept a\nlicense ID alone as authorization. Normalize the site URL through LicenseHelper\nand validate product/item binding on every check, activation, deactivation,\nversion, and package request.
\nActivation must be concurrency-safe around the limit. Test simultaneous first\nactivations and activation/deactivation races; a read-count-create-recount\nsequence alone is not proof of atomic enforcement.
\nCustomer-profile endpoints require WordPress login and must remain scoped to\nthe resolved FluentCart customer. Admin endpoints use LicensePolicy permissions\nsuch as licenses/view, licenses/manage, and licenses/delete.
\nLicense client calls enter FluentCart's public action dispatcher and map to\ncheck_license, activate_license, deactivate_license, get_license_version, and\ndownload_license_package handlers. Match the installed request/response shape\nand distinguish transport HTTP success from the returned license status/error.
\nDo not reuse fct_package as a general-purpose signed URL scheme. In the tested\n1.6.0 source it is a base64-encoded credential payload, and the download parser\ndoes not consume the appended expiry field as a verified cryptographic claim.\nUse the built-in path only for required compatibility, keep TTL/authorization\nunder version-specific audit, and implement new protected delivery with a\nserver-held, tamper-evident, expiring token or opaque one-time record.
\nTest disabled module/Pro absence, one-time and subscription products, quantity\nand variation license settings, duplicate paid event, payment failure, full and\npartial refund, renewal/grace/expiry/EOT/reactivation, key regeneration, limit\nchange, local/staging classification, normalized URL variants, concurrent limit\nrace, activation replay, wrong item/site/hash, customer cross-account access,\nadmin capability boundaries, expired/tampered package URL, update response, and\nlegacy EDD client compatibility.
\n