CiviCRM Community Forums (archive)

The concept of a payment processor 'type' is a bit confusing. Usually, it refers to the subclass of the base payment processor type (i.e. the PaymentProcessorType entity).

But there are two other ways of categorizing a payment processor:

1. By 'billing_mode', which seems to have been invented a while ago to deal with unique Paypal-specific behaviour.
2. By 'payment_type' which is usually 1 for credit cards, but can be 2 for direct debit. Introduced some time ago but regularly ignored by core code that is very credit-card centric ...

I'd like to propose that both of these get ditched in favour of greater use of object methods and subclassing.

Specifically, let's create a payment processor class CRM_Core_Payment_CreditCard and make most of the existing payment processors subclass that and put the credit card specific functionality (e.g. the card validation routines, and the field lists and rules) into that. Then we can create a CRM_Core_Payment_DirectDebit for all the direct debit-specific functionality. And then we can take out all the Paypal specific code in core that is nasty. Hey, while we're at it, let's move all those core payment processors into their own extensions!

As a nice corollary, I think we could then create a CRM_Core_Payment_Cheque payment processor and use that instead of the hodge-podge of 'is_pay_later' switches all over the code.

Here's another example of how that could be useful: the credit card swipe devices are credit card payment processors that don't have the same requirements in the credit card fields - for now, they are broken.

And from a code point of view - writing payment processor extensions would be much saner - more code can live in the payment processor object instead of all those buildForm hooks.

The most straightforward difference between Direct Debit and Credit Card is the billing block fields. Most of Credit Card processors are going to use the same set of fields, and most Direct Debit processors are going to a different set of fields (which is additionally complicated by variations across countries/regions).

But to answer the question of 'fundamental' differences, I'd have to just refer you to my blog post: https://civicrm.org/blogs/adixon/taking-payments-web-without-credit-card-hard

Or in summary: credit cards and direct debit are two different legal bases for transferring money over the internet. So how that might play out in the payment processor code is for example how they handle chargebacks, and how they handle the status of a payment. For credit cards, the transaction is pretty much instant, with the possibility of a charge back later, and the money arrives relatively soon. For Direct Debit, you're always just putting the payment into a queue somewhere for processing, with a greater likelyhood that it won't go through, and also the possibility for a later chargeback, and usually takes a lot longer than credit card to end up in your bank account.

re: pay later payment processor. Yes, i think my posting is probably a little naive about how easy it might be, but I do think it's feasible to implement pay later as a payment processor. From a bookkeeping point of view, I see no reason it wouldn't work as it does now - i.e. it gets entered into accounts receivable. When the payer is ready to actually initiate a payment, then this for now fictitious 'pay-later payment processor' would have to allow the contribution to be associated with a different payment processor (e.g. a 'cash' payment processor or 'cheque' payment processor, or some credit card payment processor), and then the logic of that payment processor would be invoked. A nice bonus would be to allow a payer to follow up a 'pay later' option to have a self-serve option for payment.

Great to see this being discussed!

If it helps to complicate the issue, there are many processors which we might call "aggregators", which present a unified API to many backend payment methods.  The OmniPay library is a good example, there are also third parties like GlobalCollect who offer a similar service, they will process bank transfers, credit cards, direct debit, etc.  Even PayPal will let you use a credit card without an account, in addition to their e-wallet method, after you've already entered their workflow.  It's probably best if the payment details are private to each processor, and that any CiviCRM core functions that need to handle this information do so using attributes like "is this PCI-scope cardholder data?", "recurring System of Record is external?"...

We deal with a lot of different payment processors at Day Job, and I've found that there is no way to categorize them cleanly.  In our case, the main characteristic of a payment processor is the type of interaction it requires from the user.  There is the unhosted type, where fields can be filled out in CiviCRM and our backend can initiate the transaction without further interaction.  There are iframe methods, where the form is hosted by the acquirer/processor, and redirect methods like the PayPal button, where CiviCRM isn't responsible for any of the interactions.  Some processors can switch between interaction styles depending on API parameters.

The ideas in this thread for cleaning up the payment processor code look solid, the only thing I'd like to add is that we should find ways to reuse code which don't rely on a possibly superficial, processor-level difference between credit and debit, cos that might tie our hands when we try to support a processor that can do both.  I like the idea of creating a component like CRM_Core_Payment_CreditCard, but just as a helper, not as part of the class hierarchy.

And thank you adixon for your work on the iATS extension!  I'm configuring it for a friend's non-profit at the moment, and I'm very happy to have this option.

Can you clarify what the subclasses might look like? e.g what functions would one see on the dd subclass vs a credit card subclass?

NB - I've also added some notes on the wiki page & I'll log a ticket for the tpl change I mention there