Share » Learn » eZ Publish » Selling Pay-Per-Download Products

Selling Pay-Per-Download Products

Sunday 30 August 2009 3:00:00 pm

Currently 5 out of 5 Stars.
1
2
3
4
5

This article has provided a working framework for a pay-per-download solution on eZ Publish. However, there are many ways that you could improve or customize it to suit your needs.

Order history

The eZ Publish "shop" module has a view for an order history intended for site administrators to view all orders made on the site. Therefore, it is not suitable to allow normal users to access this view. However, you can create your own module and view based on what eZ Publish already provides, in order to show a user only their order history. A sample module called "orderhistory" is provided in the sample extension download (see below).

You can link to its "view" view (which takes one parameter: the user's ID) of such an order history module in another template, such as in a user's "My profile" page.

Other workflow uses

With the workflow extension as a starting point, here are a couple of the many other use cases for a pay-per-download solution that you could add with some extra coding:

If you are selling software with product keys and have an existing product key generator, you could trigger this generator whenever someone purchases that product. Using the resulting key, you could create a new object with that key, and give the current user access to that object.
Assign access to a particular section (via the assignment of a role or by moving the user to another group) to support the purchase of value-added website content (for content subscriptions and the like). Instead of buyers getting access to specific files, they receive access to entire areas of the site.

Limitations and other possibilities

Here are some limitations of the example extension and some hints on how to overcome them:

To support multiple downloads per product, use an attribute of the "Related objects" datatype (instead of the "Related object" datatype we used), then in your workflow code (and all the templates that display details of an order), loop through all of the related objects.
In our example, we've assumed that the buyer will complete payment via PayPal. You can install different gateways or even accept offline payments.
Neither the eZ PayPal extension nor the example pay-per-download extension change the order status after they've run. Therefore, by default the order statuses will all say "Pending". In the case of a pay-per-download situation, you have probably completed the entire buying loop and it might be useful to distinguish this as "Completed" or "Delivered". You can edit order statuses in the "Webshop > Order status" page of the "Administration Interface" and then employ the usage of eZOrder::modifyStatus() in whatever shop-related extension you use.