Transactions – DAP Documentation

Processing Offline Payments

DAP supports offline payments.

Your buyer does not have to necessarily pay using one of our supported payment processors. You can also use un-supported processors, like say a physical Check/Cheque, Western Union, Wire Transfer, Bank Deposit, etc.

So when someone pays you offline, if you just want to give them access to a product or membership level, then see:

Creating New Users Manually

If you also want to record (or book) the payment in DAP, so that DAP can include the payment in the Admin reports, then keep reading.

Adding A Manual Transaction

And normally, when the user logs in after they’ve received the login information from DAP, when they log in, if they had an affiliate cookie on their system, the affiliate will get credit for their purchase, and will get credited the commission within an hour of their logging in (when the hourly DAP cron runs).

But if you want to override this and manually give some other affiliate credit for the purchase, then see:

Manually Crediting Affiliates

Adding A Manual Transaction

Once you have manually added a user, when you search for them on the Users > Manage page, you’ll see their row with “FREE” or “PAID” under the “Trans Id” column.

1) Enter an order (transaction) into the system by clicking on “Add Trans” (which stands for “Add Transaction”).

2) When you click on the “Add Trans” link, you will see a small popup appear (see image below) that allows you to manually enter an amount. So if the payment you received offline was say $97, then you would enter “97” or “97.00” in the “Order Amount” field and click on “Submit”.

3) Once you’ve entered a manual order, the “Trans Id” column will change from “FREE” or “PAID”, to an actual transaction id (or order id) – in the example below, it turns to Transaction Id “3”.

Affiliate Commissions For Offline Payments

DAP is one of the very few membership platforms that will let affiliates earn commissions on offline payments too.

And in fact, DAP will credit affiliates for not just offline payments, but for any payments that you accepted outside of the payment options listed on your web site.

So, for example, you’re using Paypal and Authorize.net buttons on your site. And someone wants to send you a check (cheque) in the mail, or they want to send you money via Western Union, or wire transfer, or they call you and you accept their credit card information by phone, or any other such offline methods.

In this case, DAP can still give credit to the right affiliate for the sale. Here’s how…

1) Add Manual Transaction

First you add the user manually, by going to DAP Admin > Users > Add.
Once you’ve added them to the product, come back to DAP Admin > Users > Manage.
Search for the user by email
On the user data row for that Product, initially, under Trans Id column, it will show PAID (see image below)
Step 1: Enter a manual transaction by clicking on Add Trans (which stands for “Add Transaction”). That will record your offline payment in DAP. So now there’s an actual payment associated with that user’s sign up.
When you click on the “Add Trans” link, you will see a small popup appear (see image below) that allows you to manually enter an order. So if the offline payment was for say $97, then you would enter “97” or “97.00” in the “Order Amount” field and click on “Submit”.
Once you’ve entered a manual order, the “Trans Id” column will change from “PAID” to an actual transaction id.

That’s it.

By this time, the user would’ve received their “Welcome Email” from DAP, which will have their login info to log in to your site.

And when they log in, if they have an affiliate cookie set in their browser (which they would, if they had clicked on an affiliate link at some point before they contacted you and asked you about a non-standard, offline payment method), then when they first log in to your member’s area, DAP will pick up the referring affiliate’s id from the affiliate cookie, and give credit to them for the sale.

And when the DAP hourly cron runs at the top of the next hour, that affiliate will be credited with any commissions that you’ve set up for that product.

Affiliate Reports

DAP offers a number of affiliate statistics on the “Affiliates > Reports” page.

Here’s how it looks as of DAP v4.2.1.

1) Email Id of Affiliate

This is the field where you would enter the email id of an affiliate, if you want to generate a report specifically for an affiliate. If you leave it blank, the report will include all affiliates.

2) “From” & “To” Dates

By default, if you leave these fields blank, then DAP will assume “today’s” date – i.e., the date whenever you’re viewing this page.

3) View Performance Summary

This is the most detailed report available. This is the report being viewed in the above screenshot. For a given time period, for a given number of affiliates (“all” affiliates if (1) is left blank above), it shows…

