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).
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
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.
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) :
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.
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)
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.
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
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.
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:
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.
When you look at the “System > Job Queue” screen, you see one line that shows this error…
Message: Error in CSV File
You were probably trying to to Bulk-Add Users to DAP. Or do a Broadcast email to a CSV file. In either case, there was an error in processing your request, because one of the following happened:
1) The CSV file could not be created in /dap/bulk/ folder because of a permission issue (try CHMOD 755), so when the cron task ran, it could not find the CSV file (or the file was corrupted for some reason).
2) The list of email addresses within the CSV file were not in the right format – Order should be: Email,FirstName,LastName ( LastName is optional)
How To Fix It
If a job fails, then there’s no way to “fix it and re-run it” right now. So you basically have to delete the job, and then submit a new one. So if a Bulk-Add job errors with the above message, then here’s what you need to do…
A) Click on the “Delete Jobs In Error” link on the “System > Job Queue” page. That will delete all jobs that have failed for whatever reason.
B) You should also clear out the /dap/bulk/ folder to make sure you delete any old, or errored out CSV files from that folder.
Question: You ask what to do if your host does not support cron jobs?
Short answer: Fire them and get a better host.
Ok, 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…
Any membership script worth more than $1, should ask you to set up cron jobs for sending out emails. You couldn’t possibly send out an email blast to even 100 members in real time. If your membership script doesn’t require you to set up a cron job, then they’re worth absolutely nothing.
But DAP requires you to set up a cron job to do all of the tasks above.
And even the cheapest of the cheapest web hosts will allow you to set up a cron job.
If yours doesn’t, seriously you have only 2 choices…
The choice is pretty obvious, no? 🙂
Last updated: 09/02/2014
DAP directly integrates with the following Payment Processors without the need for any additional third-party shopping carts:
DAP also integrates with the following 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
DPI Merchant Services
ECX QuickCommerce 3.0
Paymentech (direct integration via Authorize.net)
PayPal Payflow Pro (via e-Junkie)
TrialPay (via e-Junkie)
VeriSign PayFlow Pro
ViaKlix (Nova Systems)
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.
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.
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.
The reason why your affiliate program may not be working as intended, is almost always because of incorrect setup and/or testing parameters.
Here are some more troubleshooting steps:
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
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.
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
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.
There are a few different reasons why this may not be working.
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.
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.
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.
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
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.
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.
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.
Make sure you have set the thank-you message with the right merge tags for Email and Password.
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.
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
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.
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.
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).
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.
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 ‘firstname.lastname@example.org’. Now make sure that the emails in your email@example.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 : firstname.lastname@example.org (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.
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.
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.