5

Access Expiration Options

In DAP 4.7, we have added a new feature to the hourly dap cron where once every day (it’s hardcoded to run ONCE between 10:00 PM – 11:00 PM PDT) the cron will look for users whose access expired that day.

You can configure the Cancellation Options in DAP Products page -> Cancellation & Expiration tab.

Then based on these settings, the DAP Hourly Cron will check if the current time is between 10:00 – 11:00 pm PDT (Server time), and if yes, it will take a look at each product, pick up the ‘Expiration Action’ setting for that product, then get a list of ALL users whose access to that product has expired and apply the ‘Expiration Action’ to that user->product record in DAP users -> manage page.

The reason the DAP Cron checks the current time and runs the ‘expiration job’ only once a day is because running it too often will burden your server/resources as this job needs to pick up all products and then apply the cancellation rule to all users whose access has expired.

The main thing is to make sure it only runs once.. does not matter if that’s between 10 – 11 or 11 – 12 etc. We just picked the time to be between 10 – 11 PM (server time).

1) No Action

User’s access will auto-expire at the end of current recurring cycle. If the user re-signs, they will start from where they left off instead of starting over at day 1.
Infact this is how all older versions of dap already work.

If a user cancelled access to a subscription product before and say that the same user now wants to start back after a couple of months break.
If you have selected NO ACTION as this product’s expiration setting (in dap products page -> cancellation & expiration tab),
then when the user re-signs, they will start their dripping from where they left off and will not start fresh again from day 1.

Say a user’s access start date is 07/01/2014 and access end date is 07/30/2014, when the cron runs on 07/31/2012
and finds the user’s access has expired, it wont do anything.

If the same user re-signs for the same product on 08/30/2014 using the same email id, their access start date will be what it was before (07/01/2014) and their new access end date will simply be extended from what it was before. It will be set to previous access end date (07/30) + 30 days instead of new signup date (08/30) + 30 days. User’s access to product will remain expired. You will have to set post-expiry access to “Y” in dap setup->config page for access to ‘paid-for content’.

See this for more details: Cancellation

2) Remove From Product

If selected, dap will automatically find users whose access to this product has expired and remove user’s access to product completely for those users.
You will need this setting to prevent access for expired users. Users will completely lose access to product.
If these users signs up again, they will start over like a new member.

3) Set end date to previous day

To enable this option, you will have to first enter the following in /dap/dap-config.php file.

Please ftp to your site, find dap-config.php file, edit it and add this to your /dap/dap-config.php file:

Add it towards the top after php start tag (<?php) :

if(!defined(‘EXPIREACCESS’)) define(‘EXPIREACCESS’,’Y’);

IMPORTANT:  Replace all occurrences of backticks in the line above with single or double quote character.

Then upload back to your site (under dap folder).

We are forcing the dap-config.php setup in DAP 4.7 so users do not pick this option by mistake. We also want this feature to be BETA tested fully (in DAP 4.7) and then we will remove the extra steps (to add lines to the dap-config.php).(

After you set this in dap-config.php, this dropdown option will be available in the ‘expiration action’ dropdown.

If you pick this option for a product, then DAP CRON will automatically find a list of expired users (whose access has expired to this product) nightly and move the expired user’s access start and end day (set the access end date to the previous date).

When the cron wakes up and runs this job once once every night at 10:00 PM, it will move the user’s access start / end date forward in such a way that user’s access will remain expired but the access end date will not be stuck somewhere in past. It will be always set to the previous date (from current date).

Say a user’s access start date is 07/15/2014 and access end date is 08/15/2014.

When the cron runs on 08/16/2014 and finds the user’s access has expired, it will set the access end date to previous date.

So first time when the cron runs after the user’s access expires, nothing will happen. The access end date will remain 08/15 as it’s already set to previous date.

When cron runs on 8/17, it will move forward the the access start and access end window, so the new access start date will be 07/16 (moved forward by 1 day) and end date will be 8/16 (moved forward by 1 day).

This way the user’s access is still expired (as it’s always set to previous date) but the access dates are not stuck in the past.

If they re-sign, when DAP extends access, the access end date will be in the future instead of being expired.

If the cancelled user re-signs, the user’s access will not remain expired as their access will be extended from the current access end date to a date in future and the dripping will continue from where they left off.

IMPORTANT:  ADDITIONAL INFORMATION

1)  EXPIRATION: SET ACCESS TO PREVIOUS DATE

