Design for a shared checkout

Question

I am currently working on a ecommerce system that is slightly different in structure to a typical ecommerce system in that you have multiple stores, accessing the same database from different URLs.

So for example i might have:

• http://www.site1.com
• http://www.site2.com

the above are essentially the same store, they point to the same database, in the main will share the same products (this may seem weird but these are the requirements of the client). The only difference is, based on the URL the users, baskets, orders etc are split so that they do not cross each other. I.e. the orders/baskets/users of site1 are not visible to site2 so a pretty standard single database multitenant model.

The above is implemented, i am just slightly stuck on how to implement the checkout process. The requirement is to have a shared checkout, so instead of:

• https://www.site1.com/checkout

you would have (for clarity this will link to the same database as the above sites)

• https://checkout.somesite.com/storeid/basketid

You could tie this in to the way it is handled at Shopify, multiple stores one checkout process.

The checkout process in the main is not difficult, i can use the storeId and basketId to identify what i need to identify in terms of create an order from a basket and assigning to a store if the user is a guest. The issue i am facing is what to do when an existing user wants to checkout and login so that the order is associated to their account and some basic information (Email Address, Billing Address) is pre-populated for them.

The checkout process (https://checkout.somesite.com/storeid/basketid) does not concern itself with logins or account management of any sort, its just there to facilitate checkout so users, if they are at the beginning of the checkout process and wish to login will be redirected back to the corresponding sites login page. From there i am thinking about this process, but just wanted to share it to see if there is something glaringly wrong with it:

1. User Logs in with correct credentials
2. Some object (may be the Cart or an intermediary CartOrder object) is updated to contain the id of the user, a unique session key (possibly a GUID) and a timestamp to state the expiry of the checkout session
3. User is redirected back to the checkout site with the session id appended in the querystring (i can't use cookies as the sites are on different domains)
4. Option: At this point i may create a local session to hold onto the value for the remainder of the checkout process making sure it is still valid along the way (a new login would also expire the session key)
5. Checkout!

Now there is a slight concern in that placing the session id in the query string it could be picked up by some malicious person, used and some information (name, address) could be visible. On the flip side to that, the checkout will be all SSL, the sessions are short lived and not really able to spoof accounts (or do anything on behalf of the account it represents) so i am not sure if it is being over thought in this process?

Answer 1

I have dealt with a somewhat similar scenario in the past, though it was across subdomains. (I don't know what programming language you are using, so I'll just describe what I did using PHP) The approach that I used was to configure PHP on all servers to store sessions on 1 dedicated memcached server. This allowed session data to be centralized and accessible from any server really, but you'll want to write some firewall rules to restrict access to only your servers. Memcached doesn't have any security like that built in, you have to restrict it to only 1 IP address, or '0.0.0.0' which is any. The second step was to configure the "cookie_domain" setting on each server to the parent domain. Here are the config options from my php.ini:

session.save_handler = memcached
session.save_path = "[server ip address]:33023?persistent=1&weight=1&timeout=1&retry_interval=15"
session.cookie_domain = .somesite.com

You will replace [server ip address] with your memcached server ip address.

Many folks don't know, PHP keeps track of the session id via a cookie though you can pass it through the query string too. But if you are able to set up the site(s) the way I explained above, you won't have to do that since your sites will have access to the session cookie under the same cookie domain. Browsers have security built in that prevent you from accessing cookies from another site.

HTH

Answer 2

Apologies if I misunderstood the question and requirements.

Assumptions

Three unique web sites
shop1.com
shop2.com
checkout.com

Shopping at site 1 or site 2. When you checkout you redirect to site 3.

I would take a look at browser sessions. They usually have a unique ID across tabs in the browser.

My implementation would be something along the lines of.

• User shops at shop1.com
• User does a checkout. Login required.
• Capture browser session ID. Open a socket from the shop1.com server to the checkout.com server and pass it the unique browser ID along with any other info that you require.
• Perform redirect to checkout.com
• Get unique browser ID and check if the checkout.com server knows about it.

This way you don't need to use special URL's and parameters and you can pass information between the sites.