Mark

IP.Nexus aims to give you the tools you need to monetize your community, and the core of that is the actual transaction process. We've made a number of changes in IP.Nexus 1.2 not only to make managing payments and gateways easier but to protect you against fraud, encourage renewals and generally make it easier for you to make more money. Authorize.Net Recurring Payments IP.Nexus has since version 1.0 supported the Authorize.Net payment gateway. In IP.Nexus 1.2, we're adding support for two systems which will automatically bill customers renewal charges: The first is their "Automated Recurring Billing" system. This works very similar to PayPal Subscriptions - a profile is created on Authorize.Net with the payment information. Then when the renewal is due the card is automatically charged, and Nexus is notified. For more information about Automated Recurring Billing, please see Authorize.Net's website. The second is their "Customer Information Manager" system. This works by having Authorize.Net store the credit card information. IP.Nexus then calls Authorize.Net to make payments, when renewals are due or manually in the Admin CP. This system gives greater flexibility as Nexus chooses when to charge, and you don't need to manually cancel recurring payments with Authorize.Net when a purchase is cancelled. For more information about Customer Information Manager, please see Authorize.Net's website. For both systems the user sees an option on the checkout asking if they want to be charged automatically: PayPal Website Payments Pro PayPal Website Payments Pro is a service provided by PayPal that allows merchants in the US, Canada and the UK to accept credit card payments directly on their website. We're pleased to say that IP.Nexus will support PayPal Website Payments Pro, including recurring billing support. For more information about PayPal Website Payments Pro, please see PayPal's website. Improved Gateways Page Different payment gateways have different requirements such as HTTPS, supported currencies and maximum transaction amounts. In IP.Nexus 1.2, we've added more information to the gateways page, including a warning box that will notify you of any misconfigurations: Anti-Fraud Protection MaxMind offers a Credit Card Fraud Protection, which here at IPS we've been using for years to help audit transactions for fraud. In IP.Nexus 1.2, we will be adding integration for this service. MaxMind returns a score between 0 and 100 indicating how likely a transaction is likely to be fraud. All the service needs is the user's address (which you can require on checkout), however it works best with gateways that use credit cards, i.e. Authorize.Net and PayPal Website Payments Pro. Depending on the score returned, you can choose to manually approve or decline the transaction: The purchase screen will also contain detailed information indicating the reasoning behind the score: For more information about this service, please see MaxMind's website. As always - if there's anything you'd like to see not mentioned here (including other payment gateways), please post in our feedback forum.

As was hinted in the blog entry last week, IP.Nexus 1.2 shall bring support for selling hosting packages. Right away I'd like to mention that this at the moment will work with any server using cPanel and WHM - we will of course gauge interest for other control panels for future versions. Hosting Packages You set up hosting packages just like regular products and advertisement packages. There is a contextual settings tab which displays hosting-specific settings, and these packages then show up in the store: Each package is assigned what we call a "Server Queue" - this is a collection of servers which the account may be created on. So for example, you could have your "advanced" packages only use higher-powered servers. Servers can be part of multiple queues. When the account is created, the server in the queue which has the least accounts is chosen to create the account on. Purchasing a Hosting Package When purchasing, users will be asked if they want to choose their own domain or use a subdomain of one of your domains. You can of course make only one of these options available. If the customer chooses their own domain, they'll be shown your nameservers, and if they choose a subdomain, they'll be shown a list of options - both of these you can set up in the Admin CP. Client Area Management Customers can view their account information in the client area along with all other purchases: From here they can also launch the control panel, FTP and change their password. You can also configure options to allow users to purchase additional bandwidth for that billing cycle, if their bandwidth limit is reached. Admin CP Management The purchase page in the Admin CP shows the same information that is available in the client area, along with the control panel and FTP buttons: Clicking the edit button will allow the administrator to edit specific allowances on the account, without the need to log into WHM: The administrator of course, does not need to manually suspend and terminate accounts. If the customer does not renew their account, it will be suspended, and, after a certain number of days (configureable in the Admin CP), terminated. Of course, using the normal package cancel function allows administrators to manually suspend accounts. Server Management In the Admin CP, you can view all of your servers along with the current load. From this page you can also reboot a server. Clicking on a server will show you a list of accounts on that server. You will also see an overview of how much diskspace is in use and how much is allocated (so you can see if you're overselling). Nexus will also check all the accounts in it's local database against the server to check for any discrepancies: Discrepancies can include an account not on the server but in the database (and vice versa), domain names not matching and account is suspended on the server but active in the database (and vice versa): In addition to auditing each server, there is an "Audit All Servers" button which will check all servers for discrepancies. We're sure that there will be many questions and comments about this new functionality - if there's anything you'd like to see not mentioned here, please post in our feedback forum.