We recommend that you enable this option ON a test product first. DO NOT use this option on an actual live product. Add a few test users to the test product. Move their access start/end date manually to a date in the past .Make a note of it. Enable the admin option to ‘move date to previous date’ for this product. Then run the cron manually. Go back to dap manage users page and check the new access start / end dates for these users. If all looks good, then use it for live products.

2) CRON JOB:

The dap cron (dap-cron.php) runs once every hour at the top of the hour… but it will only do the expiration job between 10- 11 PM (server time). The expiration part of the cron only executes once a day.

To force run the cron, run this command in a browser (dont run cron too close to the top of the hour as it will collide with the normal running of cron ).

http://yoursite.com/dap/dap-cron.php?forcerun=Y (replace yoursite.com with the name of your site)

 

0

Troubleshooting Cron

The Problem

• Your autoresponder or broadcast emails are not going out (hourly cron job dap-cron.php)
• Your Affiliates aren’t being credited with sales (hourly cron job dap-cron.php)
• Your 1SiteAutomation/1ShoppingCart Orders are not being processed. (10-minute cron job dap-emailorder.php)

The Solution

One possible solution is that your cron job(s) aren’t running correctly.

DAP has two cron jobs. One that runs once an hour (dap-cron.php), and one that runs every 10 minutes (dap-emailorder.php).

You can see how to set them up here.

But in this post, we will see how to make sure your cron is actually set up correctly, or if it’s running correctly.

How To Know If Cron Is Running

1. Go to System > Logs and click on “Empty Logs”. That will fully clear out all logs.
2. Go to Setup > Config and set “Log Level” to “Log All Activity (during troubleshooting)” and click “Update“.
3. Wait for the top of the hour for the hourly cron job to run. So if the time when you’re doing this, is say 11:20 AM, then wait for 12:00 Noon. If time is 3:45 PM, then wait for 4:00 PM.
4. A few minutes past the top of the hour and go back to the System > Logs screen.
5. If you see hundreds of lines of text in the logs, then that means your cron job is running correctly. If you only see maybe 10-20 lines of text, then your cron job is NOT running correctly, and you need to make sure the cron job is actually set up correctly.

0

Troubleshooting Bulk-Add & Bulk-Import Of Users

Issue: You tried to bulk-add users to DAP (i.e., a bulk-import), and it is not working. No users have been added to the system.

Possible Solutions & Troubleshooting Tips

1. CSV File created?

First check if there's a .csv file that has been created in the folder /dap/bulk/ on your server. If there's more than one .csv file in there (from a previous import/bulk-add), then see if there's a file whose timestamp is close to the time when you actually did the "Users > Add > Bulk-add Multiple Users To A Product" action.

If there's no .csv file, then it's possible that the folder doesn't have the right permissions for DAP to be able to create the file. So CHMOD the "bulk" folder (in /dap/ folder) to 755. Then re-try the bulk-add again.

2. Is Cron job running?

You see a .csv file in there sitting for a few hours, but none of the users inside the .csv file have been added to DAP.

It's possible that the hourly cron job has either not been set up at all, or may have been setup incorrectly. Make sure the cron is setup and running correctly.

See both these links:

i) Setting up Cron

ii) All about Cron

3. Error in CSV File

Sometimes, it is possible that the .csv file was actually created, but it was actually corrupt. And you won't know this until the cron runs and that specific bulk-add job shows an error.

0

Your Host Does Not Support Cron Jobs

Question: You ask what to do if your host does not support cron jobs?

Short answer: You may want to switch your hosting company.

The basic idea of a cron jobs is that it allows you to run scheduled tasks, that run automatically, frequently, silently, in the background, without requiring manual intervention.

DAP uses cron jobs to do things like…

