Populating customer account on register...

[WriterDanGaidin]

Populating customer account on register...

[perrytew]

Dan,

(I'm assuming that's your name based on your github user...)

I reviewed the code for register. It receives the cart, but only uses the email and password to create a blank profile. I've requested that be changed so that it uses more of the cart object to make the initial record creation more entensive. I'll keep you posted of the status.

Thanks,
Perry

[perrytew]

We've committed a fix to make register work better. I've updated the docs with an optional parameter to specify whether you wisht the cart billing or shipping to be used as the main address for the customer. The default is billing.

http://docs.ultracart.com/display/ucdoc/UltraCart+REST+Checkout+API#UltraCartRESTCheckoutAPI-/rest/cart/register

The fix will be live at end of day.
Thanks,
Perry

[WriterDanGaidin]

This looks great. Is there any way to add the credit card number too? Not sure what all would go into that. Sorry I forgot to mention that in my initial email. Also I've been a bit focused on the my account API the last few days and had forgotten to check this thread sooner for updates.

[perrytew]

Here's how storing credit cards works for the "normal" checkout:

1. In the Customer Profile Settings, there is a checkbox for "Allow Customer Profiles to Store Credit Cards"
   Home -> Customer Profiles -> Settings
2. If checked, the customer is prompted on the final review screen with a checkbox "Store my credit card securely for future reuse".

The javascript checkouts (v1, v2, and v3 [rest]) don't have this step #2 checkbox plumbed into its pipeline. It might help to understand why. Our javascript checkouts grew from the trial offer market that needed simple one or two page checkouts with lots of gui flexiblity. None of them needed customer profiles for their sales.

So, as the javascript checkouts have grown in popularity and huge sites like http://www.flirtyaprons.com/ use them, we've slowly added customer profile functionality to them as requested.

If we added credit card storing to the rest api, we feel like prompting the user to store their card would be the polite thing to do. The only time we don't prompt them is for auto orders (recurring) where the business agreement implies a stored credit card.

To keep things consistent with the regular checkout, we think the best REST based model would be add a flag to the cart checkout or finalizeOrder method that triggers the storing of the credit card upon successful charge. We don't want to add a property to the cart object itself as that makes for a huge amount of cascading changes.

It would then be left to you to design the appropriate prompts to the customer. You could always bypass the prompting and store it without their knowledge. We leave that to you. The same power will be available to the normal checkouts when the StoreFront comes online and the merchant has complete control of the pages. They will easily be able to change the checkbox to a hidden field.

Thoughts? We'd have to plumb this out, mind you. :)

[WriterDanGaidin]

I think that sounds like a great way to do things. Would be simple enough for us to add the customer prompts to our cart and then change the corresponding flag that'll be passed to the checkout method.

[perrytew]

The cart.storeCreditCard field is now in play. I've updated the reference implementation and demo to use the checkbox to show how it's done. Search the code for 'storeCreditCard'.

Thanks,
Perry

[WriterDanGaidin]

Stylin. I'll get on this today. I also noticed that you've update the cart object recently to include customer accounts (with credit cards!) as well. No more having to access two separate rest models. Yeah! Should help to simplify things significantly. Of course, that means I'm going to have to re-do most of what I've finished so far... Oh well. Better for us in the long run.

Thanks, Perry.