I am currently developing a little ecommerce application to help me get to grips with CodeIgniter and programming in general.
I have a 4 step checkout process.
Customer name, email, shipping country
Shipping option, shipping address
Billing option, billing address
Review and submit
Currently I am storing all this data in the session (cookie for now, db when live) as a JSON encoded array.
I was wondering, am I better off storing the information in the order table linked to cart items so that I can track abandoned carts (contents, step when user exited) or just retaining it in the session and transferring it all when they confirm on the review page.
I am trying to get to grips with some of the options available to me.
It depends on how you plan to use the data. If you're going to create functionality to mine data on your users' shopping habits, including abandoned carts, then definitely retain that data in a database. If you don't think that is likely to happen then storing it doesn't do you any good and is unnecessary information. But only discard that information if you're sure you're never going to need it. It sounds like you may want to explore abandoned cart reporting at some point in the future so storing the data now, although it won't be mined right away, is probably a good idea.
Related
so I need to ask a question, I need to setup a simple paypal express checkout system, that one can allow users to change currencies, and two can then update the page with the updated currencies.
Then I need a way for me to get the order information. As I will be selling website templates so I need a way for me to get their email address, so I can then email them with the link to the template file download.
So my question is what data do I get if I set up an express checkout system. And what code do I need, Do i need to create a database to get the returned data back from paypal? Or do I just get an email or can i see that when i log into my paypal account and check orders and see their details that way, but the main important detail i need is their email address?
Can I also say that this is the first time I have looked into express shopping carts. So I am a complete novice in this field, So I will struggle with the coding aspect. But I think it is the route I need to go down.
Also I want to make it all in php as well. But also I don't want to use ready made systems. I just need the back-end code so that I can then just implement it into my current design. Not sure if paypal give you the code when you click the express shopping cart option in All tool section. I did notice though it redirects to a page that lists many partner sites. I couldn't find anywhere for any implementation advice or tips or code.
EDIT: Also I know I will also need to use either IPN or PDT but the documentation I read is highly confusing and just is making me unsure if I can even set a system up. I also read that you should implement both systems, but I also read that that had a risk of doing the payment twice. So yeah i am kinda a bit unsure how to even go about implementing a system I need.
Thanks in advance.
Imagine a site like istockphoto or envato where the user can only purchase digital credits...
How would one implement this in the cleanest, easiest way using paypal's API's? The docs there are a bit confusing to navigate...
Aside from that general "best-practices" question, my guess was to start with the Integration Wizard at https://devtools-paypal.com/integrationwizard/ and select "Express Checkout - Digital goods"
After setting up some test accounts on the sandbox, I've kinda sorta got it working- but I'm confused how I track dynamic data across the session.
I.e. where would I securely store the "number of credits" and "userid" values so that it gets added to this user (who may not have an email address, nevermind one matching their paypal account) upon successful payment. Is a database/callback system necessary?
Assuming so for the time being, my guess is to maybe store the data in a database where the primary key is the TOKEN received at SetExpressCheckoutDG(), and prepopulated fields are the data I want to keep... and then the final confirm.php page will check the database at that token and implement that data... but something just seems strange about that, i.e. relying on a callback (could be timeouts, etc.) and I'm not sure if it's really the most secure way of doing it.
If using examples, please stick with PHP (not curl or other langs). Thanks!
You could just bounce this along with your calls. I'll use NVP for my examples
You set your digital goods in SetExpressCheckout. Inside, you pass how many credits the user is buying and set the PAYMENTREQUEST_0_CUSTOM with their user ID.
In GetExpressCheckoutDetails that data would be passed back to you so you could store it in some fashion (you would get their items and quantity, plus the user ID). Then, you finish with DoExpressCheckoutPayment.
If that still doesn't help let me know.
Is there any possibility to move customer and order data between 2 magento sites?
I have a database which keeps giving wierd issues with the database so I intend to rebuild the site, adding in some extra features at the same time. I cannot loose the order and customer history though (including passwords etc) so Is there a way to do this?
I've got the same problem. I posted a question about this in the magento forum.
If i don't get an satisfying answer, i will write an application that reads and associates the customers and orders and writes both into the new store.
You can do that using the Magento SOAP API.
I have this small PHP/MySQL cart system that users add products to, checkout, and pay.
These products all have IDs on them so that when the user checks out,
I can get that product's attributes (price, weight, the vendor's account id, etc).
Right now it would be really easy for someone to open up Firebug,
guess another product ID, change it, and checkout.
What would be the best way to prevent this?
The store and the checkout system are on two different domains if that matters.
I could use something like a unique token
but how would that work if multiple customers could be using the cart at the same time?
EDIT: Wow, typed this too fast, left out some important details. The cart is currently represented as JSON that is being stored in a PHP session. All products have an account_id that associates them with a vendor's account.
The problem would occur if a user changed the product id and happened to get a product under another vendor's account (essentially purchasing another company's product from a different company's store) which would be undesirable. Thank you for the answers so far.
Use a server side session to store the cart details.
Every session gets a unique ID, stored in a cookie. All details (selected items, amount, etc) are tied to this sessionId.
By definition, you do not want different customers to use the same cart. Instead, every custommer uses their own separate copy of the cart.
If you need to 'share' the sessionId with some external service, instead calculate a separate unique key and share this key with the third party service (=checkout service in your case).
This ensures that you can uniquely identify your customer in communications with the thirds party, without the third party knowing anything about how you identify or communicate with your customer on your side of the fence. (the important thing to remember is, a sessionId is a shared secret, nobody else should ever know about it).
If you have access to the cart system, the proper way would be to have it duplicate the ID lookup and cost calculations before running the payment. That way, if someone DOES change from a $1.99 box of candy to a $1999.99 HDTV, they will get charged for the tv.
If you don't have access to your cart system, or you can't tell it what the products are and their cost. Get a new cart system.
As a side note: You should NEVER trust data that has come from the user. There should be no need to have to build in trusting the user. Just accept the IDs and run all the numbers on the server.
One way to do this is to use a hash. When they select a product and the form is rendered, take a hash of the Product Id and store it in a hidden field alongside the Product Id. When the 'checkout' post occurs, take a hash of the Product Id that is posted and compare it to the one that was sent out in the form. If they don't match, then the Product Id has been tampered with. I'm not familiar with PHP so can't provide a code sample but I've used this approach in ASP.NET and it works a charm.
Hope that makes some sense!
And what the threat is? If the client-side has only product IDs, then if they change the ID, they'd be buying different product, and that's all. Or your products are not available for all? If they aren't, you need to use random IDs so that they couldn't be easily guessed.
I think what you have to do is encrypt/decrypt your product id and use it.
you can use base64_encode() and base64_decode()
Hope this will help
i'm going to explain the flow of what i need:
the checkout process is the same, now, in the last step, i'm doing POST to an external URL, where all the data is processed, i wait to the response of the external server, after process it, i make the correspondient step, 1- Save the order in the db or 2- Give an error message. it depend on the response, then, to save the order i need to have all the card details, if i don't have it, magento give me an error, the external server doesn't return the card details for security reason, and they said the won't, so, i need to keep alive all this information until i can save it or refuse it, my question: What can i do here? Save the card details in a cookie? or a session variable?? or do i have another opcion??
thanks
If you save card details anywhere, including the session, you will probably have run afoul of data security laws in whatever country the business is running in. I would not suggest that as a solution.
As this is a really important topic (imo) and the answers are a bit complicated i decided to write a rather lenghy response about this.
So what are the main aspects with custom payment methods and especially with magento?
You are most likely not allowed to store and or transmit credit card information.
However you can store something similar so the customer doesn't have to re-enter his/her information all the time. I will come to that later.
Magento is a very flexible and powerful application (however it is damn slow). You can do almost anything. But when it comes to checkout processing the flow has to obey certain limitations, with good reasons.
Checkout processing steps should be capsulated into units. You are trying to wrap apart one unit which is almost certainly a very bad idea.
So what I want't to say is that the Credit Card information should be entered at the SAME provider that processes the payment. Nothing else. Ever.
I mean thats just absurd... Think about it. "Please provide your paypal credentials, we will then do the payment for you..."
On the other hand if you are a certified credit card payment provider you this transaction of yours (which sounds absolutely insecure) is handled internally and you as a provider are like a black box. Even for your shop.
If you really want that you can internally do your verification transaction etc. To get you on the right track with that i have this code for you which should bring you on the right track.
I essentially copied it from magento forum and tweaked it a bit to work with the usual issues like several shops, super products, custom prices, special prices and so on.
However i think you should really re consider your approach for whatever you are trying to accomplish.
Last but not least as i mentioned above, there are way to "store" the card information at the provider. For example Ogone offers you the possibility to send a customer token along with the customer, and if the same token appears again they just pre-fill out all the information and the customer just has to click "pay".
They also offer you to customzie the payment pages and have your own vohst so that the user essentially doesn't realise he/she is even leaving your shop.
They also have steady modules for magento that work like a charm and are pretty customizeable.
Maby thats what you want...
If I didn't answer your question, at least in an indirect way, I would kindly ask you to re write your question and put more clearly what you exactly wan't and expecially what your intentions are. Meaning what you are trying to accomplish in the end. Perhaps there are better approaches!
Greetings, joe