• Send out autoresponder emails
• Send out broadcast emails
• Manage your outgoing queue of emails so that you can stay within your cheap web host’s strict hourly email sending limits
• Process and manage affiliate data & commissions , and
• Do some clean up jobs

Any membership plugin that offers email broadcasts, autoresponders and other bulk tasks, will likely ask you to set up cron jobs for sending out emails. You couldn’t possibly send out an email blast to even 500 members in real time as your browser will timeout.

DAP requires you to set up a cron job to do all of the tasks above.

If yours doesn’t, seriously you have only 2 choices…

1. Stick to your host but lose the ability to use powerful scripts like DAP.
2. Or do the smart thing and move to a better host. There are plenty of good ones out there, and there are a few we recommend highly, and they’re very inexpensive.

35

DAP-Supported Shopping Carts

Last updated: 09/02/2014

Direct Integration with Shopping Carts and Payment Processors

UPDATE: We are now authorized resellers for Authorize.net. If you’re in the US or Canada, click here to apply. If you’re in the UK, then click here.

DAP directly integrates with the following Payment Processors without the need for any additional third-party shopping carts:

• Stripe (new!) – via DAP Shopping Cart
• Authorize.net (US/Canada / UK) – via DAP Shopping Cart
  
• 2Checkout.com
• CCBill.com
• ClickBank
• ClickBank PitchPlus (1-Click Upsells)
• Digiresults
• DealGuardian
• Google Checkout
• e-Junkie (FYI: e-J does not allow recurring payments)
• JVZoo
• Paypal Standard – direct & via DAP Shopping Cart
• Paypal Express Checkout – direct & via DAP Shopping Cart
• Paypal Website Payments Pro (legacy) – via DAP Shopping Cart
• Plimus
• WorldPay
• WSO Pro (Warrior Plus)
• Zaxaa

DAP also integrates with the following Shopping Carts

• 1SiteAutomation.com (a 1shoppingcart private label)
• InfusionSoft
• Nanacast
• Ontraport (prev. Office Auto Pilot)
• Premium Web Cart
• WooCommerce
• WP eStore

Indirect Integration through 3rd Party Shopping Carts

Since DAP integrates with Shopping carts like WooCommerc, 1SiteAutomation.com (our white label of 1Shoppingcart), e-Junkie, Premium Web Cart and Infusionsoft, that means that it also integrates (albeit indirectly) with all of the Payment processors and gateways that these carts support. So, for example, since DAP works with 1SiteAutomation, it essentially integrates with all payment providers supported by 1SiteAutomation, like:

Bank of America
BluePay
Concord EFSNet
Cybercash
DPI Merchant Services
e-Commerce Exchange
Echo Inc.
ECX QuickCommerce 3.0
Epoch Systems
eProcessing Network
EPS SecureNet
EWAY (Australia)
FastTransact
Firepay
GoRealTime/EPP
GoRealTime
iBill
IntelliPay ExpertLink
IONGate (Costco)
iTransact RediCharge
LinkPoint Secure
MCPS WebLink
MerchantPartners
Moneris
NETbilling
Network Merchants
Paradata
PayCom Processing
Paymentech (direct integration via Authorize.net)
PayPal Payflow Pro (via e-Junkie)
PayReady
Planet Payment
PRIGate
PSiGate
RightConnect
RTWare WebLink
Shift4
SkipJack
StrataPay
Surepay
TrialPay (via e-Junkie)
TrustCommerce
USAEpay
uSight
VeriPayment
VeriSign PayFlow Pro
ViaKlix (Nova Systems)
YourPay

For the full list and more details, click here

1-Click Upsells

If you use the DAP Shopping Cart Plugin, you can do 1-Click Upsells/Downsells like the pros, without the need for any external shopping cart or upsell service provider.

The free DAP shopping cart that comes with your DAP purchase allows you to do unlimited 1-Click Upsells using Stripe, Authorize.net and Paypal Website Payments Pro (legacy).

However, for doing 2-Click Upsells/Downsells with Paypal Standard, you need our Paypal Upsell-Tree plugin that is sold separately. Or you can also get this plugin for free with our Platinum subscription.

Of course, if you need advanced shopping cart features – like ability to calculate shipping, tax, and coupons – then you should consider using 1SiteAutomation.com.