Affiliate Id
Full Name
Email id
Clicks generated during selected period
Referrals generated (includes total of both Free and Paid referrals): If the referred member actually bought something, it constitutes a “Paid” referral. If they simply signed up, say, for your free newsletter or free report or free product, then it is counted as a “Free” referral.
Commissions Earned: This is the actual amount credited to the affiliate’s account during the selected period
Sales Generated: This is the amount of the actual sale (purchase) generated for your membership site.
Earnings Per Click (EPC): This is an indicator of how well your web site is converting clicks into signups/members. So if an affiliate sent you 100 clicks (on their affiliate link), and 5% of them signed up for your “FaceBook Secrets” membership product by paying $10 each, it means a total revenue of $10 x 5 = $50. And if you were paying 30% affiliate commissions for the product, then the affiliate earned $15 in total.Total clicks sent: 100
Total affiliate earnings from those 100 clicks: $15
Earnings Per Click (EPC) = $15/100 = $0.15 – which means, 15 cents per click.The higher the EPC, the easier it will be for you to attract other JV partners and super-affiliates.

4) View Earnings Details

This shows the breakdown of each purchase referred by each affiliate. It’s a detailed view of the affiliate earnings, that lists each and every transaction (order) in the system that was referred by affiliates, all generated for the selected time period. It displays…

Affiliate Id
Full Name
Email Id
Product (name) that was purchased by referred buyer
Referral Date (when affiliate was associated with buyer)
Date/Time of actual transaction
Trans Id: This is the transaction (order) id for the actual purchase
Earning Type (L: Lead, S: Sale): Says what type of a commission credit it was – whether it was a “Pay Per Sale” credit or a “Pay Per Lead” credit.
Id of User Referred: This tells you the actual user id of the buyer who was referred by the affiliate.

5) View Payments

This shows all payments made to affiliates during the period.

6) Refund Period

This is a config setting that you can change in Setup > Config. This is what drives which orders are picked up for affiliate payment. See this article for more details.

7) View Due Payments as of <date>

This is the MAIN button you should click to start the process of paying your affiliates each month (or however often it is that you pay affiliates). When you click this button, it will show you a report (see screenshot below) of commissions owed on all orders in the system UNTIL X days ago, where X is your “Refund Period”.

So if today is 10/01/2011, and you have a refund period of 60 days, then DAP will only consider orders prior to 60 days as of today. Which means, orders up to 08/01/2011 (of course, depending on how many days in a month, you may not exactly end up with 08/01/2011, because it goes an actual 60 days back from today – and sometimes, the report will stop at the 2nd or 3rd day of the month – like 08/03/2011. But that’s ok, don’t worry about it). You just focus on paying your affiliates on whatever day you wish to make the payment.

So when you click on this button, DAP will bring you a summary report of all affiliates, and how much they’re owed today, for all transactions referred by them as of 08/01/2011 (as per this example).

And when you click on the “Export These Affiliates For Payment” button shown in the screenshot above, DAP will select and mark those affiliates as being exported for payment.

And DAP will show you Paypal Mass-Pay Ready text report, with the affiliate info and the commission amount info already filled in and ready to go. If you’re paying via Paypal Mass-Pay, then all you need is this file. See this post for details.

NOTE: Being exported for payment doesn’t mean that you’ve actually paid them. Exporting affiliates for payment only means that DAP has now “set aside” those affiliates for payment, and you still need to tell DAP that you’ve actually paid your affiliates.

This is important, because you might export affiliates for payment on the first of the month, but it may take you a day or two (or 10) to actually make the payment – especially if you’re sending out Checks.

So once you’ve made the payment either through Paypal mass-pay, or by mailing your affiliates physical checks, then you need to tell DAP that you’ve actually sent out the payments, which is what you’ll do in the step below.

8 ) Mark Affiliates from <export> as Paid

This is where you will select the most recent export from the drop down (see #8 in first image at the very top), and click the “Paid” button. This is what actually lets DAP know that you’ve actually made the payment, and only after you do this, will the affiliates see the payment show up in the “Payments” section on their “Affiliate Info” page.

9) Archived Reports

This is just a report that shows you past commission payment exports.

Manually Crediting Affiliates

Please note that an affiliate will get their commissions credited only if there’s an actual payment (transaction) in the system for that purchase.

So if you have marked someone as “PAID”, for whatever reason, then even if there is an affiliate associated with that user, then the affiliate is not going to get credited any actual commissions because there is no payment in the system.

Here’s how to manually credit affiliates for a sign-up or purchase…

1) Add Transaction If None Exists

If there is no payment associated with the purchase, and you’ve marked the user as “FREE” or “PAID”, then you must first enter an order (transaction) into the system. So search for the user by email id on the Users > Manage page, and on their row for that Product, click on “Add Trans” (which stands for “Add Transaction”).

