I am developing a website which will charge our customers monthly fee ($200/month) for membership.
So the payment will be recurring automatically.
My client (the website owner) wants to reduce the credit card transaction fee. So I am comparing credit card (through authorize.net), Paypal, and bank wire transfer.
I think bank wire transfer is the cheapest method. However, I don't have any experience with it. Can you shed some light on this? How can I decide what's best between these options?
I am in California.
Choosing a payment gateway and merchant account, and possibly a recurring billing system for subscriptions, is a complex technical + business decision, and you may well need all three. If your requirements fit a specific 'modern' payment gateway such as Stripe or Braintree you might be able to get away without the recurring billing system.
First you need to do a lot of research, and think about your requirements. As an example, here are some that I wrote recently as part of investigating this space for a UK SaaS startup:
Important point: many people seem to base their decision purely on the percentage fee taken. In my view this is a huge mistake - many other factors will be more important.
If you choose the wrong provider(s) and want to migrate elsewhere, it can be hard or impossible to get your customer card data out for transfer into another provider (card data portability is the term). BrainTree and Recurly are good here, many others don't allow any portability.
If you want to expand to international markets outside US, you will need some abstraction of the payment gateway as the European market beyond UK is entirely different (far fewer credit cards, most people use direct bank payments aka SEPA direct debit). Here you would need different gateways, e.g. GoCardless or WireCard. See Spreedly's excellent blog for more on why this matters.
If you are going to build a recurring billing system, you can use Spreedly, otherwise consider Recurly etc. Generally I would look at the market leading recurring billing systems (Recurly and Spreedly, though Spreedly are changing strategy to become more of a payment gateway abstraction layer) so you can avoid building your own billing system.
Building a billing system is much more complex than most people realise (pro-rating, refunds, credits, upgrades, downgrades, changes in pricing model, sales tax / VAT, etc), and a big distraction for most startups. Just getting tax correct depends on geographical rules, and in Europe on whether the customer is VAT registered).
My shortlist, for what it's worth based on my requirements for a UK SaaS startup with US/Canada/Europe as key markets, was:
"Non-underwriting model" means you don't need a trading history to get this service (can be a challenge for startups ) because the merchant account is run by the service not by you (i.e. like Paypal classic accounts). The tradeoff is that if you grow really fast or have unusual payment patterns (e.g. pre-orders) your account can be frozen.
PCI approval is a big issue - going for certain payment gateways (Stripe or Braintree) means you can use a 'transparent redirect' or a simple JavaScript embedded form, both of which mean you don't store or even transmit credit card numbers through your site. This in turn means a much lower cost PCI approval (self assessment rather than a full-blown PCI evaluation) and means you can host on VPSs or cloud. This factor alone could determine best approach for you, and save far more money than 0.5% on payment fees.
Some useful links from my rather long wiki page on this topic:
Personally, I would try really, really hard to stay payment gateway independent if you plan to expand a lot - you can negotiate a better deal when you are larger, including switching gateway, and you can add other payment options such as bank wire transfer later. Recurring billing systems may also make it simpler to do invoicing of clients, but that's getting into the realm of more complete billing/accounting systems.
Hope that helps!
Sounds like you need to do some research on the topic of payment systems. There are tons of little changes you need to concern yourself with when dealing with gateways, processors, and the like - much more than one can cover in this post. And - if the API is poor, your developers will run for the hills.
You are correct about cost savings if you do a bank ach transfer vs. a credit card transaction - consider doing some reading on vendor sites like balanced to learn about whether that is something your implementation can use (note: many "ship product to customer" implementations can't use it - delay is too risky)
Go with Stripe.
They do not have the same merchant account requirements that Authorize.net or others have and they can integrate with Wufoo (not required) so you can have a simple payment form. They deposit the money in your account 7 DAYS after which is how they don't require all the merchant accounts.
Traditional Payment Fees
* Merchant account
* Payment gateway
* Card fees
* Bank fees
* Subscription service (Recurly, Chargify, etc.)
Stripe fees
* 2.9% +$.10/transaction
* Wufoo ($20/month)~optional
They charge 2.9% which on the surface seems high (plus the 7 days) but compared to some card fees, Amex 3.5+%, Mile or Reward cards in the 3.9% plus your others fees it is a better service.
One drawback, THEY DO NOT HANDLE INTERNATIONAL commerce!