1ShoppingCart & GoDaddy

If you want automated recurring order processing using 1ShoppingCart (1SC) or 1SiteAutomation.com, then DAP needs to be able to process the recurring email notifications sent by 1ShoppingCart, which it does on the back-end when the DAP Cron Job runs every 10 minutes.

However, if you’re using Godaddy as your web host, then because GoDaddy disables a mandatory PHP library (“imap”) on all their servers for some reason, DAP is unable to process the recurring order email notifications from 1ShoppingCart.

This is not an issue if you are using GoDaddy as just your domain name registrar, and using some other service like Liquid Web or Hostgator as your web host.

But if you’re using 1SC & GoDaddy hosting, you will have to end up doing manual cancellations if any member cancels their subscription, or if their credit card fails and their recurring payments don’t get processed.

Please note that 1ShoppingCart order processing works great with all other (non-GoDaddy) hosts.

5

Troubleshooting the Affiliate Program

The reason why your affiliate program may not be working as intended, is almost always because of incorrect setup and/or testing parameters.

Quick Troubleshooting Tips

• A good clean test was not carried out, allowing the proper cookies to be set
• You were already logged in as DAP admin, and did not log in correctly as your new buyer
• You were using the same browser to log in as DAP admin, DAP user, new buyer, etc, thus causing a problem for DAP to set and track the affiliate cookies.
• Affiliate commissions had not been set up in advance of the purchase
• You used an existing user in the system (who may or may not have been previously attached to an affiliate) to test, which is incorrect – you must create brand new user.
• Login Xpress was not setup for the payment integration – which means the buyer has to actually log in to the member’s area in order for the tracking to be completed
• The hourly Cron job hasn’t run twice yet (which is when the commissions are credited to the affiliate)
• Resulting affiliate commission is too low to be calculated (eg. when using a test purchase of a 1 penny product)

A Clean Test

1. Make sure you have set up affiliate commissions for the Product on the “Affiliates > Commissions” page
2. Delete the email id of the test user – with which you are going to make a purchase – from Users > Manage page.
3. Log out of DAP admin, WordPress admin, clear your browser cookies, and restart your browser (unless you are going to use a completely different browser where you are not logged in as DAP admin or WordPress admin – double check that anyway).
4. Click on an affiliate link (that you have previously sent yourself via email). Don’t manually type it in the browser window, lest you make an error in the affiliate id. Make sure you use a valid link.
5. When you land at your web site, now make a real purchase as a new user. Don’t use email of existing user. If the email you wish to use is already used up by a test user in the system, then be sure to delete that user from your system before making the purchase. This is very critical, because an existing user who is currently not attached to an affiliate, cannot be made to get attached to another affiliate just because you clicked on that affiliate’s link before making a purchase (using existing user).
6. If you haven’t already set up Login Xpress (where buyers are automatically logged in to member’s area), then you MUST log into the members’ area using the user id that you used to make the purchase (you DO NOT need to log in separately if Login Xpress is setup, because then you would get auto-logged in upon purchase).
7. Now in a separate browser (like Chrome or Firefox), log in as DAP Admin, go to “Users > Manage” page to make user the new user account has been created, and that there is actually a transaction id listed under the Trans ID column of the user’s row.
8. There should be one. Click on that transaction id, it will bring you to the transaction details page
9. Look at the status of the transaction – it should say SUCCESS at this point.
10. Now wait for the top of the hour, for the DAP hourly cron job to run. When the cron finishes running, refresh the transaction details page. The status of the transaction should have changed to Processed Affiliations Successfully. (If you don’t wish to wait for the top of the hour, you can always run the cron manually by going to http://YourSite.com/dap/dap-cron.php – remember that if you run it manually for this one time, then there will be no way to know if the cron has actually been set up correctly and running on it’s own. But that’s a whole another topic).
11. Now when you log in as the affiliate in yet another browser, you will find the commissions credited for this buyer’s purchase.

Here are some more troubleshooting steps:

1A) Affiliate was not credited with a sale

There could be many reasons for why the affiliate was not credited to the sale.

