Product Delivery

When defining a product, Step 3 is ‘Product Delivery’.
The delivery method option will allow merchants to choose between the two available options:

- Upclick Delivered (eBooks, software type) : Upclick will supply unique download links to customers, tailored for each customer. The merchant has to upload the software/eBook file, as well the license keys (if required). Upclick will deliver the file with a license key (when applicable).

- Merchant Delivered (membership type): Upclick will generate a unique membership URL for each customer. This URL contains all the information the merchant needs in order to authenticate the client in his "members area". We supply documentation on the way you integrate this membership URL to comply with any system.

Let’s examine these two options closely:

Upclick Delivered

The final package to be delivered to the final customers, (an eBook or a software installer, for example) will be uploaded on Upclick’s servers.

Each time the product is sold the customer will receive a unique URL, usable for a limited amount of time (days) and limited number of downloads. Through our Customer Service interface we give visibility on the customer's activity regarding the product download activities as well as capabilities to extend the URL availability.

If the product requires a license key, Upclick offers different ways for integration:

none: no license key is required for the activation of the product. It could be the case of an eBook or other specific software;
static:      the same license key (static) is required for all users. Upclick will      display the license key in the Confirmation Page and in the Purchase      Confirmation Email, for each product, next to the download link.

     For example:

Figure 1: License Key Displayed under the download link on Confirmation Page

list: a separate license key will be delivered for each product purchased.
     During Product Definition, merchants upload a list of predefined license keys, which will be consumed and delivered one by one for the related purchases.
     UpClick has also has monitors which will alert the merchants when license keys are running low. The list can be copy-pasted from any format (ex. Excel) and has to contain each separate key on a different line (linefeed separator).
     For more information, please refer to the Notification and Alerts section.
merchant managed: no license will be delivered by UpClick.
The Notification Services and other tracking options (Pixel URL) the merchants can be used to notify the merchant on each transaction. In this case, a license key can be delivered by the merchant himself, upon reception of this notifications.
This approach can be applied in the situations of a complex DRM when the keys are generated on the fly, based on the order information or when the merchant has a separate back-office, sending eventually other emails to customers (support portal, etc.).

merchant CRM service: UpClick will connect to your own CRM service to retrieve the license key and deliver it to the customer.
For this scenario you will be required to provide your License CRM Service URL (max 400 characters).
You can find the list of dynamic tags that can be used in your License CRM Service URL in the table below:

Tag	Description
email	Customer Email
productuid	Product UID (as displayed in your account)
productsku	Product SKU (as defined in your product optional settings)
orderid	Upclick's Global Order ID
countryiso	Customer's Country Code (ISO-3166 - Country Table)
languageiso	Customer's Language Code (ISO 639-1)
quantity	Number of quantity sold

Note: Use the tags in "square brackets" [ ].

In the checkout process, if the transaction is approved, a HTTP GET request will be made to the defined "License CRM Service" URL, after replacing the dynamic tags with the real order related values. The checkout expects in response a clear text with the serials, comma delimtted. In the case of a single product unit ( quantity=1) the response will contain one single serial.

Upclick can provide the IP address from which these type of requests are made, so you can secure/whitelist the endpoint access.

Merchant Delivered

