While writing the code for ec_useracc I hit a massive, unclimbable wall. Sale of a user account requires a valid email address and without address or ecivicrm installed your site is out of luck. This post discusses the problem at hand. If you're short for time you can skip the discussion and get straight to the point.
At present there are two modules that collect email addresses from users during checkout: address and ecivicrm. Both address and ecivicrm also collect a mandatory billing address plus an optional shipping address (depending on tangible products). They work exceptionally well except when you're selling user accounts or software, or perhaps you don't care for the collection of a billing address. Which module can you use to collect an email address during checkout now? That's right! There isn't one.
Maybe I should just patch address or ecivicrm to only collect the email address. Well I could do that sure, but what's the point of having a module, designed for billing/shipping addresses, belittled to be a measley email address collection module. Besides that, on a more pertinent level, the email address collection code needs to be repeated in all modules that need it. So i'd have to write email address collection code in my shiny new ec_useracc module in order to get that functionality. As a result, I can't install both address and ec_useracc when my site sells both memberships and tangible products. Catch 22.
The point of this post
After a long discussion with Gordon we've decided to add a module to EC core: ec_anon. The module will do the following:
- First checkout page will ask for either an email address, a username/password or both depending on policy (see later point).
- Configurable policy for anonymous purchases. This will be both a site-wide and per-product setting. The product setting will override the site-wide setting.
- Registration link will only ever be displayed when the login form is displayed if, and only if, the Drupal core setting on admin/settings/user page allows unmoderated user registrations.
- Anonymous purchasing policy settings are shown below:
- Disabled: Anonymous purchasing is disabled. Initial checkout page shows login form.
- Optional: Initial checkout page asks for an email address or login details.
- Anonymous Only: Anonymous purchasing is mandatory. Initial checkout page asks for an email address only. A logged-in user will not be able to add a product with this policy to their cart.
The changes will be made to 4.7. This means address/ecivicrm need to change and any custom code (checkoutapi?) you have written for any sites may need to change.
Progress report
- Sep 26: Anon code is processing anonymous purchases up to the payment page (need token support for payment processing). Logins and registrations are fully operational. Added Email Address display to checkout review page. Added token field to ec_transaction. Logged in users cannot add an Anonymous Only product to their cart. Anonymous users cannot add a Disabled product to their cart.
Comment away!
gulp Any chance of some funding for this?
--
Sammy Spets
Synerger
http://synerger.com
Comments
Automatically populate Shipping Address fields for Anon
Automatically populate Shipping Address fields for Anon
Drupal 4.7x
It would be very helpful to have some method of filling in the Shipping Address fields for Anon users if:
1) The fields are left bank
or
2) They are the same as Billing Address
Suggestion: Perhaps, something like this below the Billing Address fields
click here if Shipping Address is the same as Billing Address
click here if Shipping Address is different than Billing Address
(with check boxes)
I should be able to find some funding for this, will know more on Monday or Tuesday
thanks
Jeff
Address stuff is for address module
This is not an anonymous purchasing feature and rather an address module feature so it's not going to be included in the ec_anon module. The ec_anon checkout page will be shown before address module's checkout page.
I'm sure we can find someone to add these features to address module for you. Contact me about it.
--
Sammy Spets
Synerger
http://synerger.com
--
Sammy Spets
Synerger
http://synerger.com
token; what is definition of anonymous
how will the token be passed?
I was persuaded to abandon anonymous purchasing on the argument that if the user paid (say at paypal.com) and then the computer crashed before the user returned to the site, it'd be quite difficult to connect the user to the user to the payment again in a secure fashion. If the user's id is passed thru the url, then that raises security issues.
in your implementation, what would happen if the user's computer crashed after payment (at paypal.com)?
what is the definition of anonymous? does it mean you have the person's email address but the person has no account?
thank you
not so much of a problem
This has never been a problem on my clients' sites (they all allow anonymous purchases, no problems to date, unless it's removed, which would be).
Usually purchase amounts end up being a unique total, so every transaction amount is totally unique and therefore identifiable. Never had the above problem though, but it may be problematic if you for example only sell one item at one price, or if you have very high purchase volumes resulting in numerous duplicate purchase amounts.
one product
thank you both for your replies.
I'm only selling one product at one price.
I'm using paypal in part because the Drupal authorize.net module accidentally was storing user's credit cards (this was fixed). My thought is that if I go with Paypal I won't have to worry about problems like that.
No problems so far
I've been using Paypal with anonymous purchases for about six months, no problems so far.
Tokens
I can see where the difficulty lies with hosted payment solutions. They are prone to failure and that's unfortunately the nature of them. Hosted payment solutions are designed for low budget sites and deliver low budget performance. If you plan to handle anonymous purchases I recommend you stay away from hosted gateways.
Should you choose to stick with those, the token we're putting into the ec_transaction table will help. That can be used as the ID you pass to the gateway.
My implementation doesn't deal with specific payment gateways so the answer to this has no place in this thread.
Yes that is the definition of anonymous.
--
Sammy Spets
Synerger
http://synerger.com
--
Sammy Spets
Synerger
http://synerger.com
We have done "registration is mandatory"
By hacking the registration page so that it asks for the email address instead of doing the standard Drupal email exchange, using code samples from this discussion http://drupal.org/node/4942 before it lead to the implementation of logintoboggan.
I have meant to rip out the custom code and replace it with LT, although the latest update on the above issue shows that the basic functionality needed (single step account creation at checkout) will be in core for 4.8/5.0.
For anonymous purchases... I can see cases where I could be interested. Maybe modify the address module so that it collects snail and/or email address, and have it configurable so that you can specify what information you want collected (ideally on a per product basis)?
Improve or separate?
You're right that we could have address module be more configurable (and it definitely needs to be). You have given good reasons why address module should be improved and the email address collected in that. Indeed I agree that the fields address module collects needs be configurable on a per-product basis.
I see this as a chance to place anonymous purchasing code into its own module making EC core cleaner. At the same time it'll improve the anonymous purchasing system. Security will be enhanced by ending its dependence on sessions. Login and registration will be moved into the checkout process to ensure a user has the chance to login or register before they enter/select billing or shipping addresses.
In my head this is the right way to go. Email addresses are more related to the user's account than to the billing and shipping address. This is the underlying drive for moving email address collection over to ec_anon rather than extending address module. During checkout the user either enters an email address (anonymous) or logs in (registers) giving that step of checkout a consolidated purpose.
Logintoboggan (LT) has been used for registration in ec_anon. LT will not be mandatory for the system to work either. Standard registration also works and the user's cart is automatically migrated over to the new user making it able to overcome the times when session data is lost.
The registration policy things that were in the original post have now been changed to be anonymous purchasing policy. Registration itself is controlled by settings elsewhere in Drupal so there is no need for us to specify them on products. Instead we are specifically interested in rules for anonymous purchasing. Here are some use cases for the three new policies.
--
Sammy Spets
Synerger
http://synerger.com
--
Sammy Spets
Synerger
http://synerger.com