Key generators
Overview
Product activation means sending the client an email message containing either a binary key (especially for software products) or an activation alphanumeric code for digital products like software and phone cards. The key or the code is used to unlock the subscriptions or get access to website content.
This feature is implemented by storing the keys or codes using two different types of lists:
Static lists
Dynamic lists
Static lists
Add a static list
Navigate to https://secure.avangate.com/cpanel/electronic.php under Setup.
Enter a name and select the list type: Static.
Choose the type of codes your customers receive:
A single activation code that all shoppers share.
Multiple codes that you can enter manually, one per line. You can also tweak the way that 2Checkout handles:
Duplicates. Your list may or may not contain duplicate codes.
Codes in the context of several units purchased. Send multiple codes according to product quantity or a single code regardless of the number of units purchased.
Notifications when a list is running low on available codes.
Assign the products for which 2Checkout delivers codes from the list.
Delete a static list
Navigate to https://secure.2checkout.com/cpanel/electronic.php under Setup.
Click Edit on the list you want to delete.
Remove all products from the list and save the changes.
Go back to the list catalog page and click the Delete button.
In the pop-up message, confirm the deletion of the list.
Dynamic lists
Use this option if you host the key generator on your servers.
Workflow
2Checkout queries your code generator.
Your code generator creates the codes and provides them to 2Checkout.
2Checkout delivers the codes to your shoppers in fulfillment emails, on the Thank You Page, and in their myAccount.
Code generator output
For each approved order, 2Checkout queries your server with certain parameters (see parameters table) that you can use to generate codes/binary keys. Depending on the code or key format (alphanumeric or binary) the 2Checkout system expects either a:
XML file (alphanumeric code or key)
Or a binary file response (binary code or key)
Limitations
Key generators hosted on websites with self-signed certificates are not allowed.
The Skip TLS validation rule set in System settings applies only for webhook notifications (IPN/LCN/INS) and does not work for key generators.
Add a dynamic list
Navigate to https://secure.avangate.com/cpanel/electronic.php under Setup.
Enter a name and select the list type: Dynamic.
Enter the URL corresponding to the location on your server where you host your key generator.
Assign the products for which 2Checkout delivers codes from the list.
Delete a dynamic list
Navigate to https://secure.2checkout.com/cpanel/electronic.php under Setup.
Click Edit on the list you want to delete.
Remove all products from the list and save the changes.
Go back to the list catalog page and click the Delete button.
In the pop-up message, confirm the deletion of the list.
Method and parameters
2Checkout sends the following parameters to your server using HTTP/HTTPS POST using the URL you supplied when configuring the dynamic list.
PID
Unique, system-generated 2Checkout product ID.
PCODE
The product code you control.
INFO
Additional information sent with the order.
REFNO
Order reference from the 2Checkout system. (maximum 9 characters)
REFNOEXT
Order reference from your own system, sent when the order has been generated
PSKU
Product SKU
TESTORDER
Specifies if the order is for testing purposes. The only possible values are YES or NO.
QUANTITY
Ordered products quantity. (number of subscriptions for example)
FIRSTNAME
Shopper first name. (maximum 40 characters allowed)
LASTNAME
Shopper last name. (maximum 40 characters allowed)
COMPANY
Shopper company name
ADDRESS
Shopper's address.
STATE
The shopper's state.
FAX
Fax number.
Shopper email address. (maximum 40 characters allowed)
PHONE
Shopper phone number.
LANG
ISO 639-1 two-letter code. The language used for transactions ("en" or "ro" for example)
COUNTRY
Shopper country. (maximum 50 characters allowed)
COUNTRY_CODE
ISO code for the shopper country.
CITY
Shopper city. (maximum 30 characters allowed)
ZIPCODE
Shopper zip code. (max 20 characters allowed)
LICENSE_TYPE
Sent for subscriptions. Possible values: - REGULAR: for new subscriptions/licenses - TRIAL: for paid trial subscriptions/licenses - RENEWAL: for renewed subscriptions/licenses - UPGRADE: for upgraded subscriptions/licenses
LICENSE_REF
Unique, system-generated subscription reference number in the 2Checkout system. Maximum 10 characters.
LICENSE_EXP
Subscription expiration date in the format: 2003-12-25 02:30:45 When the product has been purchased with the "one-time fee" (lifetime) options enabled, the value is: 9999-12-31 23:59:59 The LICENSE_EXP DateTime stamp takes into account the custom time zone you selected via https://secure.avangate.com/cpanel/account_settings.php under https://secure.avangate.com/cpanel/index_account_settings.php, or 2Checkout's default GMT+02:00
LICENSE_LIFETIME
This parameter indicates whether 2Checkout generated a lifetime subscription for the product. - 1 = lifetime subscription is on for the product - 0 = lifetime subscription is off for the product
PARTNER_CODE
Possible values: - Empty = eCommerce order - Partner code If sent, the partner code is also included when the HMAC is calculated.
TIMEZONE
The time zone you selected or the default GMT+02:00 time zone of the 2Checkout system.
Parameters LICENSE_TYPE, LICENSE_REF, LICENSE_EXP, and LICENSE_LIFETIME are not included in the debug. This is because these parameters are not used for the HASH calculation. There is no subscription created by the debug so there are no related parameters to be sent to the keygen when the debug is made, as no code needs to be generated. This process is just querying the keygen to ensure that it is working by sending the HASH which the keygen should validate and return a 200 OK response if it matches.
If you configure additional order fields and 2Checkout collects this type of info during the checkout process, it will be included in the POST request:
Field Name
CUSTOM_FIELD_TEXT[]
CUSTOM_FIELD_VALUE[]
Field Name
CUSTOM_FIELD_714585_TEXT[]
CUSTOM_FIELD_714585_VALUE[]
If you configure per-product price options, 2Checkout also includes them in the POST request. Example: 2Checkout product ID (PID):714585
PRODUCT_OPTIONS_714585_TEXT[]
Array with all the price options texts set per product.
PRODUCT_OPTIONS_714585_VALUE[]
Array with all clients input corresponding to the text.
PRODUCT_OPTIONS_714585_PRICE[]
Array with all the prices corresponding for each option (prices are in the order currency)
PRODUCT_OPTIONS_714585_OPERATOR[]
Array with all the prices operators (ADD, SUBTRACT) corresponding for each price option
Generating the output
You can package your response as:
XML for alphanumerical codes (Basic XML or Advanced XML)
Binary attachment for binary keys
Error code sent in the HTTP headers
XML files have certain reserved characters that must be escaped in a certain way when used. The reserved characters and their corresponding escape sequences are:
& (ampersand) converted to &
< (less than) converted to <
(greater than) converted to >
" (double quote) converted to "
' (single quote) converted to '
When XML files are created, please replace these characters in the attributes and inside the nodes with the correct escape sequence to have a syntactically correct XML document. These characters are documented in the XML specification: http://www.w3.org/TR/REC-xml/
HTTP Headers
HTTP servers use a large number of response and status codes, usually transparent for the navigator. These codes tell the browser if there was an error or not. The codes are embedded in the HTTP header of the client/server communication. The success status code is 200 while any other code is an error. For example, 400 means "Bad Request" and 403 means "Forbidden". HTTP response header examples:
HTTP/1.0 400 Bad Request
HTTP/1.0 200 OK
Content-type
Set the value of the Content-Type field to text/xml in the header response when you package your response as XML.
For all other values, 2Checkout treats the content as a binary key.
Basic XML Answer format sample
Use the following template for your XML file :
The code you deliver for the product. Include each standalone code between tags.
Optional. A global description per delivery/fulfillment.
Binary Attachment format
If you deliver a binary file, instead of XML, set the value of Content-Disposition in the header as in the example below. Include the attached file containing the key in the body of the message. Set the filename using the 'Content-Disposition' field.
Advanced XML Answer format
If you need to attach additional installation instructions or details to the delivered codes, you can use the XML structure detailed below:
The key you deliver for the product. Include each standalone code between tags.
If it is contained in the node, then it is treated as a global description per delivery/fulfillment. If it is embedded in the node, then it is a description for that code.
Optional field. A base64-encoded file.
A tag answer must contain at least one of the elements or .
Security
For security reasons we strongly recommend that you limit access to the key generator URL used to generate access codes or keys and grant access only to the 2Checkout server IP networks.
HASH field
Use the value of the HASH field to check data integrity.
HASH
HASH signature SHA-2/SHA-3 HMAC created using all the fields sent through HTTP/HTTPS POST.
Calculate the HASH signature
Example using the following data:
PID
6
189645
PCODE
3
123
REFNO
7
1250747
REFNOEXT
0
TESTORDER
3
YES
QUANTITY
1
1
FIRSTNAME
4
John
LASTNAME
3
Doe
COMPANY
0
18
info@2checkout.com
LANG
2
en
COUNTRY
11
Netherlands
COUNTRY_CODE
2
nl
CITY
10
Amstelveen
ZIPCODE
4
1181
Source string for HMAC_SHA is calculated by pre-pending each field value with its own length. The source string for the data above is:
Secret key for this example: SECRETKEY
HASH value SHA-2: a141c737f23ccbe0e2bc88a1c81532a6
HASH value SHA-3:
Don't forget to check if the received order reference matches a valid reference order from your system.
Test orders
In the case of test orders, 2Checkout populates the TESTORDER parameter with the value YES. It is highly recommended to reply with testing codes or keys whenever receiving the above-mentioned parameter in the server request, and not codes/keys you would send to actual shoppers.
Code sample
Related documentation:
https://verifone.cloud/docs/2checkout/Documentation/09Test_ordering_system/03Fulfillment
https://verifone.cloud/docs/2checkout/Documentation/11Emails/Email_variables/Electronic_delivery
https://verifone.cloud/docs/2checkout/API-Integration/01Start-using-the-2Checkout-API/2Checkout-API-general-information/Migration_guide_SHA2_SHA3/Electronic_delivery_of%20codes_upgrade_to_the_SHA_algorithm
Last updated
Was this helpful?