I am trying to create a donation centre of sorts in Rails for a non-profit, using PayPal, and am wondering if I should start from scratch or use an existing eCommerce gem/platform.
I want to:
- list various "products", or donation types that a user can select, customize and pay for
- be able to send/serve downloadable files to a donor, depending on their donation type
- keep track of donors, donations and various custom bits of data the user enters
- add hooks to add donors to mailing lists, push donation notifications to social media, etc.
Basically, I want something that looks like a store and supports digital products, but processes donations instead of sales through PayPal.
Does anyone have experience using Spree (or something similar) to accept donations? I can't seem to find evidence that this works without a lot of hacking.
Thanks!
There are several ways of doing this, but each will require you to roll up your sleeves and get into the code. I would recommend, especially if you are learning rails, using Daniel Kehoe's "railsapp - Ruby on Rails Membership Site"
http://railsapps.github.com/rails-stripe-membership-saas/
It is a great tutorial and building block for what you are wanting to accomplish. Don't just copy/clone it and use it out the box, I would run through the tutorial to get a better understanding of what is going on and how you can customize it to meet your needs. It uses Stripe, for payment processing.
I am working on a marketplace application similar to Etsy. Specifically, I am currently implementing the checkout process and I am struggling with the paypal payment implementation.
I would like to have a workflow similar to etsy:
customer to login/register on my website
customer redirected to paypal, entering delivery address and authorize the payment
customer redirected back to my website, eventually change the shipping address and complete the checkout
I don't understand how to take into account on step 3) of any changes that changes the order total. For instance, the customer may choose a different shipping country and therefore a higher or lower shipping cost may be paid. I don't want to cancel the previous payment and send back the customers to paypal to re-validate the payment, as this would most likely cause the customers to drop the order.
How do Etsy take into account these variations?
What kind of paypal payment type (Standard, Adaptive, etc) do they use?
It would be really appreciated if you could point me to some real word examples (I use ruby on rails, but any framework is welcome).
Your problem is that your step 3 doesn't really make sense. Let me explain.
In your step 2, above, as you probably know, you can only really give the customer a good shipping estimate when a delivery address is given. Until then, your estimate won't be as tight.
In your step 3, a payment processor (such as Paypal or Google Checkout) will adjust the order total based on shipping costs. (The details vary, see below for a Google Checkout example.)
After your step 3 is completed, this will complete the order. The processor will report back to your website saying the order is complete with the details. Your site does any final processing. (Your question above says "the customer may choose a different shipping country and therefore a higher or lower shipping cost may be paid" but this does not make sense to me. At this point, the order is done -- your site should not allow the user to change the shipping address -- unless the user wants to cancel the order entirely.)
Google Checkout
As for details, the Google Checkout API documentation offers many options you will be interested in. Read the "Shipping and Digital Delivery" section of the Google Checkout XML API Developer's Guide. These are the two that I think are most relevant:
Merchant-calculated shipping - For merchant-calculated shipping, you must operate a web service that calculates and returns shipping costs. Google Checkout will send your service a request containing the buyer's shipping address, the items in the order and the shipping methods that you offer. (You would have previously sent the items and shipping methods to Google in a Checkout API request.) Your web service then calculates the shipping cost for each shipping method and returns that information to Google.
Carrier-calculated shipping - For carrier-calculated shipping methods, you identify one or more FedEx, UPS or USPS shipping methods that you offer. Google will then dynamically calculate the shipping cost for each option based on the total weight of the items in your shopping cart. The carrier-calculated shipping document defines the specific shipping methods that Google supports for each of these carriers. For carrier-calculated shipping options, the default shipping cost is only used if Google fails in its attempt to obtain the carrier's shipping rates.
Refer to the documentation for full details. I would hope that option 2 works -- it seems to involve considerably less custom development work.
Paypal
Going through Paypal's docs is rather obtuse in comparison with Google Checkout's. So I'm going to point you in the right direction, but I'm not going to dig through all of it in detail just for you. Check out: Calculate shipping and taxes
Don't Forget Taxes
Bonus Material! Taxes can also vary based on the shipping location. Payment services have documentation that shows you how to do this.
I am using spree online demo ,having some issues related to shipping cost calculation.While
trying to add a single product to cart and checkout ,then all works
fine, the shipping charge added to the total amount correctly.But the
problem is that when am trying to checkout using multiple number of
same type product the shipping charge remains as the same for single
product,the shipping charge must change according to products count.
Thanks in advnc
Rajith
you need to use another shipping calculator for that, i don't know if spree includes one for your desired behavior, or if there is one available as an extension. nevertheless, writing calculators is extremely simple, the spree docs provide good information about this topic:
http://guides.spreecommerce.com/shipping.html
I have a client who recently changed the scope of a project I was building for them, to a marketplace.
Previously users had to pay a nominal fee to register for the site...I was handling credit card transactions using Active Merchant.
For the marketplace that they now want to build they want to build a simple escrow-type system...the payment to the seller gets released when the buyer receives the product.
This will be difficult for several reasons:
How will the system be able to determine when the item has been received? The receiver could simply lie about it. I know paypal does something similar, but they use the tracking number from the shipping company to determine this.
How do I go about depositing payments in the sellers account? It's easy to process the payment from the buyer, but how do I get this money to the seller?
For #2 I was thinking it might be possible to use some sort of paypal account to handle this...I haven't looked into any specifics yet. Any idea where to start?
Paypal may be able to handle #1 as well, if I am lucky.
Any suggestions?
We used PayPal Adaptive Payments for #2... still hunting for a solution to facilitate the transaction between User A and User B with the marketplace taking a %...
Would love to hear more answers!
In regards to #1 - I'd require some sort of signed receipt on delivery. That would depend on the value of the goods, at the lower range tracking receipt + some sort of reputation system to remove people who abuse the system has worked for me in the past.
In regards to #2, disbursements; I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
Balanced will allow you to collect funds into an escrow account and then disburse the funds as a separate action which allows you to split the funds up or group them together as required. Payouts are done via next-day ACH (US only) but we're building out international support.
Balanced has an excellent ruby gem since you're building in Rails and there's an ActiveMerchant plugin if that's what you are/have integrated with.
I am in my sophomore year of programming in general and Ruby on Rails more specifically. I have created several apps and finally have one that I would like to start charging for. I have never implemented something like this before and I feel like (from what I have read) most of the docs provided are a bit over my head. I don't mind diving in but before I did I wanted to get some opinion from those more experienced about what is the simplest way to implement a model for charging my User a month fee for use. Two notes:
My App contains Users already and I will be introducing a new section of the app which I only want to give access to those who pay.
I don't mind sending them to a third party page for payment.
From what I can find, it seems like both PayPal and Chargify do a decent job of providing help for this type of integration. What are your thoughts about which type of solution is best for a newbie to this space.
I'll admit I'm biased since I'm one of the founders of Chargify :-).
But before that I helped build 7-8 companies, most recently Engine Yard, and I really, really wish we'd had something like Chargify back then. I remember thinking, "Man, we need something like 'Basecamp for Billing'... it should be simple, sign up with a credit card, define products & pricing, and get going". So I found the Chargify/GrasshopperGroup folks and joined the team.
Chargify takes it up a level from what we found with payment gateway offerings and things like PayPal... with Chargify, you define products, prices, coupon codes, metered-usage units, etc., and let Chargify do as much as you want. The system emails your customers when their cards get declined or expire, and directs them to a URL to fix the problem, etc.
Billing gets complex as a business grows. I tell callers that if their needs are really simple, then they may indeed be okay with Auth.Net's ARB service or another like it, but as soon as your needs even begin to get less simple (ie, customers change plans mid-cycle and want proration), then Chargify really makes your life easier.
And as Rails folks ourselves, we're always working to make the service better, so you'll get more and more services as time progresses. And you can actually call us 24/7 and get someone on the phone! Our Level 1 phone team knows the product better and better each week and can send the call to Level 2 if they don't know the answer.
So, you're getting a good piece of software, plus a good team who's here for you to develop new features and provide support if you need it.
Sorry this sounds like an ad; it is, partly, of course. But it's also just a reflection of my frustration trying to build this at earlier companies, and my enthusiasm for being part of Chargify now and helping merchants not focus on recurring billing :-).
http://www.braintreepaymentsolutions.com/
At a previous place of employment, we used Brain Tree, and I only heard good things about it though I wasn't (and still aren't, but trying) a programmer at the time. It seems to be a little bit more expensive than the big guys - but has more freedom as well.
It might be worth looking into.
Charging System or Billing System?
Talking with a number of folks building businesses in the Ruby community, I thinks it's important to note that simply collecting customer payments and scalable billing are two rather unique animals. Today's SaaS companies are not always aware of the difference.
Hitting credit cards for $39.95 on a monthly basis is something most of the "payment tools" mentioned here do well. Yet, when one needs to incorporate a complex billing algorithm (charge model), client contracts, promotional codes, freemium, tiered, rollover or metered usage, or integration with other internal systems, They need more than a payment machine. They really need a "smarter" billing system that leverages a payment gateway, but does far more than simply hitting cards on a monthly basis.
Also, if one has a significant number of clients or volume a system that scales is key. For research check out more mid-tier billing systems like http://www.metanga.com or http://www.zuora.com.
To take payment you're going to need a few things:
A bank account to put the money in
A payment gateway
An SSL certificate (this can be tricky if you're in the cloud)
The beauty of products like chargify or braintree is that they give you a nice API for dealing with card events like expiry or failed payments and can sometimes also act as a payment gateway.
I integrated with cheddar getter (https://cheddargetter.com/) in an afternoon. There's a ruby gem (https://github.com/ads/cheddargetter) and they have a payment gateway service, but I haven't used that so don't want to comment on its value.
Payment is an annoyingly complicated process and you have to pay everyone down the chain, the hardest part is making sure your service is competitively priced but not priced in such a way where you're not making any profit.
Here's some more links you might be interested in reading:
http://www.activemerchant.org/
http://recurly.com/
I've used PayPal's Express Payments with ActiveMerchant before, because there's no buy-in cost; PayPal just takes their slice of each transaction, so I don't have to worry about paying fees to a ton of different providers. The downsides are well-documented, though, as well - specifically, if PayPal decides that you're doing something shady and decides to freeze your money, you're up the creek without a paddle. That's a calculated risk you have to evaluate, though.
You might look at Saasy if you don't want to roll your own full solution, though. It seems to integrate well with existing apps.
ActiveMerchant is definitely the way to go to get integration with PayPal or any of the creditcard gateways like Braintree (highly recommended) or Authorize.net (good and cheap). The SaaS Rails Kit, which I authored, uses it as the basis for a full recurring billing solution that you can integrate with your app.
Regarding your follow-on question about PayPal, ActiveMerchant makes it easy to use their API or IPN to get information back about the transaction status.
I've had a ton of experience with this and the first question that you need to ask yourself is "how important is recurring billing?" If recurring billing is a requirement then by all means use Chargify, Recurly or the like. They are all pretty good.
If, however, you are simply looking to outsource your payment process (as I typically am) so you don't have to deal with PCI compliance (which is a nightmare) then you have a lot LESS viable options IMO. You can use PayPal, Amazon or Google Checkout, but they all have downsides. PayPals user experience is terrible and many people get confused by it believing they need a PayPal account to complete the purchase. Google Checkout REQUIRES the user to either have or create a Google Account, which is ridiculous and Amazon is ok but like Google Checkout requires an Amazon account.
WePay is my personal favorite right now for outsourced billing but is very lean and you have to use their checkout process. Their staff and API is awesome though.
What I would LOVE to see if a Chargify-like solution that is focused on ONE OFF sales. Something that let's me host the entire checkout process on THEIR PCI Compliant server but allows me to customize not just the look and feel but form. If I wanted to ask for extra info, like a username and password, I can. If I don't need shipping address, I can remove it. If I only want the CC number, CVV and exp date without billing address I can do that, etc.
But to the best of my knowledge that does not currently exist. Don't use Chargify for one-off transactions. While they support it the checkout process is VERY clunky for one offs (displays things like $0 setup fee, which means nothing when someone is buying a shirt or one time downloadable material and is merely confusing).
Good luck!