Here's is the basic sequence of events:

1. The customer purchases a license for your Zarqon-licensed application from your website or other channel.
   • Currently Adobe Flex and AIR are supported; more platforms are planned.
2. You receive an email from your payments provider (i.e. Paypal, Google Checkout).
3. You launch or switch to the Zarqon Desktop Control Center and issue a License.
   • Enter the individual or company’s name and email address or select them from a list if they’re an existing customer (i.e. upgrading, purchasing extra features)
   • Add a license, which will:
     • Select the product, (and optionally, feature sets or individual features)
     • Expiry dates can be set for by license, feature set or feature.
     • Specify the website if it is a Site License.
     • Generate the License Key.
     • Encrypt the Product License.
     • Store it in a publicly accessible bucket in your S3 account.
     • Email the License Key and License Holder info to the customer.
4. The customer receives an email from you with the License Holder and Key information.
   • The License Holder info should always be the same as is associated with the purchase!
   • This decreases the likelihood that the license info will be shared.
   • All three pieces of information are necessary to encrypt or decrypt the license if it is a desktop app.
   • If it is a web app, there is no real concern since that key will only be valid if your app is served from the licensed website.
5. The customer installs your application on their desktop or website.
   
   1. If it is a desktop app, you prompt the the customer to enter the License Holder and Key information exactly as it was emailed.
   2. If it is a web application, they simply supply the license key to your app by Flash Vars, or you can fetch it from a file or the querystring (Flash Vars is best).
6. Your application makes a simple Zarqon API call to retrieve the encrypted License from your S3 bucket.
   • S3 buckets store key / value pairs.
   • The License Key is the key and the encrypted license is the value returned.
   • The bucket is publicly accessible, or otherwise you would have to put your S3 key and secret into your application, and since AIR can be decompiled, your S3 account could be compromised.
   • The public bucket is safe, because the License Key itself is useless without the License Holder info if it is a desktop app, or if run from the licensed website if it is a web app.
   • Strong encryption has been used to encrypt the License and so it is far more secure than a typical password protection scheme.
7. The API call will return a valid License object, or null if the License Holder info is invalid.
   • If it is a desktop app:
     • If the License is invalid, have them enter the info again until you get a good license back, or deny further operation.
     • If the license is valid, then store the License Holder information in the AIR encrypted local store (ELS) so that future launches of your app can read it without needing to have the customer enter it each time.
   • If it is a web app:
     • There is no need to ask for or store the license info, you simply get a valid license or not based on whether the key and website is correct.
     • You may now use it to determine what features are available to the web user based on the license details the remainder of this article describes the desktop scenario. 
     • The remainder of this article describes the desktop scenario. 
       
8. There are two ways your desktop product might handle licensing:
   • One-time activation:
     • Store the License object that was retrieved in the AIR ELS.
     • Never consult S3 again for this installation unless the license information is not in the ELS.
     • This means if you close your S3 account, the user can still use the app.
     • It also means that you can’t disable their app if you find out that they’ve shared their license info.
   • Active licensing:
     
     • Do not store the License object that was retrieved, store only the License Holder info and Key.
     • At each startup retrieve the License Holder info and key, and validate it using the Zarqon API which will retrieve the license from S3.
     • This means if you close your S3 account, the user can no longer use the app.
       
       • The kind thing for you to do if you plan to shut down your S3 account, is to publish an update to your app that no longer checks the license or stores it in the ELS an reverts to behavior described above for one-time activation. This allows users to continue using your app. Consider that your exit strategy.
     • It also means that you can disable their app (and all pirates copies, too) if they share their license.
     • It means that you can upsell features to existing customers (i.e. a ‘basic’ user upgrades to ‘pro’, or pays an upgrade fee for a new version)
     • It means that  concurrent licensing and activity tracking are possible, as both touch the S3 bucket with information at each launch.
     
     
9. Regardless of whether you do one-time or active licensing with your desktop app:
   • In the simplest scenario you treat the existence of a valid license as an on/off switch for your app; allowing or denying all functionality based upon it license validity.
   • You can define Features and Feature Sets for your product.
     • This allows scenarios such as:
       • A free, ad-supported app where customers can pay to turn off ads
       • Tiered functionality were users purchase any tier or upgrade  from one tier to another (i.e. Free, Basic and Pro Feature Sets)
       • Upselling individual Features to existing customers.
   • You can set licenses or even individual features to expire.
     • You can check the whether the expired property of the License or Feature
     • This allows scenarios such as:
       • Recurring License Fees (i.e. monthly or yearly license)
       • Limited-time trials of the app, or new features.