a) Buyer didn’t click on any affiliate links before purchasing the product
b) Buyer did click on an affiliate link, but somehow (intentionally – or not) cleared her cookies before buying the product
c) If you haven’t set up Login Xpress, then buyer needs to log in to your membership site – which they probably haven’t done yet (if this is the case, see if DAP supports Login Xpress for your payment processor)
d) The hourly cron job on your DAP site hasn’t run yet (hourly cron has to have run *after* the buyer has logged in to their account)
e) You have not set up any affiliate commissions for the Product on the “Affiliates > Set Commissions” page

 

1B) Affiliate was credited with the “Lead”, but not the “Sale” (no commissions awarded)

Short answer: You’re not using “Login Xpress”. And you probably forgot to initially set up the affiliate commission for the Product in question, under “Affiliates > Commissions“, and only set up the commission record 7 days (or more) after the actual sale happened (the sale for which your affiliate got the “Lead”, but not the “Sale” (and in effect, no commissions). We call this the “7 Day Commission Cutoff Period”. So affiliate will not be awarded the commission. You just have to pay them offline.

Long answer: DAP has two ways of awarding commissions:

a) Using Login-Xpress, where affiliates are attached to buyers instantly after purchase, and when the cron job runs at the top of the next hour, the affiliate commissions are credited to the affiliate’s account.

b) In situations where Login-Xpress is not possible (due to restrictions with the specific payment processor), the affiliate is attached to the buyer only when the buyer actually logs in to your membership site. Believe it or not, not everyone logs in the same day (sometimes not even for a few days after) they’ve purchased your product. So it’s possible that the affiliate/buyer connection is not made by DAP until a couple of days later.

Now consider these scenarios…

Case X: Buyer clicked on affiliate link at work. They purchased the product at work. You don’t have Login-Xpress setup. So only way for affiliate/buyer connection to be made, is when your member logs in to your site for the first time. So they went home that evening, logged in for the first time from home, but there’s no affiliate cookie at home. Normally your affiliate is screwed. But DAP goes the extra mile to be fair to affiliates. If your buyer logs in to your membership site even a couple of days later from work, since the cookie is still on their work computer, the affiliate and buyer are now connected, and affiliate gets credit for the sale.

Case Y: Buyer never clicked on any affiliate link. They bought your product. You did not have Login-Xpress setup. So only way for affiliate/buyer connection to be made, is when your member logs in to your site for the first time. So since they never clicked on any affiliate link, there’s no affiliate cookie. They buy your product, log in to your site, and their account has no affiliate attached to it. Then a couple of days later, they’re surfing the web, and happen to read an article from one of your affiliates, and intentionally or not, click on that affiliate’s link. Now that affiliate’s cookie is stored on their computer. The next time they login, DAP thinks “Ah, this is the same as Case X (above): No affiliate attached already, but now finding affiliate cookie – same as the buy at work/login at home example. So DAP will go ahead and give that affiliate credit for the sale, even though the referral was not made prior to purchase. So to avoid awarding affiliates incorrectly (after the sale), DAP is deliberately programmed to look for transactions only for the last 7 days, every time the DAP hourly cron job runs.

2) Affiliate Program Life Cycle

1. You have already set up a “Per Sale” commission for the Product being purchased.
2. Visitor clicks on affiliate link and affiliate cookie is set on her computer
3. Visitor goes on to buy the product
4. a) If you HAVE setup Login Xpress, then member is logged right into the members’ area.
   b) If your payment processor does not support (or you HAVE NOT setup) Login Xpress, then buyer gets welcome email and logs in to your member’s area: This is when the affiliate is actually credited with the referral. So it is critical that if you’re testing the affiliate program, make sure you log in to the new member’s account.
5. So regardless of whether they’re auto-logged in right after purchase, or whether they log in a few minutes after the purchase after they’ve received their log in information via email, the login action takes place at this point.
6. At the time of this login, the only thing that happens is:
   a) DAP records in the database that this buyer was referred by the affiliate set in the affiliate cookie.
   b) If you have set up any “Per Lead” commission, then this lead commission amount is instantly credited to the affiliate’s account. So if the affiliate were to log in to his account exactly at this second, they would just see that they have gotten the “Per Lead” commission credited to their account. If there is no “Per Lead” commission, then nothing is credited to Affiliate account at this point. So the affiliate would see no “Sale” commissions yet.
