I'm using subscriptions with ecommerce module. My intention is to assign a special role called "subscriber" to a user, whenever he subscribes.

However, I noticed that an user get associated with the role "subscriber" even *before* he pays with PayPal! It suffices merely to open the first PayPal screen, and the role gets assigned, and I get an "pending" transaction in my transaction log. Is this a feature or a bug?

IMHO I think an user should become associated with the role only after he completes the payment process.

Comments

gordon’s picture

gordon commented

Basically what happens is that the transaction is created as soon as you proceed to the paypal page. You need to check that the transaction has been completed before you allow the user to access the secure content.

You may want to look at doing this via a cron or something like that.

freyquency’s picture

freyquency commented

huh? I can understand the 'cron approach' -- which i think many will dislike as it's not instant -- but to have the module automatically do something that leads to misleading data (50 people could go to the paypal screen and not pay but it looks like there were 50 sales) and insecure products seems to be worse than if you did it manually. I'm appreciative of the module and the subscription functionality in particular, and I think this should be fixed somehow.

moshe weitzman’s picture

moshe weitzman commented

it sounds like the subscription should use the 'on payment completion' operation when it is using the trascation operation now. this is an easy change.

gordon’s picture

gordon commented

As soon as you click on the "continue to payment details" the transaction is created with a payment status of pending, and the transaction status will be "transaction received" You cannot enable the subscription until the transaction status is completed.

You should use the "on payment completion" in the product api to update the subscription. I this will then happen as soon as the server knows that the payment has been made.

skolaric’s picture

skolaric commented

I appreciate the feedback, but I'm not sure about the cron approach... Perhaps I don't understand something. Cron time window in my case is 24 hours, and in 24 hours a lot of valuable content could be taken off my site... Even if I decrease cron interval to one hour, it's enough time to download gigabytes of valuable matter. Decreasing it futher would be absurd, imho - cron is meant for periodic website-maintenance operations, not for regular day-to-day operations.

I understand PayPal works in real time through payment notification (it sends confirmation of transaction validity, something like "SUCCESS"), and I would prefer an approach where the role gets assigned when this happens, not when the associated meta-transaction starts in Drupal.

Disclaimer: I'm not sure whether all this what I'm saying makes any sense, though, since I'm fairly new to Drupal.

gordon’s picture

gordon commented

It will be best to use the "on payment completion" hook in the productapi, as soon as the system know that the payment has been completed the system will be updated.

skolaric’s picture

skolaric commented

Thanks for the tip.

judah’s picture

judah commented
Title: Role assigned before PayPal checkou » Role assigned before PayPal checkout

The role should be assigned when Paypal pings the IPN page giving the payment status a "payment completion" notification. But there is an active bug open that does not move the payment status to "completed". I don't see where the payment complete hook is triggered but the paypal_ipn function has a on case 'COMPLETED' block that you can move this code into once this bug is fixed.

See this related issue http://drupal.org/node/16744.

spazfox’s picture

spazfox
Location Olympia, WA
commented

Has anyone provided a patch or anything to correct this problem? I'm using the latest 4.6 version of ecommerce, and would like to have this corrected before I launch my site. Thanks...

sime’s picture

sime
any/any
Location Melbourne
commented
Component: paypal.module » -- other --
Status: Active » Closed (won't fix)

We are not supporting 4.6 now. Please re-open if any problems.