I'm making a site for a coaching company, and they've requested that we somehow keep card information on file (I informed them that that is a big no-no, and most payment API's will handle that side of things for us) so that we can charge the cards 'on-demand'. For example, the person shows up to a coaching session, types in a pin, and it charges their card for one session.
Best case scenario- this also works for an online store as well for payment processing. Once the card is on file, they can create a card, punch in their password, and they are good to go.
We are currently using Authorize.net with Ruby on Rails. I'm still fairly new to the development world, and this is my first time needing to handle payment processing. As far as I have seen, there isn't as much documentation as there should be. They would prefer not to use Stripe, as it has high per-charge fees, and most of our fees are $8-$15, and they also want to avoid PayPal, as it has been known to freeze accounts for no good reason.
Storing credit card information on your side is not practical for two reasons - security and cost (PCI compliance). Your best option is to use Stripe or Braintree.
Both offer great libraries and work as payment aggregators (no need for a merchant account with a bank to start processing payments).
https://stripe.com/docs/api#cards
https://developers.braintreepayments.com/ios+ruby/sdk/server/payment-method-management/create
For Authorize.Net, you would use Customer Information Manager for secure data storage. http://developer.authorize.net/api/reference/starting_guide.html#customerInfoManagerID
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 the early stages of integrating a vendor marketplace (similar to Etsy, but for a very niche demographic) into an online community. I envision a platform that allows vendors to sign up and post goods for sale, with all transactions handled through the platform. Payments would be made from the consumers directly to the Paypal accounts of the vendors. A processing fee would be incurred for each transaction, with the sum of all fees billed to the vendors at the end of each 30 day period.
I have briefly looked into Activemerchant, though I feel as though it may be the right tool for the job. Does this sound like something that could be accomplished using Activemerchant?
Activemerchant is simply an API front-end to one of a fairly large number of payment processors. As such, it would surely handle the job of getting money from consumers. The funds would normally be deposited into the bank account that you set up with your payment processor.
Then you would need a separate process to pay vendors, which could be handled via one of PayPal's APIs. The two processes (get money from consumer, pay money to vendor) could be disconnected or integrated.
Check out http://poundpay.com It's geared towards your specific request.
I don't think, there is a multi vendor solution available that which build on Rails.But i have found various solutions on Core php and ecommerce software like open cart,oscommerce and so on.
Refer Multi Vendor Shopping Cart Software
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!
I know it's possible to sit between a payer and payee using PayPal by just storing payee's PayPal account information.
Is it possible to take a percentage of the that transaction and pay it to a different PayPal account. Basically acting as a service fee for using our website?
If it helps, I would probably be using Active Merchant for rails.
What you are looking for is called "Chained Payments". You can take a commission from a payment, and the remainder can be split with one or more payees. The original payer only sees you. Chained payments are one of the several types of workflows you can get through the "Adaptive Payments" API.
More info on:
https://developer.paypal.com/webapps/developer/docs/classic/adaptive-payments/integration-guide/APIntro/
and pages 18 and 19 of the following manual on Adaotive Payments manual at cms.paypal.com/cms_content/US/en_US/files/developer/PP_AdaptivePayments.pdf
I was looking into this very same scenario, and I believe I've found that it is supported via PayPal's Website Payment Pro API. It appears as though there are several available use cases, such as:
Taking a cut, as you described
Dividing up a single customer payment among multiple payees (so if you have a shopping car where you resell items from several different providers, you can divide the payments up based on who provided each item)
Take a look at the document here and see if it fits your needs. I'd be very curious to hear how your integration goes, since I'm looking at something very similar for my forthcoming site.
https://www.x.com/docs/DOC-1328
EDIT: You should also take a look at the Adaptive Payments API. That was the other service I found that may fit this use case...
https://www.x.com/community/ppx/adaptive_payments
You can automatically charge transaction fees between the payer and payee if you use the Amazon Payment Service. It explicitly supports your business model.