3

We are looking at writing a module for Ezidebit. Ezidebit allow the setup of Direct Debit payments online. However, the initial request to Ezidebit includes the payment frequency and Ezidebit initiates these future payments on the frequency provided.

So once setup Civi does not need to request any further payments from Ezidebit. Instead it just needs to import the payment receipts - which are available from Ezidebit via an API.

I'm wondering what the best way to go about building a module for this will be? It's not really a payment gateway as there are no real-time payments available via this aspect of Ezidebits service. It is probably more like a bank account with payments being received by Ezidebit that need to be entered in to Civi.

In Civi it is most likely going to be used for Regular Donors and if so we would need to be able to track the commitment the donor has made and also the actual payments received. This doesn't seem to quite fit Pledges (as it is ongoing) or recurring payments (as Civi does not initiate the payment).

Any suggestions on the best approach for this?

Improve this question
1
  • I work for Ezidebit in the Integration Services Team and I am able to assist with any matters in relation with integration and API usage, validation of business process and mapping to API calls, workflow design and review of compliance requirements. We are more than 'just the usual' payment gateway and offer processing capabilities for real-time credit card transactions as well as Direct Debit services for recurring payments. One of the areas that we are a specialist in is the Charity domain and our product will cater to the once-off and regular donor use cases. I can be contacted via phone +6
    – Integration Team
    Commented Nov 28, 2016 at 6:23

2 Answers 2

Reset to default
3

What you are describing is not unusual and is within the range of processes that CiviCRM can handle. See here for some details: https://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=184188933

Two key things you want to do for your specific payment processor code are: 1. Set the 'payment type' to '2' - this sets some default assumptions for debit cards as opposed to credit card (e.g. fields). 2. Create an automated job to pull in the completed contributions.

There are some complex things you may want to implement later, like being able to manage the recurring schedule from CiviCRM, but for now you can probably get the basics working without too much suffering.

You'll want to look at a few examples and also the core payment object that you'll be subclassing: https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php

Improve this answer
3
  • I didn't know about payment types being a thing, thanks for that gem! But are you sure that 2 = debit cards? The define is PAYMENT_TYPE_DIRECT_DEBIT = 2 (which applies well to this question) - "direct debit" not "debit cards". Looks like these are the fields it affects? In NZ at least, debit cards are handled more like credit cards than like direct debits.
    – Chris Burgess
    Commented Dec 5, 2016 at 11:03
  • Yes, there is some confusion in core about direct debit vs debit cards. You're right that for payment type, 2 is really setting the default fields to direct debit (what we call ACH or EFT in North America), i.e. from an account, and no card of any kind is required. On the other hand, for payment instrument, 2 is debit card and it really should be 5 for EFT, but I use 2 because 2 is the reserved one, and debit cards used online typically go through a credit card processing. So I tend to mix up direct debit and debit card all the time ...
    – Alan Dixon
    Commented Dec 6, 2016 at 14:46
  • And for the record, Eileen wants to get rid of that payment type concept altogether and have each payment processor explicitly define it's own fields.
    – Alan Dixon
    Commented Dec 6, 2016 at 14:48
2

CiviCRM's payment processing is much improved, but there may be some "baked in" assumptions about how things look which don't match new processor interfaces.

That said, what you describe sounds a lot like the structure of the Flo2Cash payment processor in NZ, and Fuzion's processors for Flo2Cash WSDL (merchant hosted) and Flo2Cash Donate (3-party) have what sounds like a similar structure.

On Flo2Cash side of the interface, the relevant terms are Frequency_ID (eg week, month) and Installment_Number (number of payments), see here and here

Take a look at those processors and see if that answers your question?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.