IP.Nexus features an advertisement system which allows administrators not only to set up circulating advertisements on their community, but sell advertising space too. Currently in IP.Nexus, advertisements are purchased through a special location in the client area. In IP.Nexus 1.2 we will be removing this area and moving advertisements into the store. When adding a package to the store, you will be shown a screen which asks you what type of package to add: Then, when filling in the settings, there will be a contextual tab which shows settings for that package type. For products you'll see options about shipping and license keys, and for advertisements you'll see the usual advertisement package settings: Users can then purchase advertisements through the store just like a normal product. They will be asked to provide their advertisement link and image on the same screen that custom package fields appear: And view information about the advertisement on the normal purchase screen: Not only does this make the process of purchasing advertisements easier, but all of the options available to packages are now also available to advertisements, including: Only make certain advertisement packages appear to certain groups. Give discounts on advertisements to certain members, for example, members who have purchased advertisements in the past. For time-base advertisements, use renewal price settings to allow members to continuously pay for advertisement space. Move users who purchase an advertisement into a different usergroup. Allow users to upgrade to a higher package (for example, with more clicks) from within the client area. Finally, this change opens the door for us to add more types of packages all of which display in the store. Like, for example, hosting packages...

IP.Nexus 1.1 was released at the beginning of this month bringing a number of new features such as product options, reporting tools, advertisement system improvements and more. Already we have started work on IP.Nexus 1.2 - while release is still a while away, we'll be posting blog entries during development to show you the upcoming new features. The first new feature in IP.Nexus 1.2 that we wanted to talk about is a license key system. Many users are using IP.Nexus to sell digital products, and currently there is no way to keep track of where your products are being used. In IP.Nexus 1.2, you will have the ability to generate license keys and use an API to call back to Nexus to activate and check license keys. Generating License Keys When creating a product, there are now a number of options regarding how to handle license keys: License keys are by default generated either as a random md5 hash or several blocks of random letters and numbers - developers can also upload a simple PHP file to a certain folder to add more methods if you have your own way of generating license keys. You can also choose an "identifier" for the license keys. Identifiers are provided to the API when activating the license key (for example, your program could ask users for their license key and their name or Email address) - as an additional security measure. Identifiers can be the customer's name, Email address or any custom field with the purchase. This is of course optional. Managing License Keys In the Admin CP, there is a new box on the purchase screen which displays information about the license key: The grey box shows you the license key, when it was generated and it's current status and the table below shows where it's being used (you can set how many times a license key can be used). The dropdown menu at the top with the other buttons contains options to reset (which will clear uses and generate a new key) or cancel (which will make API calls to check the license key fail) the key. Of course, all actions related to license keys is also logged in the customer history page. Users can see their license keys in the client area: Using the API The API uses XML-RPC to send and retrieve data. Full developer documentation will be available when Nexus 1.2 is released, but to give you an overview, there are four methods: activate This is what you call when the user enters their license key, for example, on an installation screen. You send Nexus the license key, the identifier (if necessary) and any additional information you want to save (for example, the version number). If the license key is invalid, or the key has already been used the maximum number of times, Nexus will return an error - otherwise, Nexus will log the IP address used to activate and the additional information you sent and return a success message along with the "usage id" which is an ID number given to that installation for that license key. check This is used to check that a license key is still valid, for example, you may call this periodically from your application. You send Nexus the license key, the identifier and the usage ID (returned from the activate method) and Nexus will return the status of the license key (if it's active or cancelled). info This is used to fetch information about a license key. You send Nexus the license key and the identifier and Nexus returns data about the key (when it was generated, how many times it's been used, etc.) the purchase associated with it (it's ID number, when it expires, all custom fields, etc.) and information about any child purchases (that is, purchases associated with the purchase the license key is associated with. updateExtra This is used to update the additional information send in the activate method. You send Nexus the license key, the identifier, usage ID and new information and Nexus will update the information locally and return a success message.

For our final entry on IP.Nexus 1.1, I'd like to sum up some of the additional general tweaks and enhancements since our last blog entry. Marking an invoice unpaid In IP.Nexus 1.0, once an invoice has been paid, there is no way to mark it "unpaid". While for most circumstances this makes sense, in the event a check bounces or something similar, you may want to undo everything done when the invoice was marked paid. In IP.Nexus 1.1, when you attempt to mark a paid invoice unpaid, you'll see a screen like this: This explains clearly what will happen, including: Which purchases will be deleted. Which purchases will have their renewal dates changed (if the invoice was a renewal invoice). If anyone will have any commission revoked. Which shipping orders will be deleted. It will also warn you of any unexpected circumstances, such as if a purchase has been transferred to a different member, commission earned from the purchase has already been spent, or if any shipping orders have already been shipped: Purchase Page In IP.Nexus 1.0 there are specific pages in the Admin CP for viewing invoices, transactions and shipping orders. In 1.1, we've also added a page for viewing all the information about to a purchased item. This allows you to view all information about a purchase which could sometimes be difficult to find previously, such as the invoice which created it, any renewal invoices, if the member will be returned to a different group when the purchase expires, and more. Cancelling a Purchase It could sometimes be confusing what "cancel" means when referring to a purchase. Sometimes you just want to disable renewals, sometimes you want to revoke any privileges gained by owning a purchase, and sometimes you want to delete it entirely. In IP.Nexus 1.1, when you select cancel, it will present all of these options to you, explaining which does which, so that you can decide what action to take: Share Links We have added share links to the Store's product pages. Print Invoice While customers could always print invoices from their client area, we've also added a print button to the invoice page in the Admin CP. Usability tweaks We've made a few small tweaks to the interface to make things easier to use, including:We've added a "duplicate" button for packages, to save you having to select the same settings for similar packages. We've added a link to the customer page when viewing a shipping order. We've added a "Save and Reload" button when editing packages. We've added a button when viewing your purchases in the client area to submit a support request associated with a purchase right from the list.

Email on new order You can now set packages to send an email when a member purchases that package. Usergroup Discounts You can now provide discounts to users in a particular group. Auto-resolve Support Requests You can now set support requests to automatically be set to resolved after a given time of inactivity. Group Name Limit We've increased the length package group names can be to 255 characters. https In IP.Nexus 1.0, there was a setting which when enabled would make the payment screen server over https. The scope of this setting has been extended to the entire checkout process, the client area when providing information and support requests. Delete Transactions Transactions can now be deleted. Support Request API We have introduced two central models for handling support requests, one for support requests and one for support replies. This allows you to create support requests and replies using a simple API. For example, to create a support request: supportRequest::create( "Title", 1, 1, NULL, 1, NULL, NULL, supportReply::create( supportReply::REPLY_MEMBER, 1, "Message" ) ); Complete developer documentation can be seen here.

IP.Nexus has an advertisements feature, allowing administrators to display advertisements on their community and sell advertising space to third parties. We've spent some time going over some of the suggestions we've received for the advertisements system and have made the following enhancements for IP.Nexus 1.1. Start/End Time Advertisements can now be specified with start and end times for time-specific campaigns. Advertisement Packages: Expire by length In hand with the option to set a start/end time, you can now specify that purchased advertisements last a certain length of time, opposed to a number of clicks or impressions. Advertisement Package Descriptions You can now specify a description for advertisement packages which will display on the purchase screen. Admin Image Upload Currently, when an administrator adds an advertisement they must specify a URL to an image (or HTML code). As of Nexus 1.1, administrators will see an option to upload an image too. Circulation Mode In IP.Nexus 1.0, if there is more than one advertisement per location, a random advertisement is selected from the pool. In IP.Nexus 1.1, we've added a setting which allows you to continue using this behaviour, or to always use the most recently added advertisement. This is useful if you want to have a generic advertisement set up by the administrator but allow purchased advertisements to override that for their duration. Maximum Number of Advertisements You may only want one advertisement in each location at a time, so that advertisements don't circulate at all. In IP.Nexus 1.1, we've added a setting allowing you to specify the maximum number of advertisements per location. Administrators of course can oevrride this, but if there is the specified number of advertisements in a given location, users will not be able to purchase advertisement packages which add advertisements to that location. Alignment We've added a new setting which allows you to choose how to align your advertisements. Size Restrictions You can now specify in an advertisement package the maximum size for advertisements created by that package. External Access Currently, IP.Nexus displays advertisements in pre-set locations on your community. As of IP.Nexus 1.1, you can include advertisements in other areas of your skin, in IP.Content blocks and even in external pages and applications outside of IP.Board. To place an advertisement in a template or IP.Content block, you can simply use the tag: {parse advertisement="1"} The tag can take either the ID number for the advertisement to display, or the key for the location, which will use IP.Nexus' normal logic for fetching the advertisement. For example, using this tag: {parse advertisement="ad_code_board_index_header"} Would display whatever advertisement is configured to show in the board index header - if more than one is configured, Nexus will either pick a random one, or the most recent one (as per the circulation setting described above). To place an advertisement on an external site, you can call a new REST API which will out put the contents - the file is located at: http://www.yoursite.com/interface/advertisements.php You simply need to pass a single variable in the query string which is the same as the parse tag above (ID number or location key). For example, you might use something like this to add your advertisement to a website outside of IP.Board: <?php echo file_get_contents( "http://localhost/ipbdev/interface/advertisements.php?ad_code_global_header" ); If you have more in-depth feedback or ideas please use our feedback forum so your suggestions can be given proper attention. Otherwise, feel free to comment on this entry below.

IP.Nexus 1.0 has the ability for users to send in support requests via Email. Nexus handles these internally as "Guest" support requests and the users can reply by responding to the Email notifications Nexus sends when a staff member replies. In IP.Nexus 1.1, we've added a web-based interface for guests to create support requests too. This makes it easier for users to submit pre-sales questions without having to create an account, and is particularly useful if you are unable or unwilling to use incoming Emails. Guests can now access the new support request screen like regular members, where they'll be prompted for, in addition to normal support request information, their Email address. They'll also need to fill in a Captcha verification if you have that setting enabled. IP.Nexus will then send them a confirmation Email which will contain a link where they can retrieve their support request to reply later. This then displays as a normal support request: They can also of course reply to this notification if you have that incoming Emails enabled. If a user has created support requests as a guest then registers, support requests with their Email address will become associated with their account.

In IP.Nexus 1.0, when a user visits the store and tries to make a purchase, they are redirected to the login screen where they can register or log in. Once logged in, they are redirected back to the checkout screen. While this works well, it can be confusing to some users to be removed from the checkout process. In IP.Nexus 1.1, we've made this process a little smoother. First of all, if a guest attempts to make a donation, they will not be prompted to log in - guests will be able to make donations without registering an account first. You can disable this in the Admin CP so users must be logged in to make a donation if you prefer. For normal purchases, when a user attempts to make a purchase when not logged in, rather than being redirected to the login screen they will simply see a few extra fields on the personal information screen: By simply filling in those details, IP.Nexus will create an account, log them in, and the checkout process will continue as normal. They can also click the login link, which will take them to the login screen, and will be immediately returned to checkout after logging in. Some notes on this: You will notice the screenshot is not prompting for a username. IP.Nexus will automatically set their username based on their real name. You can choose to prompt the user for a username if you prefer. The setting specifying whether or not a user should enter personal information when registering is still honoured. If that is not enabled, and they are not purchasing a physical item, Nexus won't ask them for their address. You can enable Captcha on this screen. Validation settings are still honoured. If you have Email or Admin validation enabled, Nexus will put the user in the "Validating" group and send out the validation Email and/or admin notification Email. If you have disabled registrations, users can still register through this method - this allows you to only allow users who are purchasing items to create accounts. You can of course disable guest access to the store if you do not want this. The Spam Monitoring Service settings are honoured. If COPPA is enabled, they must use the normal registration process since they will need to fill in the COPPA form before the account can be created. Nexus will continue to function as it does in 1.0 if COPPA is enabled.

IP.Nexus contains a powerful support desk allowing staff members to provide support to customers. In IP.Nexus 1.1 we are adding an enhancement to this feature called Support Severities. Severities allows members to mark the importance of their support request. This allows support staff to triage incoming requests and give priority support to particular customers. You can create multiple severities, and specify which ones can be set by customers. Here I have set up two severities: one is for regular requests, and one is for critical issues: Each severity can be configured to display an icon and be displayed in a particular color when viewing the support request list in the Admin CP so that staff can easily identify important requests. You can also choose for each severity if members are allowed to select it. User-selected severities When a user submits a new request they will be prompted to select their severity. The selection box will only show if there is at least 2 severities for the user to choose between, and if there is only the default and one other, it will automatically change to a checkbox: You can also configure in the Admin CP a message to display below the severity selection: Support requests will be sorted in the Admin CP by severity in the order you specify - so in this example, critical support requests will display above normal support requests. When viewing a support request the staff member can of course change the severity. They can also click the icon to the right of the severity selection which will revoke the member's permission to set severity in future (instead, all support requests will have the default severity) - this is useful if a member abuses the severity feature. There is a setting in the Admin CP to allow members to view and edit the severity after their request has been submitted - if this is on, they will see a selection box when viewing their request to change the severity. Auto-selected severities In addition to having severities that the user can select, you can also create severities which are automatically selected when the user submits a support request for a particular package. I have created a new severity called "Priority Support". Under the settings for packages, you will notice a new setting called "Support Severity". I am going to create a new package and set this to "Priority Support". Now, when a user with this package creates a support request associated with this package, the severity will automatically be set to Priority Support:

IP.Nexus allows members to earn account credit using referrals and the IP.Downloads integration. Members can then (if you allow) request payouts in their client area. Until now, these payouts had to be handled manually one by one. PayPal supports a feature called Mass Payments which allows you to make multiple payments at once. The way Mass Payments works is in your PayPal account you simply upload a "Mass Payment File" which instructs PayPal to send out multiple payments. In IP.Nexus 1.1 we have added a feature to generate Mass Payment Files. When viewing the payouts screen in IP.Nexus 1.1, you'll notice 2 new buttons: When you click the "Mass Payment" button you'll be shown a list of payouts that are eligable for Mass Payments (that is, payout requests requesting to be paid by PayPal). Simply check the checkboxes for the requests you wish to fill and click the button at the bottom: A file will download to your computer which is the Mass Payment File that you will supply to PayPal. In your PayPal account you then simply go to the Mass Payment page and upload this file: PayPal will then allow to review and send out payments. Note that this feature requires a PayPal Business Account.

As mentioned in my blog entry last week, even though IP.Nexus 1.1 is still very much in development, we're going to be posting periodic blog entries throughout development to keep you up to date with the latest new features. In IP.Nexus 1.1, we're going to be adding reporting features for a number of different statistics: The number of items sold (grouped by package). The amount of income made (grouped by payment method). The number of new support requests created (grouped by department). The number of staff replies made in support requests (grouped by staff member). All of these charts can be viewed as a Bar Chart a Line Chart or a Pie Chart. Bar and Line Charts will show the results against time, while a Pie Chart will allow you to compare different groups. All charts allow you to customise the series shown, allowing you to have any number of series and to group results together as a series. All charts can also be viewed accross a number of different time scales:Results for a single day (On Bar and Line Charts, results will be shown for each hour of the day) Results for a week (On Bar and Line Charts, results will be shown for each day of the week) Results for a month (On Bar and Line Charts, results will be shown for each day of the month) Results for a year (On Bar and Line Charts, results will be shown for each month of the year) Results for all time (On Bar and Line Charts, results will be shown for each year) Of course, you can select which time period to focus on - so you could for example, view the amount of income made last year, or the number of support requests created 2 weeks ago (or whatever). (The options are contextual depending on the view - so if the chart you're looking at is for an entire year, only the dropdown for year will show.) Here are some screenshots: This is a line chart showing income for the year 2010: This is a bar chart showing the purchases for two different packages over the course of a week: This is a pie chart showing the number of replies different staff members have made in a month: This is a line chart showing the number of support requests for two different departments over the course of a day:

Since the release of IP.Nexus 1.0 we've had a great amount of feedback. Even though the next version of IP.Nexus 1.1 is still a ways off, I'm going to be introducing new features as we go along so that you know what to expect. One of the most frequent suggestions is some way to have multiple stock and pricing levels for products. IP.Nexus already has custom package fields to allow the user to select different variations of products, and now with Nexus 1.1, you can control stock and pricing based on those values. For example, you could specify how many of each size T-Shirt you have, or have options for additional services on a product which increase price. To demonstrate, I've created a short video (best viewed in full screen): As an aside while we're on the topic of product options, some of you will know that in Nexus 1.0, if a user adds a product with custom fields to the cart, the quantity cannot be altered on the "view cart" page. This has been changed in IP.Nexus 1.1 so each configuration is grouped with an update quantity box: I'll be blogging a lot more about IP.Nexus 1.1's new features over the coming months - if you're an IP.Nexus customer haven't done so already, please fill in our short feedback survey.

One of the benefits provided to IP.Board license holders is the skin generator which allows you to automatically generate an IP.Board skin using the colours you choose. If you're not familiar - have a look at our previous blog entry on it. Something which is frequently requested by skinners is a way to move the member box in the IP.Board header to a different location, so it isn't overlaying the logo; more like a traditional member bar. I've spent some time today working this in as an option to the skin generator. When you go to the skin generator, there will be an option under "Choose Options" that says "Add member bar?" - simply check this box, and the member bar will be included in your skin. Here's a screenshot of how it looks using the default colours: If you'd like this look on your community simply head over to the skin generator and download a skin in your colour choice. For instructions on how to import skins, please see our documentation. Enjoy!

Since we announced IP.Nexus back in May, the interest shown has been phenomenal. We have held two limited pre-sales of IP.Nexus providing participants with a beta version of the product to provide feedback and testing beyond our internal QA team. The ideas presented by the participants of these pre-sales has been invaluable. By using Nexus in real-world situations, users have provided some great ideas both for putting the finishing touches on 1.0 and for future versions. I wanted to go over some of the bigger things we've improved on since my original development entries so you can see how the feature-set has progressed thanks to these pre-sales. Improved Tax Classes and Shipping Methods For users selling physical items, we have improved and expanded on the tax class and shipping method functionality and interface. It is now easy to set up multiple tax classes with rates dependant on the location of your customers, and flexible shipping methods which are also location-dependant and taxable. See these short videos for an short overview: Upsell Lots of stores offer addon products and services for a product. When a user adds an item to the cart, this is a perfect opportunity to present such addons to customers to upsell. We've added this to IP.Nexus. This is an example of what you might see now when you add an item to your cart which has addon services: Improved IP.Downloads Integration IP.Nexus integrates with IP.Downloads in a way that allows you (or even your users) to add files to IP.Downloads and specify them as being paid. While this works great if you're selling single files, some users wanted a way to sell items through the IP.Nexus Store, but still be able to take advantage of the great IP.Downloads file handling features like secure non-web-accessible files and version handling. We've tightened up the integration between IP.Downloads to provide an additional option when uploading a file: the option to associate a download with an IP.Nexus package. To the administrator, what this means is, if you're setting up a package in IP.Nexus which you'd like to add a download to, you would then go to IP.Downloads and add the file there. You can use a category no users can access to make the process a bit more seamless, but if a user who hasn't purchased the package stumbles across the file in IP.Downloads, they'll simply be redirected to the Store if they try to download. To the user, when they purchase an item in IP.Nexus which has a file associated with it, they will then see a "Download" button when they view that package in the client area: Clicking that link will begin the download immediately - the integration is completely seamless to the user. You can of course, have downloads which are associated with more than one package, and packages that are associated with more than one download (multiple download buttons will show). IP.Nexus Release Schedule As we have received so much great feedback from our pre-sale beta testers, we have been implementing many of their ideas and fixing issues they have discovered. This does mean that the first supported release of IP.Nexus has been delayed as we add new requests and then must test those new additions. However, we believe that taking this extra time to mature and expand the product's feature set will benefit everyone in the long run. As IP.Nexus deals with commerce on your community we of course want it to be as stable as possible for its first release. We are anticipating a final, supported release of IP.Nexus sometime in October at the current time. We may do another pre-sale between now and then for those who cannot wait to try IP.Nexus so keep an eye on our Blog or subscribe to our Blog for updates. Thank you all for your interest!

In previous blog entries, we've talked about various things the user can do: generate and pay invoices, purchase packages, have custom packages, purchase advertisements, file support requests, etc. IP.Nexus features a centralised customer page from which you can view all the data the user has made. This is what it looks like: The buttons you see along the top allow you to send the user an Email, view the customer's history (which shows a chronological log of actions made to the user account, even if items have been deleted, discussed in more detail here) or go to the IP.Board edit member page. Wherever a member name is mentioned in the Nexus part of the Admin CP, it will link to this customer page. You can also access this customer page from the IP.Board edit member page via a link in the "Actions" dropdown menu. You can also search for a customer in the Nexus Admin CP. Details This box shows the customer's account details. You can edit these by pressing the edit button. Alternate Contacts This box shows all alternate contacts on the account and which purchases they are associated with. You can remove an alternate contact or manually add contacts. For more information on alternate contacts, see this blog entry. Notes This box contains miscellaneous notes made by staff members on the account. Staff members can (where they have permission) add, edit and delete notes. Purchases This box contains all purchases the customer has made. This will include items from the store, custom packages, IP.Downloads files, advertisements and any purchases made through third party applications. The icon on the left indicates the type of purchase (mouse over will provide a text description). You can see when the item was purchased, and when it expires, and you can edit, cancel or transfer the purchases. Purchases which have expired are highlighted amber, and purchases which have been cancelled are highlighted red. If a purchase is associated with another purchase, it will display in a tree format. For more information on managing purchases, see this blog entry. Invoices This box shows all invoices that have been generated on the customer's account. You can click on the invoice title to be taken to detailed information about the invoice, and can generate a new invoice by clicking the "Add Invoice" button. For more information on managing and generating invoices, see this blog entry. Support Requests This box shows all support requests created under the customer's account. You can visit the support request by clicking on the title. The icon on the left uses the same icons as topics on the forums to indicate if you have read the support request and if you have posted a reply to it. You can log a support request on behalf of the customer by clicking the "Log Support Request" button. For more information on support requests, see this blog entry. Referrals This box lists all members which have been referred by the customer (and only shows if there are any). It also lists how much commission the member has earned from each, and the total commission earned. For more information on referrals, see this blog entry.

IP.Board 3.1 has a great advertisement system. Administrators can specify code to appear in certain locations around the community to display banner ads. With IP.Nexus, it seemed logical to expand this to allow members of a community to purchase advertisement space. In order to do this, when you install IP.Nexus, the advertisement system in IP.Nexus will override the system in IP.Board. Even if you're not planning on selling advertisement space, the system in IP.Nexus allows you to set up multiple advertisements (for rotation), automatic expiry, per-ad permissions and other features. Setting up your own Advertisements The Admin CP has a page which lists all advertisements currently running on your community. These could be ones created yourself, or ones purchased by a user. Here you can add your own advertisements. You can specify either raw HTML code, or an image URL and link URL. The latter is required for click tracking. You can also specify which groups cannot see the advertisement and if it should expire after a certain number of clicks or impressions. The table indicates how many clicks and impressions each ad has received. When it has reached its limit, it will expire and become inactive. You can manually edit the current number of clicks or impressions the advertisement has by editing it. Advertisement Packages In order for a user to be able to purchase advertisement space, you will have need to created at least one advertisement package. These define the terms such as where the ad will show, who it should not show to and how many clicks/impressions it will last. You can manage your packages in the Admin CP. Purchasing Advertisements A user can purchase advertisements in their User CP. They can select a package, provide the URL for the target link, and either upload or provide a URL to an image. For security reasons, and to allow click tracking, users cannot provide raw HTML. Once a user has purchased an advertisement, it must be approved by an administrator. An Admin CP dashboard notification appears if there are pending advertisements, and unapproved advertisements will be highlighted on the listing page. To approve an advertisement, you would just click the cross indicating it is not currently active. When a user selects his purchase in the client area, a page will display the status (approved, pending approval, expired) and the current clicks/impressions of the advertisement. How advertisements are displayed IP.Nexus will display whatever ad is appropriate for each location. If there are no advertisements set up for a location, none will show, and if multiple are set up, one of the appropriate advertisements will be selected at random to show. This is calculated on each page load, however, advertisements are cached based on the appropriate location, so advertisements are not pulled on every page load to save resources. Each time an advertisement is used, it's impression count is increased. When an advertisement is clicked on, it's click count is increased. IP.Nexus will automatically disable an advertisement after it has reached it's allocated number of impressions or clicks.

In an application like IP.Nexus, it is important to have verbose logging features. Frequently you may wish to look over a the past actions of a customer to assist them, to check for suspicious activity or just for your own records. In IP.Nexus, every action taken on a customer account is logged and can be viewed from the customer's information page. IP.Nexus features a customer page in the Admin CP (which will be discussed more in a future blog entry). From here, you can access their history page. This is what it looks like: Please note that the interface shown in this screenshot is not finalised and subject to change. The log can be sorted so that newer actions show first, or older. You can also filter the log by event type, so for example, if you just wanted to see the transactions made for the account, you could uncheck all the boxes apart from transactions. As soon as you check or uncheck a box, the results list is immediately updated to reflect this (no page refresh). The actions logged are: Account Changes - if a member changes their name, address, telephone number, EMail address or password (or a member of staff does) the action is logged along with the previous values. If the change was made by a member of staff, which staff member is logged. A purchases is made (i.e. a package is added to the customer's account). The information for a package (such as the custom fields information) is edited. If the change was made by a member of staff, which staff member is logged. A member of staff (and who) cancels, reactivates or deletes a purchase from the customer account. A purchase is transferred to or from the account, the account it was transferred to or from is also logged along with the member of staff performing the transfer. A member of staff (and who) changes the purchase to a different package (this is done when a package is deleted from the Admin CP). A purchase expires. An invoice is generated. Whether the invoice was generated by the member (store purchase), the system (renewal invoice) or a member of staff (and who) is also logged. A member of staff (and who) resends, changes the status of or deletes an invoice. A coupon or account credit is used against an invoice. An invoice expires. The system automatically processes an invoice because the total to pay is zero. The customer makes a transaction. It is also logged if the transaction was automatically approved, held for review, or failed. A member of staff (and who) approves or denies a transaction. A support request is filed. If filed by a support member, it will be noted who, and if the support request was filed because of a received Email, this will also be noted. A staff member (and who) adds, edits or deletes a note on the customer's account. A staff member (and who) sends the customer an Email, and the content of that Email. The member requests a credit payout. A member of staff (and who) dismisses a credit payout request.

Updated 25th June: Due to popular demand, we have added support for POP3 account polling as well as Email Piping As mentioned in a previous blog entry, IP.Nexus supports Incoming Emails to be parsed as support requests. Technical Requirements In order for Incoming Emails to function, you will either need to configure your server to pipe Emails to a script, or a mail account which supports POP3. Customers using our hosting service who are paying $5 for IP.Content and IP.Nexus will be happy to know their accounts support piping. We strongly recommend piping over POP3 and customers not using our hosting service should check with their provider if either service is offered. If piping is not available, most EMail accounts (including GMail) support POP3. If using POP3 over piping, it is strongly recommended that you use a CRON job to poll the account. Check with your hosting provider if you are able to set up CRON jobs. How it works For Email piping: The user sends an Email to a special Email address which you have configured on your server to be piped to a script in IP.Board.Your server hands the Email to that script.If the Email is a reply, the script will detect this from the subject line and add the content of the Email as a reply. If it is a new request, the script will look for support departments with the Email address the Email was sent to and create a new request in that department. For POP3 polling:The user sends an Email to a special Email address which you have configured on your server to be piped to a script in IP.Board.IP.Board periodically checks (by default every 30 minutes, but this can be configured) if there are any new messages on your server.If a message is found, it is pulled back to a script in IP.Board.If the Email is a reply, the script will detect this from the subject line and add the content of the Email as a reply. If it is a new request, the script will look for support departments with the Email address the Email was sent to and create a new request in that department. If the user does not have an account, IP.Nexus will still create the support request and they will receive replies by Email. If the user then decides to create an account, IP.Nexus will recognise that they already have support requests and assign them to the new account so they can view them in the client area. Attachments are parsed as per the normal IP.Board attachment settings so you can Email images, zip files, etc. but any file types IP.Board wouldn't normally allow you to upload will be ignored. They will be displayed in the support request, and treated as normal attachments, just as if they had been uploaded in the client area. Information for Developers This is actually a feature of IP.Board 3.1, we just haven't previously announced it since there was no application until now. You can however, add incoming email support to your own application, and we have written a developer article here which explains how to do it: http://community.invisionpower.com/resources/documentation/index.html/_/hidden-staff-only/incomingemailsphp-r371

IP.Nexus allows account holders to create alternate contacts who can submit support requests on your behalf. On my account I have a package called "Basic Widget". I can create an alternate contact assigned to this package, and we will then both be able to submit support requests related to it, and view requests each other have submitted. This is the alternate contacts page: You can add a contact by pressing the button at the bottom, which will allow you to select which packages to assign them to. And of course can remove contacts by pressing the button in the list: When the alternate contact logs in and visits their client area, they will see, and can reply to, existing support requests, or create new requests associated with the package assigned to them: When viewing a support request in the Admin CP, support staff can identify who is the main account holder, and who is the alternate contact:

In our previous blog entry, we showed the front end for submitting support requests. In this entry, we'll show how staff members deal with support requests from the Admin CP. This is what the support listing in the Admin CP looks like: Staff members can select which departments and statuses to show using the filters at the bottom. Of course, only the departments they are allowed to access are shown. Support requests are sorted by the date of the last reply, ignoring any replies made by the same member (so if a member replies to their support request with more information, they remain in the same position in the queue). If there are any requests you are tracking or are assigned to you, buttons will appear at the top to allow you to view these requests, regardless of your current filter settings. Support requests you are tracking or are assigned to you are marked in the list with an icon. You can set the status on multiple requests at a time by selecting the checkbox for each one and using the dropdown menu at the bottom. For example, if you see duplicate tickets or spam. This is what the request screen looks like: The box at the top indicates the properties of the request. When you mouse over any of these, they will change to a dropdown menu allowing you to change them. After selecting an option, it will immediately be saved. The box below this indicates the package associated to the request. If the request is in a department which requires an associated package and there isn't one, or it isn't the correct type, an warning will be shown: When you change any of the attributes, such as department, the status of this will be updated via AJAX. If the associated package has custom fields or subpackages, clicking on the package name will reveal this information: You can change the associated package by clicking the link which will show a list of all the user's packages - the currently associated package will be highlighted: You can reply to a request using the box at the bottom. At the same time as replying, you can edit any of the attributes. You can also select a stock action, which will automatically fill in the reply and select the appropriate attribute values for you. You can then customise these or send the reply. You can add a hidden note to a request by pressing the button at the top, which will display a popup for you to type your note: The note will be displayed inline in the request: Notes only show to staff members in the Admin CP - the customer will not see them. You can control who is notified of replies to the support request using the "Notifications" tab at the bottom. This is handy if the customer requests another person to be CCd on replies.

In our previous blog entry, we discussed the management of the support desk. In this blog entry, we'll be showing the front-end to creating support requests from the client area. Members can view all of their support requests in the client area: Members can submit a support request by clicking the "New Request" button. The member can select a department, and if the selected department requires an associated package, they will be prompted to select one. IP.Nexus automatically works out which departments are available to a member based on their active packages and your department settings. Members can of course upload attachments to support requests. This is what a support request looks like: Members can reply to a support request right from the page, or, if enabled, set the status from the dropdown menu.

One feature we're really excited about in IP.Nexus is the Support Desk. Many administrators selling products on their site will need to offer support services to members. In this blog entry, we'll go through some of the settings available allowing you to control the Support Desk. Please note, the design of some areas shown in the screenshots shown are not finalised and subject to change. Departments IP.Nexus supports any number of departments. Each department can be: Private - members cannot submit support requests directly (for example, an "advanced support" department). Public - any member can submit support requests (for example, a "sales" department). Package associated - members who have purchased selected products can support requests (for example a "general support" department). Staff You can control which staff can access which departments. For example, you could have your customer service staff only see the sales and customer service departments, and your technicians only see the support departments. You can define a member or an entire group's access. If a member is in a group which one access level, and they also have their own access level, their own will override the groups. Statuses IP.Nexus allows you to customise the statuses for support requests. A set of standard statuses are in by default, but you can customise, remove or add your own. There are a number of settings allowing you to control the behaviour of a status, which you can see in this screenshot: Stock Actions One thing we really like about the Support Desk in IP.Nexus is something we call Stock Actions. Many Support Desks feature stock replies or canned responses. We find when we do technical support, than often a stock reply comes with an action. For example, if a support request needs to be escalated to Tier 2 support, we will give a stock reply, change the department to "Tier 2", change the status to "Open", and release control. Stock Actions in IP.Nexus allow this process to be automated. They can give a reply, and at the same time, set the status, department and assigned staff member on the support request. Incoming Emails IP.Nexus not only allows a member to reply through the client area, they can Email a new request or a reply to a request and IP.Nexus will process it. We will discuss a little more about the requirements for this feature and how it works in a future blog entry. You may have noticed in the earlier screenshot showing the department settings that each department can have an incoming Email address. For example, you could set IP.Nexus so Emails to "[email protected]" go to your sales department, while EMails to "[email protected]" go to your support department. IP.Nexus also allows you to define rules to filter incoming Emails. For example, if you are receiving spam from a certain address, you could instruct IP.Nexus to discard that Email.

In several of our previous blog entry about IP.Nexus, we've mentioned "credits". Credit, is simply money which is stored on the account. When IP.Nexus "pays" a users (commission for a referral purchase, for example) it adds credit to their account. The administrator can of course award credit manually from the customer page in the Admin CP. A user which has credit on their account can use it against purchases. On the checkout screen, they will see a link like this: Clicking that will deduct the user's credit amount from the balance to pay. If the amount of credit is greater than the balance, IP.Nexus will recognise that payment has been received and display the thank you page (or redirect the user to the download page for IP.Downloads purchases). In addition to using credit for purchases, if the administrator allows, users can request that their credit be paid to them. In the client area, users will see an "Account Credit" section from which they can request a payout. The user will then be alerted on the Admin CP dashboard that there is a pending payout request. They can view all payout requests in the Admin CP. Clicking the Pay option will allow admins to complete the payout request. For PayPal, this will take the admin straight to PayPal and the request will automatically be removed upon completion.

IP.Nexus is designed to give administrators the tools to monetize their community. Not only is this about selling products and services (or accepting donations) but promoting your site as well. Many customers have asked us about a referral system. Until IP.Nexus, there would have been little incentive for members to use such a system. With IP.Nexus, not only can members refer their friends using banners you create, but they can receive commission on products and services that members they refer purchase through IP.Nexus. You can enable referrals and configure the commission percentage in the Admin CP. You can also set up the banners that members can use. If you don't set any up (or in addition to any that you do), a simple text link will be available. Banners can be uploaded images, or you can supply an image URL. In the Client Area, members can view all the banners you've set up and the HTML and BBCode to display them. If somebody then clicks a banner posted on a website by one of your members and registers on your community, IP.Nexus will create a link between the two members. If that member then proceeds to make any purchases, and you have defined a commission percentage, IP.Nexus will award commission to the referring member in the form of account credit (we will discuss account credit in a future blog entry). The customer page in IP.Nexus indicates who a members was referred by and any members they have referred. In addition, you can see how much commission a members has earned through referrals: