Using PayPal with Anonymous checkout gives merged not new account [#423546]

When you use anonymous checkout (for an e-mail address that has not placed an order before) and use PayPal as the payment method, the customer is told that their order has been merged with an existing account rather than being told that an account has been created for them. This also means that the auto login doesn't work for a new customer.

I know why. It may be that this is unavoidable and has to go to "Won't fix" status, but something is needed. The reason, I presume, is that an actual order has to be created before PayPal is engaged, so that the PayPal IPN just updates the existing order. By the time the customer returns from PayPal, that e-mail address does already exist in the user table.

Two problems with this: 1. The customer would be confused ("What, I already have an account here? - news to me!"). 2. The customer is sent the wrong e-mail - they get the one that applies when they create their own account, which isn't the case. I omit the password from the e-mail when they create their own account (because I use login toboggan), but send the customer their password when an admin creates an account for them. I need the latter e-mail in this case.

Comment	File	Size	Author
#1	423546.user_defer.2.x.patch	4.58 KB	cha0s

Comments

Comment #1

cha0s commented 1 May 2009 at 06:20

Status:

Active

» Needs review

Status	File	Size
new	423546.user_defer.2.x.patch	4.58 KB

Well, I figured it out :)

I introduced a new concept of 'deferred user creation', for instance when an IPN calls back the user will be created but then if a user shows up later, the system'll think the user's already there (problem 1 above). So, I added a small bit of code in Paypal to set the 'user_create_defer' variable in the order data.

Based on that, cart_complete_sale() will create the user now, but upon the user coming back, it'll see the 'user_create_defer' in the order data, and treat it like it was just created. Also instead of using $_SESSION to store the generated name/pass, I store that in $order->data['new_user']... makes more sense to me. That also allows that data to persist further than a session (i.e. user and Paypal's sessions won't be the same.)

The new code cleans the user/pass and the 'user_create_defer' out of the order data ASAP.

Try it and see what you think. For the sake of resolving the issue, I included the change for problem 2 above. The 'register_admin_created' email is sent in this patch.

Comment #2

jamesoakley

English

North Yorkshire, UK

commented 8 June 2009 at 14:57

I can't get the patch to apply.

(On a Windows system) running <installFolder>\patch.exe -p0 -i 423546.user_defer.2.x.patch --verbose

To get this output

Deleted to shorten post. Patch problem fixed

So: Two hunks successfully applied, and then it gets stuck at the next one. I've tried this against both RC2 and the nightly -DEV snapshot.

Comment #3

jamesoakley

English

North Yorkshire, UK

commented 8 June 2009 at 14:59

Version:	6.x-2.0-beta5	» 6.x-2.0-rc3
Status:	Needs review	» Reviewed & tested by the community

That worked fine, thanks. I now get the "admin created an account for you" e-mail, and I get the "we've just created a new account" screen after the order.

Good stuff: Ready to commit to CVS as far as I can see (although I don't have an account!)

Comment #4

BrandTim commented 21 November 2009 at 22:34

Additionally confirmed works with 6.x-2.2.

Thanks cha0s!

Tim Knittel

Comment #5

that0n3guy commented 11 October 2010 at 19:02

Awsome stuff, I made a couple little changes (here: http://drupal.org/node/658470#comment-3559490 ) so that anon user is logged (if set to auto-login).

Comment #6

that0n3guy commented 30 November 2010 at 18:33

Just thought I'd let ya know, I made some more mods that uses this code and fixes duplicate emails:
http://drupal.org/node/644538#comment-3771270

Comment #7

that0n3guy commented 14 January 2011 at 18:45

Hey, isn't there a security issue here? The username and pass are stored in plaintext in the db. If the user never comes back to the checkout page... the data stays in the db. Anyway to time delay this?

Comment #8

Island Usurper commented 28 January 2011 at 14:53

Status:

Reviewed & tested by the community

» Needs work

I wonder if the user name or at least the password shouldn't be encrypted the way credit card numbers are. Even if not, I agree that this data shouldn't stick around forever if some kind of error occurs in the PayPal workflow.