Answers.Body: <p>What you are describing is not unusual and is within the range of processes that CiviCRM can handle. See here for some details:
  <a href="https://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=184188933" rel="nofollow noreferrer">https://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=184188933</a></p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>You'll want to look at a few examples and also the core payment object that you'll be subclassing:
  <a href="https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-05T11:03:44.430Z
Answers.Text: I didn't know about [payment types](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php#L63) 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](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/ContributionBase.php#L550)? In NZ at least, debit cards are handled more like credit cards than like direct debits.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-06T14:46:46.377Z
Answers.Text: 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 ...
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-06T14:48:11.773Z
Answers.Text: 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.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-29T19:04:31.127Z
Answers.LastActivityDate: 2016-11-29T19:04:31.127Z
Answers.UserDisplayName: Alan Dixon
Answers.Body: <p>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.</p>
  
  <p>That said, what you describe sounds a lot like the structure of the Flo2Cash payment processor in NZ, and Fuzion's processors for <a href="https://github.com/fuzionnz/nz.co.fuzion.flo2cashwebservice" rel="nofollow noreferrer">Flo2Cash WSDL (merchant hosted)</a> and <a href="https://github.com/fuzionnz/nz.co.fuzion.flo2cashdonate" rel="nofollow noreferrer">Flo2Cash Donate (3-party)</a> have what sounds like a similar structure.</p>
  
  <p>On Flo2Cash side of the interface, the relevant terms are <code>Frequency_ID</code> (eg week, month) and <code>Installment_Number</code> (number of payments), see <a href="https://github.com/fuzionnz/nz.co.fuzion.flo2cashdonate/blob/1.x/flo2cashdonate.php#L211" rel="nofollow noreferrer">here</a> and <a href="https://github.com/fuzionnz/nz.co.fuzion.flo2cashwebservice/blob/1.x/flo2cashwebservice.php#L212" rel="nofollow noreferrer">here</a></p>
  
  <p>Take a look at those processors and see if that answers your question?</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-28T02:14:40.880Z
Answers.LastActivityDate: 2016-11-28T02:14:40.880Z
Answers.UserDisplayName: Chris Burgess
Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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).</p>
  
  <p>Any suggestions on the best approach for this?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-11-28T06:23:31.207Z
Comments.Text: 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
Comments.UserDisplayName: Integration Team
Tags: <payment-processor><developer><modules>
Title: Best way to write module for 'unusual' payment gateway
ThreadText: # Best way to write module for 'unusual' payment gateway
  
  (Asked by: username_0 on 2016-11-27)
  
  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?
  
  **Tags:** payment-processor, developer, modules
  
  > **Comments:**
  > **username_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  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2016-11-29. Score: 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>
  
  > **Comments:**
  > **username_3**: I didn't know about [payment types](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php#L63) 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](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/ContributionBase.php#L550)? In NZ at least, debit cards are handled more like credit cards than like direct debits.  
  > **username_2**: 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 ...  
  > **username_2**: 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.  
  
  ---
  
  ### Answer by username_3 on 2016-11-28. Score: 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)](https://github.com/fuzionnz/nz.co.fuzion.flo2cashwebservice) and [Flo2Cash Donate (3-party)](https://github.com/fuzionnz/nz.co.fuzion.flo2cashdonate) 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](https://github.com/fuzionnz/nz.co.fuzion.flo2cashdonate/blob/1.x/flo2cashdonate.php#L211) and [here](https://github.com/fuzionnz/nz.co.fuzion.flo2cashwebservice/blob/1.x/flo2cashwebservice.php#L212)
  
  Take a look at those processors and see if that answers your question?
  
  
  ---
  
  