CiviCRM Community Forums (archive)

I think you have to have another browser tab open and be logged in to paypal sandbox while you test: https://developer.paypal.com/

so you would be logged in there, and then in your other browser tab you would be on your drupal site doing the test drive (and i *think* you should not have to be logged in as admin but don't quote me on it, just try it out)

I never got paypal sandbox to work properly and decided my time was worth more than that so I did a handful of 50 cent transactions on the live site instead.

(BTW - we have been struggling along with paypal for about 6 months but have found it to be really awful so if you have another option I'd go with that)

Which leads me to the question - how is it that paypal is so successful when it's such a dog to use.

I've been working through the same problem and it looks like it works, but then doesn't.

Meaning that I get through all the steps for registration, login to the buyer test account, "pay", go back and get the "Thank You" page.
So far, so good. The registration then shows up in the participant list, but as pending/incomplete. There is nothing whatsoever being logged in sites/default/files/civicrm/upload/CiviCRM.log
(Well there's some older stuff in it, which tells me that it is the right file.)

I would find this a bit unsettling if it happened with a live setup - customer pays, gets receipt, confirmation and all, and I don't see any evidence of the payment having gone through, so I'm wondering if that also happens...

Anyway, any tips where to look for clues would be much appreciated.

TIA,

Ronald

Lobo, many thanks for your quick and, as usual, spot-on reply - much appreciated!

Thanks to your instructions I got a step further.

The first problem was that CRM-3444 raised its ugly head - I had installed 2.1.4 but forgot to patch civicrm.config.php and thus the valid configuration dir was not found. Applying my patch fixed that one, but the process still doesn't work.

If I use the whole (decoded) URL from "notify_url=" onwards, I get "access denied" and this in the error log:
mod_security: Access denied with code 403. Pattern match "\\\\.php\\\\?.*=(https?|ftp)\\\\:/.*(cmd|command)="

If I only use the part up to the next ":", which seems somewhat logical, I get Failure: Missing Parameter.
I've tried various other cut-off points for the URL but always seem to get one of the above.

Looking closer at the pattern above, I removed the &cmd=_xclick&amount=2 from the end of the URL and got no "access denied" anymore, but the missing parameter message persists.

[Edit: and this in /sites/default/files/civicrm/upload/CiviCRM.log
Jan 01 19:35:24  [info] Could not find an entry for payment_status in POST]

[Edit2: I also tried the (decoded) piece of the URL between "notify_url=" and the next unencoded "&", assuming that the latter indicates the next parameter for PayPal rather than my site, but still the same result.]

[Edit3: FWIW, the URL referred to in edit2 is /civicrm/extern/ipn.php?reset=1&contactID=12&contributionID=15&module=event&eventID=1&participantID=11&item_name=Online+Event+Registration%3A+Test+Event - no difference if I swap %3A for :]

Any ideas what I'm missing here?

[Edit4: I think I understand why there might be (a) missing parameter/s (and no payment status) when accessing the link directly rather than PayPal calling it with whatever parameters it does that. However when I just try to acess /civicrm/extern/ipn.php without parameters, I get "Access Denied" - is that expected behaviour?]


Thanks again,

Ronald

That is the error. You should not get access denied for that url:

check: http://drupal.demo.civicrm.org/sites/drupal.demo.civicrm.org/modules/civicrm/extern/ipn.php

which is the notify url for the demo server

For that one I get
Could not get module name from request url

[Edit: same result when I try /sites/all/modules/civicrm/extern/ipn.php on my own site.
And http://drupal.demo.civicrm.org/civicrm/extern/ipn.php gives me "Access Denied".]

Is that expected behaviour, then?

Cheers,

Ronald

Basically we add extern/ipn.php to the resourceURL (http://drupal.demo.civicrm.org/civicrm/admin/setting/url?reset=1)

That url needs to exist and without parameters should give you: Could not get module name from request url

You notify url should be resource url + 'extern/ipn.php'

i'd ensure the above works. Might be a result of your symlink patch?

Thanks for the pointer.
Looking at the code in /civicrm/current/CRM/Core/Payment from line 275 I don't see how the patch could have an impact on the notify url:

        $notifyURL =
            $config->userFrameworkResourceURL .
            "extern/ipn.php?reset=1&contactID={$params['contactID']}" .
            "&contributionID={$params['contributionID']}" .
            "&module={$component}";


Hm. But it's not using the value I set at http://mysite.com.au/civicrm/admin/setting/url?reset=1
Sorry if this is a stupid question, but does the first bit of the code go straight to the value set at that page, or is there any internal processing happening in between?

Another thing I don't understand is why/how the internal paths are being used externally:
in Drupal, civicrm would reside in /path/to/website/sites/(<site>|all)/modules/.
As I understand it, this path is used internally by Drupal to associate the modules in there with the actual website that's being accessed, so if there are different sites, it would use the appropriate subdirectories. My idea of this is that that is purely internal and should be transparent to a visitor of the site.
Accordingly, CiviCRM can be accessed through http://mysite.com.au/civicrm, administered through http://mysite.com.au/civicrm/admin, etc, even though these are all virtual addresses which do not directly resolve to anything in the underlying file system. When I mouse over the CiviCRM menus and settings, the urls all work that way, i.e. all point to http://mysite.com.au/civicrm/something.
So what I don't understand is why in this case (with extern/ipn.php) that internal structure now needs to be explicitly navigated. In keeping with the mapping that's used by everything else I mentioned, wouldn't it make sense to map that in the same way to http://mysite.com.au/civicrm/extern/ipn.php, rather than to a path that depends on the internal structure of the setup?

That is where I think the symlink patch might in fact contribute to the problem if and when the path is being processed somewhere between setting and retrieving it because it retrieves the current logical path from where httpd believes it is, so if that is using the mapped path at the time when userFrameworkResourceURL url is being worked on, that would be used for it.

Problem is that without my symlink patch, I don't even get that far because it looks for the configuration file in the wrong place. So I guess with the qualification above, there might indeed be the hitch.

Now the question is if there is any such processing happening. If yes, then the next questions would be where and whether it would be better to modify the patch to handle this case differently, or to bring that single URL in line with how the rest of them work.

Cheers,

Ronald