7. At the top of the hour after the buyer has logged in to their member’s area, the DAP Hourly Cron (dap-cron.php) runs. It sees that Buyer X has been referred by Affiliate Y. It also sees that no “Sale” commissions have yet been credited to the affiliate for the purchase. It then looks up the Affiliate Commissions that you have previously set up at “Affiliates > Set Commissions”, calculates the commission to be credited (“Per Sale Fixed” or “Per Sale Percentage”), and then credits affiliate’s account with that amount.
8. If the affiliate were to log in to his account at this point, they would just see that they have gotten the “Per Sale” commission credited to their account.

3) Affiliate is unable to access the Affiliate-Info page.

So you created an “Affiliate” product, created a free sign-up form, and an affiliate signed up to this product, and is trying to log in and access the page, but is unable to, and is getting the “Sorry, you don’t have access to this product” error.

There could be many reasons for that (main one is #1 below):

a) Anyone who signs up through the “Direct Signup HTML Form” is added as a “Free” user. Which means, they can only access content that has been marked as free. So if you have created an “Affiliate” Product, and have added the affiliate-info page to that product, make sure that page is accessible by free users too, by clicking on the “edit” link next to the page, and on the resulting popup, set “Accessible to
Free users too?” to “Y”.

b) You have not even made the affiliate-info page protected under the “Affiliate” product

 

4) Double Credit of Affiliate Commissions for the same purchase

This is not really a double-credit for the same purchase, even though it appears to be so.

Sometimes you may enter a manual transaction for a purchase around the same time that DAP is processing an automated transaction for that purchase.

That means, there are now two transactions in DAP for the same purchase – one manual, and one automated – which can cause problems in accounting.

That’s usually how you end up crediting double commissions to the affiliate who referred the user, because all affiliate commissions are calculated from sales, and if you have two separate transactions for the same purchase, then the affiliate will get credited twice for the same referral.

So if you see two credits for the affiliate, you must first note that it is not for the same transaction, but for different transactions (note the different Trans Id‘s) on the Affiliates > Reports page.

So be careful when you’re entering Manual transactions. Those are meant only for when there is no way to automate the recording of a purchase (because they paid offline) and you’re unable to bring the transaction into DAP automatically.

If you see two affiliate commission credits (one for the automated transaction that DAP picked up, and one for the Manual transaction that you entered), then just refund the manual transaction in DAP. There will probably be a change to the user’s access because of the refund. So make a note of the current access of the user BEFORE you do the refund, and then AFTER you’ve processed the refund, go back to the User’s details on the Users > Manage page, and manually adjust their access to make sure it’s accurate.

1

Troubleshooting 1ShoppingCart Integration

There are a few different reasons why this may not be working.

1. Check if Cron is running

The DAP email-processing cron that processes the 1SC emails may not be running. Check your webhost control panel -> Cron job settings. Make sure dap-emailorder.php is setup to run once every 10 minutes.

2. Incorrect Setup of Billing Email Id

The billing email id you have entered in DAP at Setup > Config > Payment Processing , should be entered into the “Order Notice Email – Primary Destination” field in your 1SiteAutomation/1Shoppingcart account, on the Setup > Orders > Notifications section. If by chance you enter it into the “Order Notice Email – Primary Destination” field, it WILL NOT WORK.

3. No Notification Emails from 1SC

The DAP cron is running but 1SC payment notification emails are not reaching your mail server. Check the email account where you expect to receive your 1SC payment notification emails and see if the order notification email from 1SC is in that mail box.

4. Incorrect Mail Server Settings

The cron is running and the 1SC order notification email is reaching your mail server – but you did not configure the mail server settings correctly in DAP Dashboard -> Setup -> Config -> Payment Processing.

Email Server Where Order Emails Come In
Email Server User Name
Email Server Password

5.”Read” Or Deleted Emails