2) Add Transaction Amount – If None Exists

When you click on the “Add Trans” link, you will see a small popup appear (see image below) that allows you to manually enter an order. So if the purchase was for say $97, then you would enter “97” or “97.00” in the “Order Amount” field and click on “Submit”.

3) Verifying Order Id

Once you’ve entered a manual order, the “Trans Id” column will change from “PAID” to an actual transaction (or order) id – in the example below, it turns to Transaction Id “3”.

4) Give Manual Credit To Affiliate

Now that there’s an order in the system, it’s time to manually give credit to the affiliate. Now on the same User row, scroll all the way to the end, and under the “Aff Id” column, if you already see a number, then it means some other affiliate is already associated with this purchase. You cannot change that affiliate id at this time.

But if you see a “+” (plus sign) there instead of a number, it means that no affiliate is associated with that purchase yet, and you will be able to give credit for that purchase or sign up to any affiliate in the system.

So when you click on the “+” sign, you will see a small popup come up, which allows you to enter the affiliate id (must be a number) of any user in the system. Please note that ever user has a unique number (“User Id”) associated with their account. That’s the number you should enter here.

5) Verifying Manual Credit

Let’s say you gave credit to Affiliate Id 5 for this purchase. So now you should see the “+” sign at the end of the row change to “5”. That means, user #5 has been given affiliate credit for this purchase. So assuming you have already set up affiliate commissions for this product (under Affiliates > Set Commissions ), then at the top of the next hour, when the hourly cron job runs, the affiliate commission will be “credited” the affiliate’s account depending on the commissions set up for the product.

WARNING

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

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

At the very least, you may end up paying double commissions to the affiliate who referred the user, because all affiliate commissions are calculated from sales, and if you have two entries for the same purchase, then the affiliate will get paid twice.

So if you see two credits for the affiliate, you must note that it will not be for the same transaction, but for different transactions.

So be careful when you’re entering Manual transactions. That is only for when there is no way to automate it in DAP, 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.

Recommended Refund Policy

There really is no one-size-fits-all when it comes to refund policies.

There are so many factors involved. The main one being, that Visa/Master/Amex/Paypal all give a buyer up to 60 days to ask for a refund, at least with most merchants.

Unless you’ve already negotiated the refund terms with your merchant account provider, and have both specifically agreed that there would be no refunds (like say, if you were selling an expensive item, like a car, or a boat, or a service), or that it’s only going to be a 30-day refund period, then you really have no control over the refund period. You just have to comply with at least the mandatory 60-day refund period required by the credit card companies.

So that brings us to the question:

How much should you set your refund period to be within DAP?

Now remember, it is this Refund Period setting (under Setup > Config > Advanced) that also makes affiliates eligible for payment.

So it really comes down to the question:

What is the waiting period for an affiliate to get paid for a referral?

Our recommendation: 60 days.

That’s because if you end up paying too soon (say like within 15 or 30 days), and then the buyer comes back and asks for a refund, now you’re out-of-pocket for the affiliate commissions that you have already paid on a purchase that you just refunded.

Now remember that when you do the actual refund within DAP, DAP will roll-back any commissions credited towards this purchase. If you have not yet paid your affiliates, then in the next report, it will ignore the refunded purchase, and will not calculate commissions on that purchase.

But if you have already paid your affiliates (like within 15 or 30 days after purchase), then DAP will include the negative commission in the next pay-period’s report. And any future commissions earned by this affiliate will be accordingly adjusted.

However, if the affiliate doesn’t refer any more members, then you have two choices at this point:

1) Ask the affiliate to pay back the over-paid commissions

2) Just swallow the loss, write it up to the cost of doing business, and move on.

Troubleshooting Paypal Hosted Button Integration

1) I got an e-mail with this subject:
[DAP] http://yoursite.com: dap-paypal: Invalid IPN Coming In

This can happen if you click on this URL in a browser.

http://yoursite.com/dap/dap-paypal.php (replace yoursite.com with the name of your site).

This is a backend script and should not be called directly via browser. But if you click on this accidently, this error can be ignored. Just make sure that the DAP and Paypal are integrated and purchases via Paypal are getting registered in dap correctly.

2) DAP Paypal IPN Error (Rejected): IPN Product Name = does not match any DAP Product Name.
But REJECTING MISMATCH it because of your Config settings (Product Mismatch)