This type of delivery refers to membership type of products (Products that require access codes to a member area. When choosing this option, instead of receiving a direct eBook or Software installer, the customer receives the merchant URL, specified in the product definition. This type of delivery could be applied to digital products of any type, as long as the "member area" provides the product within its pages. Curiously, it can be modified to match any membership type of products, including recurring memberships and even e-books and software.

The definition is straight forward:
(Under ‘My Products’ section, click ‘Manage Products’, then scroll down to Step 3 – Product Delivery).

Figure 2: Product Definiton > Product Delivery option

Next, you might want to add a Digital Key. The membership page might require that users log-in. The merchant can choose the option to add customer and purchase information appended to the URL.

Figure 3: Product Definition > Digital Key

To ensure security, a "checksum" parameter will be generated and sent together in the URL with the other parameters. The "cverify" field is generated by an algorithm based on the "Digital Key" defined by the merchant. It is the field that will validate that the other parameters are valid, in order to avoid fraud.

The primary flow includes the following steps:

Figure 4: Product Definition > Product Delivery flow

Based on the information in the URL, the merchant has multiple possibilities: customer authentication, send email, store in specific database, etc.

The following parameters are sent in the URL:

Parameter	Description	Character
ctransreceipt	Global Order ID	10
ctransaction	SALE ( Transaction type)	10
ctranstime	The Epoch time of the sale	10
ccustname	Customer full name (append FirstName and LastName)	1-150
ccustcc	Customer Country Code ISO-3166 ( Country Table)	0-2
ccuststate	Customer State Name (if available)	50
ccustemail	Customer Email	1-255
clang	Customer language code	2
cproditem	Product UID	7-10
cprodtitle	Title of product at time of purchase	0-255
ctranspaymentmethod	Payment instrument	20
ctransamount	Amount of the transaction	5
caffitid	Affiliate ID	7-10
ccmp	Affiliate Campaign	100
cwid	Affiliate Offer ID (Website ID)	10
cmkey1	Merchant custom parameter 1	100
cmkey2	Merchant custom parameter 2	100
cmkey3	Merchant custom parameter 3	100
cmkey4	Merchant custom parameter 1	100
cmkey5	Merchant custom parameter 1	100
cverify	Validation parameter 1	40
chk	Validation parameter 2	40

Here is also an example of a membership URL with Order information posted by UpClick:

http://www.yourwebsite.com/?ctransreceipt={OrderNumber}&ctranstime=1371758648&cproditem={ProductUID}&ccustname={CustomerName}&ccustemail={CustomerEmail}&ccustcc={CountryISO}&ccuststate={State}&ctransaction=SALE&cprodtitle={ProductName}&ctranspaymentmethod={PaymentMethod}&ctransamount={OrderAmount}&caffitid={AffiliateID}&clang={Language}&cwid={WebsiteID}&ccmp={Campaign}&cmkey1={mkey1}&cmkey2={mkey2}&cmkey3={mkey3}&cmkey4={mkey4}&cverify=D571BFF892F389A05D0BE6BB0743B08FEC9D7B1B&chk=5108EEF507FE05822F6FBCA90DB04A6D3F466157

While building the string UpClick creates a hash (sha1) of the values of a concatenated values for the Digital Key, Global Order ID, Epoch transaction time and Product UID, separated by the "|" character. The result is the ‘cverify’ parameter. Upon receipt of the query string parameters, your system must also create a hash of the same values passed along with your Digital Key. The validity of the data received is evaluated by using the ‘cverify’ parameter we send and the value produced in your system. Only if there is an exact match between the two values you can be certain that the information received has not been tampered.

There are situations when the validation on your side must be even stronger, to ensure the security of your "member area", including more parameters in the hash value. In situations where you store on your side the OrderNumber, you can have rules for eventual other fraudulent requests for the same number, but with different customer information ( eg. email). In this case cverify could be enough for you to validate the unicity of your customer. In cases where you do not support a backend repository and rules for "member area" and want to relay on the link genrated, you may use the "chk" parameter .This parameter is the hash (sha1) of the following values concatenated and split by '|' character:

ctranspaymentmethod|ctransamount|clang|cwid

Example: 1234567890|U336Z4DA|1371666975|P010838|dbc1 dbc1|test@test.com|US|SALE|test1234_1|Visa|5.00|en|98

You can use the following code for the cverify (provided in various programming languages) in order to verify the received data on your side:

C# Sample

public bool cbValid(string cbreceipt, string time, string item, string cbpop)

{

string secretKey = “YOUR DIGITAL KEY”;

byte[] data = System.Text.Encoding.ASCII.GetBytes(string.Format(“{0}|{1}|{2}|{3}”, secretKey, cbreceipt, time, item));

byte[] hashedData = new System.Security.Cryptography.SHA1Managed().ComputeHash(data);

string hash = System.BitConverter.ToString(hashedData).Replace(“-”, “”).ToUpper();

return cbpop == hash;

}

VB Sample

Public Function cbValid(ByVal receipt As String, ByVal time As String, ByVal item As String, ByVal cbpop As String) As Boolean Dim key As String = “YOUR DIGITAL KEY”

Dim sha As New SHA1CryptoServiceProvider()

Dim mash As String = key & “|” & receipt & “|” & time & “|” & item

Dim result() As Byte = sha.ComputeHash(New System.Text.Encoding.ASCII.GetBytes(mash))

Dim xxpop As String = BitConverter.ToString(result).Replace(“-”, “”).ToUpper()

Return cbpop.Equals(xxpop)

End Function

PHP Sample

function cbValid()

{ $key=’YOUR SECRET KEY’;

$rcpt=$_REQUEST[‘cbreceipt’]; $time=$_REQUEST[‘time’];

$item=$_REQUEST[‘item’]; $cbpop=$_REQUEST[‘cbpop’];

$xxpop=sha1(“$key|$rcpt|$time|$item”); $xxpop=strtoupper($xxpop);

if ($cbpop==$xxpop) return 1; else return 0;

Ruby Sample

require ‘digest/sha1’

def cbValid(receipt, time, item ,cbpop)

key = “YOUR DIGITAL KEY”

popCheck = “#{key}|#{receipt}|#{time}|#{item}”

xxpop = Digest::SHA1.hexdigest(popCheck).upcase()

cbpop == xxpop

end

Java Sample

public boolean validateApiNotifcation(HttpServletRequest request) {

String xxpop = “”;

String cverify = request.getParameter(“cverify”);

String pop = String.format(“%s|%s|%s|%s”, “YOUR DIGITAL KEY”, request.getParameter(“ctransreceipt”), request.getParameter(“ctranstime”), request.getParameter(“cproditem”));

try {

MessageDigest digest = MessageDigest.getInstance(“SHA”);

byte[] b = digest.digest(pop.getBytes());

xxpop = new String(Hex.encodeHex(b)).toUpperCase();

}

catch (NoSuchAlgorithmException e) {

e.printStackTrace();

}

return xxpop.equalsIgnoreCase(cverify);

}

// This requires Jakarta Commons Codec Library (http://commons.apache.org/codec/)

A similar code can be implemented for "chk", but where the fields concatenated will be the ones mentioned above.