What web software systems of frameworks are necessary to develop a web application that has catalog of products and allows them to be buyed, using shopping cart and payment methods like, paypal, debit cards, credit cards etc...
The technology I am asking is php.
For example If I am developing system like this, can I finish the job using only Drupal or Joomla? What other subsystems should be added? Can someone give me examples? Or maybe using some CRM system?
I prefer opensource soulutions.
You should consider osCommerce. It includes everything you are looking for, and it's open source.
For instance, take a look about the payment functionality:
Accept numerous offline payment processing (cheque, money orders, offline credit care processing, ..)
Accept numerous online payment processing (PayPal, 2CheckOut, Authorize.net, iPayment, ..)
Disable certain payment services based on a zone basis
You can use Opencart. It also supports multiple stores. And it is done in PHP so it covers all your intentions. You didn't say if you want to be open source. Opencart is opensource. Shopify could be a solution too, but it is not free.
http://www.opencart.com/
http://www.shopify.com/
Related
I developed a website that is currently using PayPal Adaptive Payments to manage transactions between different users. I saw that paypal is renewing apis from classic to rest apis. It is really complicated to understand all that stuff. My question is about Adaptive Payments classic api...is there already a rest api that substitutes adaptive payments classic or not? Is there any better system to allow dynamic payments between different users?
Thank you!
Short answer: if your website already uses Adaptive Payments and is meeting your needs there's no compelling reason to switch. The Adaptive Payments APIs will do most of the things PayPal's other, competing APIs do, and some things those APIs won't. Only change if you're redoing your site anyway, or you need specific functionality the current APIs don't offer. You havn't listed any specific gap or need in your question so I can't say more.
Background: broadly speaking, PayPal has developed three generations of APIs:
The original set, including products like Express Checkout, are
pretty squarly focused on web (and mobile) "checkout", the dominant
paradigm of a decade ago for the purchase of goods and services on a
merchant site.
The second set, which includes Adaptive Payments, was
intended to be more flexible (hence the "Adaptive" name) and address
payments that might not be "just" checkouts. For example
multi-merchant marketplaces.
The third set is PayPal's RESTful APIs,
which are designed primarily as a technology refresh to replace
earlier APIs. The RESTful APIs are still being developed and do not
yet offer all the functions of the previous APIs, but are likely to
get more investment and development going forward; as such -- and
because they use newer, more industry-current integration styles --
they may be a good choice for new integrations.
(I work for PayPal and wrote a chunk of the first API set but am not an official company spokesperson, so consider this informed but not authoritative.)
I need to build web application where users can sell goods.
Each user should be able to get money directly on his PayPal account.
Can you suggest which PayPal service/payment method (or other payment system) it is better/safely to use in this case?
Thanks in advance
This is easily set up (if I read your requirements correctly). You would have to create your part of the system, but that's obvious.
The rest, specifically vendor payments, could be handled all by PayPal.
PayPal could process the orders into individual accounts. You would simply have to use the same IPN notification file for each Buy Link. This IPN notification file is what PayPal uses to notify an order has come. It does not matter that it may have come TO Suzie's or TO Bob's account.
So, your notification script gets the order -- Then, your internal system differentiates the vendor and ... that's it ;).
IPN is very simple too, and they've got nice templates in various languages to get you started.
I'm sure there are alternate ways to do it, but IPN is what I personally use, combined with a back-end system. I even have another vendor whose plug-in for my product I sell. Money goes directly into his PayPal account by simply changing the recipient email in the Buy URL (or form).
Any competent programmer should be able to handle this with ease. The proficiencies would be SQL/database experience and web coding (any language). That's about it. A non-programmer could probably even learn, though needs to be careful to sanitize the input to protect against SQL injection attacks.
You can use ExpressCheckout, this means that your sellers do not need tho have Pro accounts, but login and payment will occur in paypal's popup window. You can also use more advanced integration, but this might require the merchants to upgrade their account, and this might cost them money in every month.
You also need to collect API keys from merchants and store them in a very safe location, or collect the money yourself, and pay for the merchants using paypal's API code, but this will introduce additional (transfer) costs.
You will most likely have to write it from scratch. I mean, from some bare framework.
Im a new Drupal user . I want to be able to handle payments on my Drupal website. I would like to know which would be a better option, LM_Paypal module or the Ubercart module ?.
Does the Ubercart module have any specific advantages over the LM_Paypal module or vice versa ?
Please help.
Thank You
They're quite different -- Ubercart is a full fledged shopping cart with dozens (hundreds?) of add on modules for things like coupons, shipping, different payment gateways, wishlists, inventory, etc. If you just need simple subscriptions or buy buttons, lm_paypal might be for you. But if you want (or think you will grow into) a full online store with additional features, you probably want to start with ubercart out of the gate.
Sorry cannot give you a comparison as have only used one, LM_Paypal. However installed over a year ago, done at least two Drupal upgrades since then and it is still functioning fine.
I've used Ubercart, eCommerece and LM Paypal. For my needs (which are basic subscriptions and donations + small purchases) I stuck with LM Paypal since it's VERY easy to understand and setup. The others are much more complex for beginners and can take some time and head scratching to get up and running.
If you just need handle incoming payments I'd recommend LM Paypal.
got a question and I hope this is right place to ask :).. don’t quite understand how payment works in magento.
client goes to checkout and lets say wants to pay as a guest, so provides address etc. and finally gets to payment methods. Then I want clients to pay thru credit card. Already have module installed for gateway (bank?) of my choice. At that point I would expect users to be redirected to 3rd party page (bank hosted) where they giving all the details, only after being returned to my magento site with appropriate message.
In magento however it seems like they need to provide cc numbers and details on magento checkout page. I don’t understand if I (or the payment module I installed) need to transfer then all the credit card details to bank? I would have to have checkout page on ssl connection and static ip right?
The thing is I want to avoid touching CC numbers at any point and would love to have it done by a bank page. I like the idea of magento interface all the way without redirecting to another page though, the only problem is not sure if would be able to set it all up properly.
If anyone could explain to me possible options, what is the common way to do it and how the whole process works that would be very much appreciated.
I did my research and looked all over google and various forums still need someones help though. Please let me know if some parts of my question are not quite clear, will try to better explain if necessary.
Had to develop a payment module for DPS in NZ some time back. How this works is, you go to pay on the site and the payment module php code runs that sends off the details to an acquiring institutions payment website who process the transaction for you with the bank. In my case as I recall it was DPS NZ via some soap calls. The Soap calls contained details such as the total cost, the currency, the merchant number to identify who you are paying. The acquiring institution (DPS in this case) then takes your credit card number and expiry date and do the processing. Then, again via some soap calls back to your own magento website you get redirected back with the error code - success, etc.
DPS use soap I think, but other payment websites may use other protocols to work. The other possibility is that your credit card acquiring page could be hosted on your website and you accept the credit card numbers and do all the processing within magento to the acquirer.
In short, the process is controlled by the payment module itself. If you want to see more detail, have a look at the payment module tutorials that are available and also the comments in the magento forums. You can also look at the paypal module code.
The default architecture that Magento payment modules use involves the customer interfacing with the module and the module talking to your payment gateway behind the scenes.
Basically the customer inputs all his data (CC and all) and hits the payment button at which point certain functions are run in the chosen payment module. What these functions do is entirely up to how the payment gateway works. if the gateway talks via XML they send/receive XML, if it needs SOAP then they use SOAP and so on and so forth. This in fact is the gist of building a new payment module. Open an existing one, check out which functions are called, get rid of the code in there and substitute with your own that will talk to your particular bank/gateway.
Of course some gateways have an alternate way of operating where you send the customer to their pages, he gives them his CC data and he is promptly returned to your site. This way you don't need to worry about handling credit card data, but unfortunately the process of implementing this in Magento is somewhat more involved.
If you need to use a certain gateway then you should first check whether a payment module for it already exists. if not you can download a similar payment module, dissect it and modify it to run your code where appropriate.
Ambiguous question, I know. But anyway, I'm developing a client's site that will enable users to donate to people doing charity work abroad. I need the users of the site who create their profiles to be able to input their PayPal email address (for example) and as such any users who click the big 'Donate' button on their profile can donate directly to them.
I'm sure this is possible, at least using the PayPal API. However since this is all for charity work, I'd like to implement 'Gift Aid' - read about it at the link.
My problem is finding a payment system that we can use that has Gift Aid either 'built in' or that can make a clear definition between which payments are gift-aided and which are not - sorry if this isn't making any sense!
So ideally I'm looking for a payments processor that can integrate as seamlessly as possible into the client's site which I'm developing in PHP, can support Gift Aid automatically - or if not, clearly specify which payments ticked the 'Gift Aid' option - and supports payments from credit and debit card sources, etc. I hope this is understandable now!
I know there's obviously the PayPal API but I'm sure there are others, I'm just not too sure where to start looking or if the whole Gift-Aid thingy is even possible with transactions like this. Would it be more convienient just to code our own system?
Jack
I would use PayPal, definately. Making the effort to learn their API is not hard. Coding your own solution would be a nightmare. Don't reinvent the wheel!
Have you tried looking at what CTT have to offer: http://www.ctt.org/products__services/cp_terminal/default.asp they have their own payment Gateway called CPterminal/CPWeb which is designed for charities.