I need to develop multiple e-commerce websites. Let's call them foobar1.com, foobar2.com and so on. The catch is, when you hit the final checkout button, the checkout process needs to happen at checkout.foobar.com for all domains.
Is this possible, and if so, how could it be done? Session data (that holds cart info) won't be available at the checkout.foobar.com, and neither will cookies.
One way I could get it to work is if I maintain the cart at foobar.com, which means everytime you add an item at foobar-n.com, I will make an API call to foobar.com which will update the cart.
Is there a better way to go about this?
For the sake of not leaving this unanswered:
I implemented the database solution, i.e. when you hit checkout, your cart contents are dumped into a database with a unique id, and you're then sent to checkout on foobar.com?id={uniqid} and cart contents are retrieved. When you successfully complete checkout, the items are removed from the DB. I also ran a nightly cron job that removed items from the DB that were more than 6 hours old (for those who didn't go through the checkout process).
Related
I am having a problem on an e-comm site i am trying to build where it's possible for a user to add additional cart items when checking out with the SecurePay payment gateway.
When the user clicks 'pay now' button, they are redirected off site to the SecurePay payment page where they enter their credit card information. It's here where its possible for the user to open another page and add/remove cart items after the payment information has already been sent to the payment gateway without me being able to detect it. The shopping cart is a database shopping cart with a cookie as a unique identifier to remember the user.
The problem is that there is no input fields to for any product data in the SecurePay form that's sent to the payment gateway, you can only specify limited information about the order, ie, the total $ amount of the order including shipping(can't even send shipping total separately), a reference number(invoice number) and the currency type(AUD), surcharge percentage etc. So i have to process everything based on the the users shopping cart after the order is successful and they are redirect back to my site. If the user add/removes cart items while they are paying offsite, it is then reflected when i generate the invoice and do the stock take on the order completion page.
Im just not sure how to combat this.
My possible scenario:
I lock the cart when the user hits the checkout page, then unlock it if they hit any other page than the checkout page. Though then there is no possibility of any up selling without taking the user completely out of the checkout process and i'm also worried about any possible scenarios where if the user returns to the site their cart may still be locked. Plus maybe it seems a little messy/hackish of a solution?
I did test a couple random e-comm sites, and it was also possible to add additional cart items from another page during the 'pay now' stage of the checkout process without it detecting the additional cart items unless you actually manually refresh the page. Though i did not verify by actually paying for the items, but i can't see how it would be any different to my problem.
Does anyone have any suggestions?
I initially thought this kind of behaviour was a bug until I learned about upselling. So my solution to this (if I ever needed one), is to make sure every checkout process is a new order, and not a update. And add a hook, to let the user know about the new order, and give an option to discard (clear out) items currently in the cart.
If you can send a reference number, why not use that to generate the order? Whenever the user goes to pay, create an order with the items in their basket and send that number to SecurePay. When the payment is complete mark that order as paid for. If they change the contents of the basket then the old reference number will still refer to the products originally in the basket and if they go to check out again a new order will be created with the correct items in it.
There could be an option - that when the user is redirected back to your site - that secure pay could pass back some information including the amount charged. Then you could check and confirm that figure against whatever is in the cart.
Or - I'm looking at the secure pay developers page and they have two different methods where the customer would never leave your website.
https://www.securepay.com.au/developers/products-and-services/accepting-e-commerce-payments/
Are you in Australia - if yes you could also look at Stripe, it might be easier https://stripe.com/au/pricing
I am building an e-comm site with a database shopping cart approach using a cookie as a unique identifier. I am wondering if i should be creating a temporary checkout table to store the users shopping cart data for when the user decides to checkout? I want to try and separate the actual shopping cart from the checkout process in case the user may open a second page and try to add additional cart items while in the later stages of the checkout process.
I have a loop in place that constantly updates the checkout order summary if a user tries to add additional cart items from separate page, but when the user makes a payment they are redirected off site to a securepay payments page where they enter their payment information, so it's possible to add additional cart items during this stage.
Should i be creating a temporary checkout table that stores the current shopping cart at the beggining of the users checkout process?
I was thinking about just locking the cart when the user goes into the checkout process using sessions, so that if the the user abandons their cart, the cart will become unlocked when the session is destroyed. But i don't know, it seems less reliable?
Can anyone give advice on how i can approach this?
Here are the suggestions :
Don't use cookies and session for storing cart items, use a separate
table for this. This way regardless of sessions, the cart will be
same.
Try to rely less on cookies and session, and use database instead.
Many carts use database sessions instead of using php sessions.
One of my client runs a successful store using WooCommerce, and now he wishes to create another WooCommerce site with the exact same products. But since opening a new actual business is a big deal for him, he wish that after the users has placed items in their cart and clicked on "checkout", the user will be redirected to the first ("original") site and choose the shipping option and payment method and complete the checkout process there.
We have thought about it through, from different aspects, and finally the user insist this is the solution he wants to try.
Can it be done? If yes, does anyone know of a simple way to accomplish it? or what should I consider before trying to implement this solution.
So I have a multi paged checkout system that relies on sessions to store the contents of the shopping cart. I'm also using a third party system to process credit cards, which hosts the actual payment page on their servers. I just have to POST to the page the final total.
The problem I foresee is what if someone clicks to go to the hosted pay page, and then for some legitimate or nefarious reason changes the shopping cart contents in another tab. I had initially planned that when the hosted pay page redirects back to my receipt page I would then INSERT the order into my database. But, if the session is changed at that point, the order will be different from the total cost charged.
What would be a solution to this problem. I can see this sort of thing being an issue for all cart systems, so I'm wondering how they do it.
Maybe when the user clicks the button to go to the hosted paypage I can make a temporary order entry in a temp_order table in the database, and then when the payment goes through I can transfer that temp record into the permanent record table? That way I don't insert the record from the session information that has changed. But if I have to POST to the hosted pay page, where do I have the opportunity to save the shopping cart to the temp table?
Also, the temp order id must be unique across both temp and permanent tables since I don't want any overlap.
Lastly, I should want to clear the temp order table frequently as they are just temp records. Some might not go through as the user could change their mind on the hosted pay page.
I'm really confused as to what I should do!
I see no need to create a separate table. Just add one column into existing table, say, payment_in_progress and analyse it when client submits any changes to the cart.
The requirement to clear out unprocessed outdated orders remains
When the payment gateway returns just store the amount received against the shopping cart and if the amount received is less then the total, put them back onto the payment page, showing the outstanding balance left to pay.
Unless the payment system returns control to your website before final processing of the order, e.g. like PayPal Express Checkout, there is no way to stay in control of the checkout process. One-way checkout systems are really meant to be one-way. Follow-up management is manual (by a payment receipt) or handled by server to server notifications.
Posting directly to the payment site is not going to give you any control once you submit away to the other website. Probably the best case scenario is you submit the order to your website as an UNPAID order into your database, then provide a page that says "You're almost finished. Continue to payment." -- At this point, you should have also emptied the customer's cart so they cannot change anything about the order in process (which is already in your DB). When the payment system redirects back to your website, you will simply look for the unpaid order and mark it paid. It would also be a good idea to verify the payment amount, just in case the user modified the POST data in an effort to pay less.
EDIT:
You might really be in need of a payment gateway solution that gives you more control over the checkout process. Your concerns are real, but they are not typically addressed adequately using payment flows that send the user directly away from your website without first setting up the transaction server-side.
I'm currently implementing Paypal Express Checkout within a Zend Framework Application, I wrote my own cart model which consist of two simple class Cart & CartItem, and they are able to se quantity, get total price, etc.
I'm not much aware on payment system, and I only use Paypal (it's my first time), but I though since I'm not able to control what's happing there (at Paypal) it is a good idea to "lock" the Cart at the beginning of the process (when redirecting to Paypal) to avoid inconsistencies over the current Order processed by paypal and the actual cart on the website.
It can happen for example if the user open a new tab and try to add products while he is a payment process with paypal.
If your cart is locked the use is not able to add or remove anything from its cart until he finished to process the payment thorough paypal or cancel its order.
My question is do you think it is a good approach?
Edit: The reason I don't store anything in the database but only the shopping cart in session is all order are stored with Paypal, so I don't want to store it twice, it is a really really simple system.
I've done it a different way.
When the user browses the site, the cart is stored using a session, a cookie or whatever.
Once he clicks the "pay" button, the content of the cart goes to a orders datable table with a unique ID.
You delete the session or the cookie to prevent him to add new stuff to the order.
You use the unique ID to give it to paypal. Once the payment is done, Paypal comes back to you with IPN, and gives you back the unique ID. From that you know it's paid and can put a boolean or something in your orders table.
Sometimes the user won't pay, and you'll have some never paid orders. You should have a cron that check orders older than one day and remove them from the table.
I think your approach is fine. But make sure you inform the users why they can't add items to cart and offer an easy option to unlock the cart.
Use case:
fill cart
start payment
ah, I forgot the socks
close payment tab
shop opened in other tab
add socks
"you can't add, it's locked"
I can't return to payment to cancel it and can't add anything to cart => i leave