Which payment processor to choose

[pike67]

Hello

If this has been asked before, and answered extensively, forgive me. Couldnt find it.

There is a list of payment processors here
http://wiki.civicrm.org/confluence/display/CRMDOC/Payment+Processors

There is no working demo of any of these (is there?)

I understand that page offers as little bias as possible, but I am interested in peoples experiences. This is a forum, so we can put hurrays and booboos here :-)  Any experience, or pointers to anything, is welcome.

The problem is: I am not sure on what grounds I would choose from that list. There are a few formal arguments that I can use to limit the list down (recurring,yes,on-site ssl,yes). But after that, I'm guessing. I am tempted to choose http://authorize.net   just because its on top. Also tempted to choose https://stripe.com/ because their product looks great. Both arguments sound bad.

There seem to be a few negative words on paypal on the list, even though core support seems very good. Why is it 'confusing' - do users have to become paypal members, with an account name, to use paypal ? Also for paypal pro ?

There is a mention about authorize.net resellers, that confuses me. Can I use a reseller account from within CiviCRM ?


thanks,
*-pike

[pike67]

One good argument ofcourse would be pricing.
Forgive me again if I'm not *supposed* to put such a list here - delete it.
I'll just add the links, not the prices, because they will change over time.

I've only looked at those sofar - if anyone has other links, I can add them here.

• paypal : https://www.paypal.com/webapps/mpp/merchant-fees
• authorize.net : https://www.authorize.net/solutions/merchantsolutions/pricing/
• stripe : https://stripe.com/us/pricing
• iats: http://home.iatspayments.com/iats-payments-difference

[Hershel]

Authorize.net does not sell accounts--you would actually acquire your account through one of their resellers, that's all.

Regarding the choice of processor, certainly consider the fees, and it may depend on your projected monthly amounts as some give discounts for larger accounts.

Those links you posted, perhaps you could add them to the wiki page--there is a column there for URLs which is somewhat empty.

As far as your end choice, most of them work pretty much the same, as far as I know. So I don't think it is terribly important.

[e_mason]

These services differ in terms of integration with CiviCRM ... or at least iATS makes a strong argument about why their solution is better.  So also consider what you need the processor to do (such as process phone orders or in person card swipes).  I think there are also differences in the ability to handle ETFs.  Once you consider these factors, the "cheap" solutions may no be so attractive (imho, orgs start of with the free version of PayPal because of the cost ... but then discover its very expensive in terms of staff time and decide that $30/month is well worth it).

[CiviTeacher.com]

Paypal Pro or Paypal Express seem the best options for the folks I work with, in terms of price and no-fuss customer experience.

[adixon]

Well, first of all thanks for pointing me at that page which I'd forgotten about and has some stale iATS info on it.

I'll also fess up right here that I'm one of the developers of the iATS extension, so this isn't exactly unbiased.

As noted, there are actually two separate criteria you'll want to look at: what it does, and how much it costs. Neither of those is actually simple.

1. How much it costs.

This is not simple because different payment processors charge in very different ways. You definitely don't want to rely on the payment prcoessor's own propaganda, which is often written by their marketing department. Here's a long answer: http://homeofficekernel.blogspot.ca/2013/08/confused-by-online-payment-processing.html

The short answer is that there are different charges that are going to be charged by different actors (possibly up to three separate companies that may be involved), and some of those may be per transaction, some may be fixed per month, some may be a %, etc., etc.

The other answer is that anyone who tells you that they are the cheapest and only charge 2% is lying [to put it bluntly]. Taking credit cards online as a merchant will cost you, probably about 3% at least, in total.

2. What it Does

I'll have to differ with Hershel here: although there is some shared basic functionality (i.e. one time credit card charge), after that it gets complicated. Here are some other things that some payment processors do, and not always the same way:

a. Recurring payments. There are many ways that this can go wrong, even in core, e.g. with recurring memberships. It's an easier concept to imagine than actually deliver... The three basic models are IPN (where the payment processor takes care of scheduling and reports back to CiviCRM), Token (where CiviCRM does the scheduling), and NOT (i.e. the payment processor does the scheduling but doesn't report back, so the recurring payments don't show up in civicrm unless you manually put them in).

b. Direct Debit. This is a less expensive way to recieve money (for merchants) than credit cards, but few payment processors offer it (yes, iATS does!). It's also complicated by country-specific rules and language (e.g. SEPA, ACH/EFT ...).

c. Swipe. If you want to take money at the door of events, this is a great feature (and yes, offered by iATS ...)

If you're in the UK or Europe, then Direct Debit has it's own special requirements, and there's an extension if you want to do European direct debit on your own (SEPA), and iATS if you want a server to manage the fiddly details at a price.

And finally, a note about Paypal Standard which is absolutely the simplest to get started with (no signup cost and offsite payment page so you don't need ssl). Here are the two biggest problems with Paypal:
a. Limited customization of the payment page, and user confusion about whether they can actually use a credit card, leading to abandonment of the payment ...
b. Expensive for high volume (3.5%)

So I do recommend paypal standard if you have no budget even for an ssl certificate and only need it for a fairly captive audience (e.g. for membership or event payments), but not for any organization with longer-term aspirations.

[KarinG]

From what I've learned working on the new iATS extension with Alan (for 4.4.x and 4.5.x) is that there are many different pathways in CiviCRM where payment can be processed. And each and every one of them is a bit different. Our test matrix now includes 20 different types of transactions per CiviCRM Core version with #21 in the beta now.

My recommendation would be to compare payment processors for the specific functionality you need. Else there are too many apples and oranges. If you want to be able to take ACH/EFT (direct debit) payments on public Contribution pages - compare payment processor functionality and cost for that specific option:
a) is it possible to do that type of transaction with a given payment processor - in CiviCRM and
b) what are the costs for getting that set-up, monthly, per transaction, etc.