DAP only processes order notification emails that are in the “Unread” status, to prevent previously processed emails and other non-DAP emails from being repeatedly processed.

Also, if you “pop” off the emails from that mail box (means, your email client like Outlook or Thunderbird or Gmail is “removing” your emails from the server when it retrieves them), it means that when DAP logs in to that billing email address, there are no emails there to be processed – the mailbox is empty, or the 1SC payment notification emails have somehow gotten deleted from that mailbox.

So it is possible that DAP is able to connect to your email server, but DAP is not finding any “unread” emails. Please login to your email server and mark all the payment emails that you want DAP to process… as “unread”. And also make sure that your email client does not remove the emails from that mail box.

6.Product Name Mismatch

There might be a “Product Name” mismatch. The product name has to be EXACTLY the same (including case, spaces, etc) in both DAP as well as in 1ShoppingCart. So if you have created a product by name “Widget A”, make sure your 1shoppingcart product also has the exact same name “Widget A”.

If everything is setup correctly, DAP cron will run every 10 minutes and try to process all 1SC emails.

The next time the DAP cron will run (every 10 minutes), it will pick up all the unread payment emails from 1SC.

7. Empty “Thankyou-Email Body/Subject”

Welcome email is not getting sent.

Select the product, and make sure there is some text in the “Thankyou-Email Subject” and “Thankyou-Email Body”. Whatever is in these fields is what gets sent immediately after someone purchases that product (or right after you give them access from the backend).

Now go to DAP Dashboard -> Users -> Add .

Select the product and manually add user. Now see if the thankyou email gets sent to that email id. If it got sent, then your product setup is correct.

Also check the DAP Dashboard -> Orders . Search for all orders, look up the order for the particular user in question by email.

Check the payment status and make sure there is no error there.

If you did all this and things are still not working, please do this:

1. Set DAP Dashboard > setup -> Config -> Log Level -> Log All activity
2. Re-run the 1SC test purchase
3. Check the DAP Logs (DAP Dashboard > System > Logs) and send us the log text in there for troubleshooting by pasting it into a new support ticket.

8. Sending Email & Password To Buyer

Make sure you have set the thank-you message with the right merge tags for Email and Password.

9. Manually Running Cron

First set DAP Dashboard > setup -> Config -> Log Level -> Log All activity

If you feel that the orders were not processed in dap, then just login to the 1SC email account where the sales/payment notification emails are sitting, and mark those orders/emails as UNREAD that you want dap to process.

Then manually run the cron script dap-emailorder.php cron by visiting the following link in the browser.

http://www.yoursite.com/dap/dap-emailorder.php

Replace yoursite.com with the name of your site.

It will just display an empty screen when complete.

Then check “Users > Manage” to see if user has been created.

– Veena Prashanth

2

Silent Import

You wish to do what we call a “silent” import. Basically, you don’t want DAP to send out the instant “thanky-you” email to the users being imported.

You may want to do this, say, if you wanted to import a bunch of users into DAP first, without DAP sending them any kind of emails at all, do some preliminary testing, make sure their settings, product access, etc, are all correct, before notifying them of any changes.

Here’s how to do a “Silent Import” with DAP

1. Remove the “ThankYou-Email Subject” and “ThankYou-Email Body” from the Product into which you wish to import users. Save it in a text file for later, and save the Product.

2. Go ahead and do the bulk-add of users from “Users > Add > Bulk-Add Multiple Users To A Product”.

3. Wait for the DAP Hourly Cron to run and finish importing all users. Since the “ThankYou-Email Subject” and “ThankYou-Email Body” of the Product is empty at the time of import, DAP won’t send out those emails.

4. Once all the users have been imported, put back the “ThankYou-Email Subject” and “ThankYou-Email Body” text content, and save the Product.

OPTIONAL

5. At a later point, if you want, you can send out an Autoresponder email – or even better, a Broadcast email – with the merge codes for the email and password, if you want the newly imported users to get their passwords, or if you wish to notify them of anything at all (like the new system you’re using, their new account info, a general “what has changed recently” type of email, etc).

5

Installation / Pre-Installation FAQs

What are the minimum web-hosting requirements to run DAP?