Make sure that the item_name in Paypal button is set to eXactly match a DAP product name otherwise DAP cannot process the payment notifications. If the notification is for a product that you sell outside of DAP, then DAP will reject it with this error message and no action is needed.

If you want DAP to process Paypal notifications even if the product name in DAP does not match the Paypal item_name, then enable this setting in DAP :

DAP Setup -> Config -> Payment Processing -> Should DAP process Customer Emails even when the Product names don`t match ->
Set this to “Y” if you want DAP to process non-dap defined product purchase notification from Paypal.

3) Paypal failing with “Check Product and Price(Reprocessible)” in DAP Orders page

Note: DAP Orders page moved under Payment/Coupons menu in DAP 4.0

This could be due to a problem with the CURL library on your site.
With DAP 4.0, you can easily switch your site to use FOPEN instead of CURL.

DAP Setup -> Config -> Payment Processing -> How DAP connects to Paypal -> Select FOPEN

4) Can I use my Paypal account to sell products outside of DAP even if the global IPN points to a DAP script?

Sure. Paypal has 2 IPN settings:

a) Local button level IPN
This one needs to point to the DAP script (http://yoursite.com/dap/dap-paypal.php) on your site so for all sales via this button,
Paypal can send a notification to DAP.

b) Global IPN – under your Paypal profile -> instant payment notification preferences
This one is used by Paypal ONLY if button level IPN is not set. If the button level IPN is set, then Paypal ignores the global IPN.

We recommend that you set both button level and global IPN to point to the same dap script –
http://yoursite.com/dap/dap-paypal.php
(NOTE: replace yoursite.com with the name of your site)

Now, if you are selling other products outside of DAP using Paypal and for those Paypal buttons, if there is no button level IPN notification defined, then Paypal will look at the global IPN setting (which also points to dap) and send notifications to dap. But dap will reject that message because the product is not defined in DAP.
That is when you receive these ‘IPN rejected’ messages and you can ignore them.

5) I have integrated DAP and Paypal per your documentation but it still does not work.

Three key things to watch out for when you integrate DAP and Paypal are:
a) Make sure that the Paypal button has the item_name set to exactly match a DAP product name otherwise DAP cannot process the payment notifications.

b) Button-level IPN must point to DAP script (http://yoursite.com/dap/dap-paypal.php – replace yoursite.com with the name of your site).

In Paypal button creation page, under Ã¢â‚¬Å“Step 3: Customize advanced features (optional)Ã¢â‚¬Â tab, within the Ã¢â‚¬Å“Advanced VariablesÃ¢â‚¬Â text box,
enter the following (change the text yoursite.com below to your domain name).

notify_url=http://yoursite.com/dap/dap-paypal.php
Note: replace yoursite.com with the name of your site

c) Global IPN must be enabled and pointed to the DAP script as descrbed in step 1 of this document.
http://www.digitalaccesspass.com/doc/setting-up-your-paypal-button-and-paypal-IPN/

6) What config items in DAP are required if I use Paypal HOSTED button?

If you want to use sandbox for testing, then
DAP Setup -> Config -> Payment Processing -> Use Paypal Sanbox For Testing -> Set to “Y”.

If your site has trouble connecting to Paypal via CURL and you see this error in DAP orders page – Check Product and Price(Reprocessible), then update the config to use FOPEN.

DAP Setup -> Config -> Payment Processing -> How DAP connects to Paypal –> Set to “Y”.

NOTE: In the DAP Products page, you ONLY need to set the Product Price, Trial Amount and Recurring Count if you use the DAP hosted/generated buttons for Paypal. Not needed if you use Paypal hosted buttons. You can leave it empty if you use Paypal hosted buttons. Even if you populate it, it will not be used.

If you use the Paypal hosted buttons, then you DO NOT need to set the following in DAP Setup -> Config -> Payment Processing ->

Paypal API Username – Only needed if you use the DAP upsell tree plugins for Paypal Payments Pro or Paypal Standard.
Paypal API Password – Only needed if you use the DAP upsell tree plugins for Paypal Payments Pro or Paypal Standard.
Paypal API Signature – Only needed if you use the DAP upsell tree plugins for Paypal Payments Pro or Paypal Standard.
Paypal API Endpoint – Only needed if you use the DAP upsell tree plugins for Paypal Payments Pro or Paypal Standard.

Paypal Business Email ID – Only needed if you use the DAP generated button for Paypal (DAP Payments/Coupons -> Generate paypal button)

Merchant’s Payment Gateway API Login ID – Only needed if you use e-junkie or the DAP upsell tree plugin for Authorize.net
Merchant’s Payment Gateway Transaction Key – Only needed if you use e-junkie or the DAP upsell tree plugin for Authorize.net
==========================================================

Please check all of the steps at the link below…
http://www.digitalaccesspass.com/doc/setting-up-your-paypal-button-and-paypal-ipn/

Especially check the “notify_url” part towards the end.

If you are absolutely sure that you have followed all of the steps above, and DAP is still not creating an account for the new user, it is possible that your host is not allowing your server and Paypal to communicate correctly. You can confirm if this is an issue, by going to the “Orders” page, searching for all orders, and see if your test purchase in question has been recorded by DAP (even if DAP didn’t give access to the user).

If you find the order in DAP, but the user has not been created, then check with your host and make sure “fopen” or “curl” is enabled for your web site.

If they say it is enabled, and it still doesn’t work, please do the following:

1) Go to Setup > Config > Dap Log Level and set it to “5”.

2) Completely delete test user from DAP

3) Repeat test purchase

3) Go to System > Logs and copy/paste the information there into a support ticket

4) And then please update the ticket with…

* Domain name where DAP is installed
* FTP info
* DAP admin info

And we’ll investigate this asap.

5) Go to Setup > Config > Dap Log Level and set it back to “1”.

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

Make sure you have set up affiliate commissions for the Product on the “Affiliates > Commissions” page
Delete the email id of the test user – with which you are going to make a purchase – from Users > Manage page.
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).
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.
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).
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).
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.
There should be one. Click on that transaction id, it will bring you to the transaction details page
Look at the status of the transaction – it should say SUCCESS at this point.
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).
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

You have already set up a “Per Sale” commission for the Product being purchased.
Visitor clicks on affiliate link and affiliate cookie is set on her computer
Visitor goes on to buy the product
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.
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.
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.
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.
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.

Cancellation or Refund Requests

The Question

How does a customer, once they have signed up and become a member, cancel their membership (or get for a refund)?

Cancellations

If it’s Paypal, they could go into their Paypal account, and cancel their subscription themselves.

If it’s ClickBank, they can log in to their CB account, and cancel their subscription themselves.

If it’s any other payment processor or cart – like 1SiteAutomation.com, Authorize.net, Paypal Payments Pro, etc – then they have to ask you (the membership site owner) to cancel.

Refunds

Except with CB, in all other cases, they have to ask you for a refund

Action Steps For DAP Admin

Whether it’s a cancellation or a refund, log in to your Payment Processor (1shoppingcart, Authorize.net, etc), and make sure you perform the cancellation or refund there. DAP does not store any of the payment information of your subscriber. So both cancellations and refunds have to be performed at your Payment Processor.

Now that you’ve cancelled the actual charging of the customer at the payment processor level, you have to also take care of the customer within DAP – only for refunds.

Cancellation Of Ongoing Subscription in DAP

If this is the cancellation of an ongoing subscription, then no action required within the DAP Dashboard as far as the User is concerned. DAP already does “Pay As You Go” processing – which means, their account will automatically expire at the end of the current recurring period (eg., end of current month). The “Access End Date” of the user’s access to the Product will automatically expire if no new payments come in. And then they’ll automatically lose all access to the content that is part of that Product.

However, if this is the cancellation of a “trial”, where if the user comes back and signs up again for another trial a few weeks or months later, then you want the user to start all the way AT THE BEGINNING. So if it’s the cancellation of a “trial” then you must manually remove the user’s access to the product. So for that, follow the process below.

Refunds (and Cancellation of Trial) in DAP

If it’s a refund of the entire purchase, then…

Search for that user by email on the “Orders” page, which will bring up their Order (a.k.a “Transaction”)
Click on the “Refund” button on that screen. That will create a new negative transaction in the Orders table. Then it also roll-backs any affiliate commissions earned on that sale and make a negative entry in the database for that affiliate. Then it rolls back user access by the number of days entered in one of the “Recurring Cycles” entered on that Product’s page (depending on how far along they were in as a member).
Now search for that user by email on the “Users > Manage” screen. Make sure that they no longer have access to the Product.

If it’s a refund of just one recurring payment from among a series of subscription payments, or the cancellation of a trial, then you can go into the “Users > Manage” screen, search for the user, and do a “Rollback Access for Selected User(s) to the Product by 1 Recurring Cycle“.

For a big-picture view, also see Cancellations & Refunds

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