See “Minimum web-hosting requirements”

What web hosts to you recommend?

See “DAP-Certified Web Hosts”

I’m getting an error during installation

See this post for more details about errors .

How can I avail of Free Installation?

See “Free Installation”

How do I setup Cron?

Setting up Cron Jobs

All about Cron Jobs

Your host does not support Cron Jobs

24

1ShoppingCart Email Order Processing

If you’re using 1ShoppingCart or 1SiteAutomation.com (our private label of 1SC), if you want your users to be automatically logged in to their DAP membership area upon completion of purchase, then refer to this documentation on how to setup Login Xpress with 1ShoppingCart.

If you only sell one-time products, then the 1SC Login Xpress is the only thing you will need to integrate DAP and 1SC.

However, if you sell RECURRING products via 1SC, then you need to set up the email parsing of orders to allow DAP to process recurring payment notification from 1SC, as described below.

The reason for this, is that 1ShoppingCart, while very robust as a cart, does not trigger payment notification messages on the backend (like Paypal can do with IPN) when recurring payments comes in for a member.

So, we at DAP have created an exclusive “Email Order Processing” feature, where DAP will log in to your billing email inbox (where your 1SC email notifications come in) and then check your emails as if it were your personal assistant, and then process any orders that match your DAP Product names.

That is how DAP is able to do automated processing of Cancellations and Failed Recurring Payments.

For 1ShoppingCart and ClickBank, DAP does “Email Parsing” of orders.

Setting Up “Email Parsing”

Basically all you will be doing here is telling DAP where your payment notification emails from 1SC come in, and how to go fetch those emails so the recurring payments can be processed automatically, without you having to lift a finger.

1. Log in to your 1SC account. Then go to “Setup > Orders”. Copy the email id that you have entered into the “Order Notice Email – Primary Destination” field. Please note that 1SC DOES NOT send recurring billing notifications to the email id in the “Secondary Destination”. So be sure you use the email id from the “Primary Destination” field.

So let’s say you have set the primary destination email currently, to point to say ‘billing@yoursite.com’. Now make sure that the emails in your billing@yoursite.com inbox remain in ‘Unread‘ status, because when DAP logs in to check your recurring notifications, it will be looking at only Unread emails. It will not touch the ones that are already read.

2. Go to DAP Admin Dashboard > Setup > Config > Payment Integration .

3. On this screen, configure the following fields…

Email Server Where Order Emails Come In : mail.yoursite.com

Email Server Protocol (pop3/imap) : imap (no need to change this)

Email Server Port : 143 (probably won’t need to change this)

Email Server Protocol (ssl/nossl) : nossl (probably won’t need to change this)

Email Server User Name : billing@yoursite.com (enter email id copied from Step #1 above)

Email Server Password : yourpassword (the password to your email inbox for the above email address)

That’s it as far as setup is concerned.

Additional Notes

4. Set up your sales page as you would normally do when accepting payment through 1ShoppingCart. The only thing you need to make sure is to use the exact same “Product Name’ in your cart as well as within DAP.

So, if you set up a product called “My Membership Site” within DAP, then use the same name “My Membership Site” in your 1SC product name.

5. During installation, a Cron job (dap-emailorder.php) would have already been set up in your web hosting cpanel, to run every 10 minutes. So, every 10 minutes, DAP will automatically check the email id specified in Email Server User Name (the email id from Step 1).

If there is a payment notification (first time or recurring payment) for a product name that matches a product name in DAP, then it will automatically add that customer to DAP as a member if they’re a new member, or if they’re an existing member and it was a recurring payment notification, then DAP will “extend” their membership access by a month (or whatever your recurring cycle is), so that they will continue to get access to your membership site until the next payment comes in.

Testing

Try out some test purchases first. Make sure you try out the full purchase and full user experience, end-to-end.

WARNING 1: If you ever change the name of your product in 1ShoppingCart, or within DAP, make sure that both DAP and 1SC Product names are in sync.

WARNING 2: Do not use SKU in 1SC while defining the product. DAP will not parse the emails correctly if you use SKU.

More: Troubleshooting 1ShoppingCart Integration