To reproduce this issue:

1. Create/enable an iATS ACH payment processor

2. Create/enable any credit card payment processor (I have reproduced this issue with Authorize.net and/or iATS credit card payment processors)

3. Click "Create New ... Contribution (Credit Card)

In the section labeled "Credit Card Information" There is a heading labeled "Direct Debit Information" but this section has NO entry fields (Because of these missing fields , ie credit card number, etc it is impossible to do a back-office credit card contribution for any processor)

Just below that, there is a heading labeled "Billing Name and Address" which does have the expected entry fields.

If I disable the iATS ACH payment processor, then the "Create New ... Contribution (Credit Card)" screen works properly.

See attached image.

Our donation page ( http://kohalacenter.net/civi ) is a CiviContribute page that uses iATS as the payment processor. When a donor submits a recurring donation, no email receipt is generated, neither for the initial contribution nor for any subsequent recurring payment. The transactions all successfully go through, but no emails are ever sent. This problem only occurs for recurring donations; one-time donations generate confirmation emails to the donor immediately. We are running CiviCRM 4.4.10 on Wordpress 4.0.1. Thanks in advance for your help.

To reproduce this issue:

1. Create an automated recurring contribution for x installments.

2. Go to the "Contributions" tab for the contact and scroll down to the section listing recurring schedules. Click the "More" link then choose "Cancel" (FYI: The explanation on this screen seems incorrect, as its seems to refer to payment processors that manage the schedule on their end, and provide an API to cancel)

3. ISSUE: The next installment is processed as if the schedule is not cancelled. (also the recurring schedule status gets changed back to "in progress". )

I have a serious issue where an installment was sent to iATS to be processed, after the final installment was completed The recurring contribution was set up for 1 installment, but the extension processed 2 installments.

I am using version 1.2.6 of the iATS extension, with CiviCRM version 4.4.6

Using CiviCRM 4.5.3 and IATS 1.2.11, the purchase of an auto-renewing membership fails to populate membership start/end dates in the membership record created. The membership since field is populated properly.
Without membership start/end dates, the status for the membership is automatically set to "Pending" based on the membership status rules.
A contribution is immediately processed and the appropriate recurring contribution record is set up. I have not tested what would happen to the membership record when the next recurrence fires.
Note that on the same installation, non auto-recurring membership purchases result in all the fields for a membership record being populated appropriately.
Thanks.

I installed v 1.3.1 on a Drupal 7 / CiviCRM 4.4.5 site. When I run a test payment it throws an error "Table 'mydatabase.civicrm_iats_request_log' doesn't exist".

I ended up just running the install.sql manually.

The activity listed under Activity tab for a contact for activity_type = Contribution points to 1st contribution. Wrong link is generated for 'View' link as /civicrm/contact/view/contribution?action=view&reset=1&id=&cid=49032&context=activity. Since id is NULL, CiviCRM fetches 1st Contribution.

I have submitted PR(#58) which includes source_record_id to be passed in activity params during activity creation via api.

If one configures a Contribution page with options to pay either by direct debit or by credit card using two iATS processors configured for the same account, it is not possible to make a one-time payment. The confirm page comes back with recurring even when recurring is not selected.

The file BillingBlockDirectDebitExtra.tpl includes the following HTML:

That is using the British/Canadian spelling of check, not the US spelling which I need. I created a "word replace" rule in my configuration of CiviCRM, but it was ignored as this extension is not using the "ts( )" PHP function for strings.

Hi,
For what I remember, the processor name is used as a key and changing makes civi very sick. so

$this->_processorName = 'iATS Payments';

instead of
$this->_processorName = ts('iATS Payments');

(I might be wrong on that one, I don't write payment processors on a daily basis, feel free to ignore and close)

My method for adding the list of urls for 'backend' ACH/EFT is not the recommended one and could use some improvement.

1. Use a better hook so I can add elements to the smarty template.
2. Use the better way of extending smarty templates (http://forum.civicrm.org/index.php/topic,31894.msg136528.html#msg136528)

After the end-user did deduplication of some contacts, the associated recurring contributions started to fail with the message "iATS Payments Recurring Contribution (id=7) Errors: Recur id 7 is has a mismatched contact id for the customer code."

I examined the table "civicrm_iats_customer_codes" and noticed that the record for the impacted contribution had a CiviCRM contact ID that no longer existed. ( because of the earlier merge.) I used sql to update the correct contact ID.

Some questions:

1. Why even store the contact ID or the email address in the table "civicrm_iats_customer_codes" Why not just store the ID from the table "civicrm_contribution_recur" Then you can always do a join to get the correct contact ID. (This would protect things in the case of a merge/dedup process)

2. How can I re-animate the existing recurring schedule? There were 11 failed contributions before the extension gave up. But now there is a missing contribution, which can be made up as I fixed the record in the table civicrm_iats_customer_codes

Any objections to us providing a PR to post Financial Account information into the transaction so that it shows up on the IATS terminal when reviewing transactions? Could you provide a link to the version of the iATS API documentation that you are using? Thanks!

Under CiviCRM 4.4.x, the CiviCRM apis for updating extensions does not yet support triggering the database updates from a new version of an extension. Which methods in this IATS extension do you suggest calling so that I can automate updates? (This was discussed in more detail at: http://forum.civicrm.org/index.php/topic,34233.0.html )

Hi,

To avoid hard to debug problems, might be a quick win to add a
if (!function_exists("is_soap_fault")
display a give error message and refuse installing

I would like to use the new SWIPE feature mentioned at: https://civicrm.org/extensions/iats-payments as item #3. I am running version 1.2.10. But I do not see a new IATS SWIPE payment processor type when I try to add a new payment processor.

Also, do you have a list of SWIPE hardware that you have tested with? Or a technical spec covering the type of swipe device to buy?

I have developed a CiviCRM native extension ( https://github.com/sgladstone/com.pogstone.pmt2recur) that works well with non-iATS automated recurring contributions. The purpose of the other extension is to allow the bookkeeper to record a mailed check to cover a missed/failed automated contribution. Since there is no payment-processor specific code in the "pmt2recur" extension, I was hoping it would work with automated recurring contributions that are created via the iATS extension. However, in my testing the "payment instrument" gets changed from "check" (or whatever the user entered) to "Debit Card" and the status gets changed to "Pending". (This is not happening with non-iATS recurring contributions)

What is your suggestion for allowing the bookkeeper to deal with mailed checks in the situation where an automated transaction has failed? Could this iATS extension be changed to NOT alter a human-entered contribution record?

When a automatic recurring contribution (via DirectDebit/ACH) is created using a priceset, the first contribution looks good: All the line item records exist with the expected financial types for each line item.

HOWEVER, NONE of the following recurring contributions related to that schedule have ANY line item records.

For example: recurring Direct Debit contribution schedule is created with the following:
Contribution financial type is "--split--" . The priceset used results in 3 line items:
$25 for financial type "tuition"
$50 for financial type "dues"
$20 for financial type "donation"

(Total contribution amount is $95)

The first automatic recurring contrib. looks fine. However, all the later recurring contribs show total amount $95, all of it for financial type "--split--". There are NO line item records for tuition, dues or donation!

This is only impacting the Direct Debit contributions, thankfully not credit card contributions.

Alan and Karin,

My client has a big need for the partial payments functionality in CiviCRM 4.5.

Do you have an estimate of when the IATS Payments extension will be available for CiviCRM 4.5?

Thanks for all your great work on this.

Shai

Client added two recurring transactions today initiated by staff person in CiviCRM admin area.

The first one did not add a row to civicrm_iats_customer_codes. The transaction went through. Everything looks good at iatspayments.com. I added a row manually to ale_civicrm.civicrm_iats_customer_codes with the Customer code and expiry from iatspayments.com, the recur_id from civicrm_contribution_recur. I grabbed the email from looking up the contact ID in civicrm_contribution_recur.

One difference between the two transactions is that in the case of one that succeeded, the billing name and the first/last on the contact record were identical like:
Contact first/last: John Smith
Billing name: John Smith

For the one that failed to write a row to civicrm_iats_customer_codes, the name fields were filled like this:
Contact first/last: John Smith
Billing name: John J Smith Cohen

(Even though this issue is almost identical to #26 I thought it made more sense to start from scratch since there the focus was figuring out what was happening. We surmised that was some bad timing around a db restore, but didn't have conclusive evidence. In this case there have been no database restores, so there couldn't have been an accidental deletion.)

Any clues? In the meantime I'll monitor daily to make sure the number of rows in civicrm_contribution_recur is exactly the same as the number of rows in civicrm_iats_customer_codes.

Three improvements:

1. In line 52 of the ACHEFTVerify job, the code assumes no more than one transaction to verify per customer code, which is normally true, but a little risky for the case where a transaction happens every day and the verifications at iATS get backed up for some reason.
2. The PaymentBoxJournal method does not seem to include the previous day's transactions - try fixing this by giving an end time to the end data parameter.
3. There are rejections being pulled using the TEST88 account because of the new OR in line 131

There is an ACH recurring contribution that is scheduled to process monthly. (on the 8th of each month) It is not connected to membership.

Starting Dec 16, it is being processed daily (ie transactions are listed in the iATS portal) but are NOT listed in CiviCRM. The "Next Contribution" date for the recurring schedule is listed as Dec. 8 in CiviCRM.

Ideas on how to fix?

Useful until Github provides a CDN upload feature on wiki pages.

I installed the extension from "MASTER". Then I created a new automated recurring contribution to happen daily. The contribution is split across 3 line items and totals $3. Initially everything seems fine: I see a pending contribution with the correct details.

The next day after the first transaction is processed, I see a second contribution (line item details are correct) but the status is "pending". Also the first pending contribution is unchanged.

When I use the back-office screen "New Contribution (Credit Card)" the "Recurring Payment Block" is hidden. (If I click "View source" the HTML is there. )

As a work-around, If I change the choice of "payment processor" from the select list of all my active payment processors, then the "Recurring Payment Block" becomes visible. If I only have one active payment processor then there is no work-around.

I am running into this issue even when my only active payment processor is Authorize.net or PayPal. The only way to avoid the issue is to disable this extension or uninstall this extension entirely.

When I use the ACH payment option along with others (eg Pay Later, or Credit card) on a single contribution page, the layout gets funky. After the user clicks the "payment method" choice of "ACH" the field called "Account Type" and the picture of a sample check ends up being displayed below the questions for billing address. The rest of the direct debit questions are above the billing address section.

This is a different layout than when ACH is the only payment method available ( ie the user does not need to click anything to see the Direct Debit fields.)

If I enable BOTH IATS ACH/EDT and another processor (e.g Auth.net) on my contribution page, the recurring checkbox is marked true and read-only:

[x] I want to make this contribution every ....

... even if I've selected the OTHER processor. This is a bit of an edge case but should be fixed at some point. Note that I tested this on a 4.5 site, so it's possible that it's a 'new' behavior - but probably not. The payment block fields swap back and forth nicely when I change between processors.

After enabling a new payment processor (of type iATS Payments SWIPE) I am prevented from using any other payment processor in the back office, even other iATS payment processors. (SWIPE is NOT the default processor)

When a recurring transaction fails, it will keep getting tried until it goes through. At that point, then next transaction will get set based on the successful transaction, instead of according to the original schedule. Instead, it should try to keep to the original schedule if possible.

I've recently installed CiviCRM with IATS payments for a client.

The client set-up a bunch of recurring monthly donations on July 21. The initial transaction went thru immediately. However, the recurrence did not happen.

Cron is working fine. Here is the log message from cron:

Finished execution of Call Job.IatsRecurringContributions API with result: Success (No contribution records were processed.)

The test monthly recurring transaction that I set up on July 17 did process on August 17. I cannot see any differences in the way I set up the recurring donation on the test versus the way the staff person entered the recurring donations on July 21.

I've looked in the civicrm_contribution_recur table and I don't see any differences between the one successful recur and the others that didn't. The ones that did not process have a next_sched_contribution_date of Aug. 20. (I thought maybe the cron action might only look for that field time being within the time since the last time cron was fired, so I changed that field in one of the records to Aug. 26 (today) and then manually executed cron... but got the same result "no records were processed").

Thanks so much in advance for helping me troubleshoot this. The client has over a hundred transactions that did no fire on Aug. 20 which translate to income delayed to the organization.

The site is running Drupal 7.28 and CiviCRM 4.4.5. The extension version was 1.2.5 until today when I updated to 1.2.9. I manually executed the relevant IATS cron after I did the update and it had no affect.

Shai

The record in the table "civicrm_contribution_recur" has the incorrect status of "complete" even before a single installment has been processed. It should have the status of "Pending" while waiting on the first installment. Afterwards it should be "In progress". It should only be "complete" if ALL of the installments have been received. (For open ended recurring, it should stay "in progress" indefinitely)

Screen print shows the issue:

When a back-office user processes a credit card (such as by clicking "Create New...Event Registration(Credit Card) ") the payment processor "fee amount" field for the contribution gets populated, which is incorrect behavior. This issue does not occur for self-service event registrations.

This causes pain for the bookkeeping staff because when they use the "Accounting Batch" area ( Or Bookkeeping Transaction Report) , it appears that there are duplicate transactions. One record is for the income to the payment processor account, the other record is for the fee to the "Banking Fees" account.

This issue only seems to impact my Canadian client.

They are using this extension version 1.2.11

I am getting the following SQL error and stack trace during the upgrade:

CREATE TABLE civicrm_iats_ukdd_validate ( id int unsigned NOT NULL AUTO_INCREMENT COMMENT 'UK DirectDebit validation Id', customer_code varchar(255) NOT NULL COMMENT 'Customer code returned from iATS', acheft_reference_num varchar(255) NOT NULL COMMENT 'Reference number returned from iATS', cid int(10) unsigned DEFAULT '0' COMMENT 'CiviCRM contact id', recur_id int(10) unsigned DEFAULT '0' COMMENT 'CiviCRM recurring_contribution table id', validated int(10) unsigned DEFAULT '0' COMMENT 'Status id of 0 or 1 (after validation)', validated_datetime datetime COMMENT 'Date time of validation', xml longtext COMMENT 'XML response to initial validation request', PRIMARY KEY ( id ), KEY (customer_code), KEY (acheft_reference_num), KEY (cid), KEY (recur_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='Table to store UK Direct Debit validation information' [nativecode=1050 ** Table 'civicrm_iats_ukdd_validate' already exists]

Function Location

0 CRM_Core_Error::exceptionHandler(Object(DB_Error)) unknown:unknown
1 call_user_func(Array, Object(DB_Error)) /home/london/public_html/sites/all/modules/civicrm/packages/PEAR.php:931
2 PEAR_Error->PEAR_Error('DB Error: alread…', -5, 16, Array, 'CREATE TABLE ci…') /home/london/public_html/sites/all/modules/civicrm/packages/DB.php:969 3 DB_Error->DB_Error(-5, 16, Array, 'CREATE TABLEci…') /home/london/public_html/sites/all/modules/civicrm/packages/PEAR.php:564
4 PEAR->raiseError(null, -5, null, null, 'CREATE TABLE ci…', 'DB_Error', true) /home/london/public_html/sites/all/modules/civicrm/packages/DB/common.php:1905 5 DB_common->raiseError(-5, null, null, null, '1050 ** Table 'c…') /home/london/public_html/sites/all/modules/civicrm/packages/DB/mysql.php:898 6 DB_mysql->mysqlRaiseError() /home/london/public_html/sites/all/modules/civicrm/packages/DB/mysql.php:327 7 DB_mysql->simpleQuery('CREATE TABLEci…') /home/london/public_html/sites/all/modules/civicrm/packages/DB/common.php:1216
8 DB_common->query('CREATE TABLE `ci…') /home/london/public_html/sites/all/modules/civicrm/CRM/Utils/File.php:284
9 CRM_Utils_File::sourceSQLFile('mysql://london_m…', '/home/london/pub…') /home/london/public_html/pogstone_extensions/com.iatspayments.civicrm/CRM/iATS/Upgrader/Base.php:109
10 CRM_iATS_Upgrader_Base->executeSqlFile('sql/upgrade_1_3_…') /home/london/public_html/pogstone_extensions/com.iatspayments.civicrm/CRM/iATS/Upgrader.php:54
11 CRM_iATS_Upgrader->upgrade_1_3_001() unknown:unknown
12 call_user_func_array(Array, Array) /home/london/public_html/pogstone_extensions/com.iatspayments.civicrm/CRM/iATS/Upgrader/Base.php:65
13 CRM_iATS_Upgrader_Base::_queueAdapter(Object(CRM_Queue_TaskContext), 'upgrade_1_3_001') unknown:unknown
14 call_user_func_array(Array, Array) /home/london/public_html/sites/all/modules/civicrm/CRM/Queue/Task.php:79
15 CRM_Queue_Task->run(Object(CRM_Queue_TaskContext)) /home/london/public_html/sites/all/modules/civicrm/CRM/Queue/Runner.php:186
16 CRM_Queue_Runner->runNext(true) /home/london/public_html/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php:44
17 {closure}() /home/london/public_html/sites/all/modules/civicrm/CRM/Queue/ErrorPolicy.php:80
18 CRM_Queue_ErrorPolicy->call(Object(Closure)) /home/london/public_html/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php:47
19 CRM_Queue_Page_AJAX::runNext(Array) unknown:unknown
20 call_user_func(Array, Array) /home/london/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php:289
21 CRM_Core_Invoke::runItem(Array) /home/london/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php:72
22 CRM_Core_Invoke::_invoke(Array) /home/london/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php:52
23 CRM_Core_Invoke::invoke(Array) /home/london/public_html/sites/all/modules/civicrm/drupal/civicrm.module:456
24 civicrm_invoke('queue', 'ajax', 'runNext') unknown:unknown
25 call_user_func_array('civicrm_invoke', Array) /home/london/public_html/includes/menu.inc:517
26 menu_execute_active_handler() /home/london/public_html/index.php:21
27 {main}

When a donor completes a contribution using a Contribution Page that is configured to use an iATS payment processor (either credit card or ACH), the configured email message for that page is never sent. It should be sent to both the donor, as well as any configured CC/BCC email addresses.

When clicking the "cancel" link for a automated recurring contribution schedule ( ie at the very bottom of the Contribution Tab on a contact) the wording in the pop-up dialog window is very confusing and inaccurate. The current wording is:

"Are you sure you want to mark this recurring contribution as cancelled?

WARNING - This action sets the CiviCRM recurring contribution status to Cancelled, but does NOT send a cancellation request to the payment processor. You will need to ensure that this recurring payment (subscription) is cancelled by the payment processor. "

1. ACH transactions can be 'returned' after a request initial request for debit received a BankAccept. This can be days - but can also be weeks later. iATS Payments sends out an Email to primary contact on file for every single return.
2. At this point they are to be processed manually in CiviCRM -> by toggling the contribution status -> from completed to e.g. cancelled (most suitable CiviCRM Core contribution_status at the moment -> it puts Cancelled in red ink on view contribution screens and it also takes into account the logic for Civi Accounts. Note that you may have to also update Membership signup or Event registrations when status for the contribution linked to it is toggled from Completed to Cancelled.
3. Started work on grabbing the Returns directly from iATS Payments -> to be processed automatically (via a new scheduled job).

The SWIPE processor works by putting an encrypted credit card string into the credit card field and then clears the credit card type field. This works for 4.3.

But the strategy is broken for civicrm 4.4+ (since this commit: civicrm/civicrm-core#1730), because the validateCreditCard code now generates an error if the credit card type field is empty.

Since core is being reasonable, I think we need a different strategy - the overloading of the use of the credit card field is not very future-safe anyway.

Instead, I think we need to work with core to allow payment processors to provide their own validation logic - for swipe, we probably don't want any validation to happen, but perhaps there is some that we do, at least to prevent sql injection type hack attempts and or to prevent too many bad calls to iATS servers.

Still thinking about what an appropriate core patch might look like in the interim to allow this payment processor to work for the admin pages.

Set-up: CiviCRM 4.5.1 IATS extension 1.2.11 manually patched info.xml for 4.5 compatibility.

Client is using auto-renewing memberships (monthly) and we were hoping this would work with IATS.

It appears that it doesn't, though we just launched this. The membership record is behaving as we thought it would. But what we expected on the contributions tab was a recurring contribution below the list of contributions.

Is IATS compatible with automatic memberships? Are we missing something? Will the membership renew with the required payment and we just won't see anything analogous to what happens with recurring contributions?

Thanks for your support.

Shai

This one needs a pair of small core patches, provided here:

https://issues.civicrm.org/jira/browse/CRM-15307

http://wiki.civicrm.org/confluence/display/CRMDOC/API+changes#APIchanges-4.3.0:JobAPI

Says the Create Job API does not exist until Civi 4.3, yet it's called from install?

Sep 16 01:27:40 localhost drupal: PHP Fatal error: Uncaught exception 'Exception' with message 'API error: API (Job,create) does not exist (join the API team and implement it!)'

"License info here" is not one of the OSI approved one as far as I recall ;)

I am trying to get a direct debit to go through for the first time but getting an error stating "Payment Processor Error message
9002: Error : Could not create customer code."

I'm not sure what that means or what causes it.

It makes me wonder: What is the format for "Bank number + branch transit number" field?

On the bottom of cheques the MICR number format is
YYYYY-XXX
where YYYYY is the transit number and XXX is the three digit bank code. See http://www.canadaroutingnumber.com/

Whatever is the correct format, it would be useful to provide help under the field explaining how to enter the field based on information on a cheque. In the case of Savings Accounts, people may also benefit from being referred to the URL above or some other place that provides the bank number for their bank, since they often may not know that.

I've tried 0XXXYYYYY and XXXYYYYY but neither worked for me.

I almost posted this as a comment in #24, but I think it is a different issue.

Alan wrote in #24

When a recurring transaction fails, it will keep getting tried until it goes through.

That's not my experience. Well, let me qualify. That is my experience if the cause of the failed transaction is an expired credit card. Note that in the case of an expired credit card, iatspayments.com never gets touched. The rejection happens prior to anything being sent to iatspayments.com

However, if there is a different reason for the rejection, which is determined at IATS servers, the next date in that case gets pushed one month forward from the time of the transaction.

In my case in the last two days, 118 transactions were processed and there were 12 rejects of type code 15. Those were all caught by the IATS server and in every case the next sched date was pushed up by a month.

The status was appropriately set to "Failed", but the next sched date was advanced.

1. The README still mentions 'Backend' ACH/EFT being broken in core. Wasn't this fixed in 4.4.5? I know it's been a while since your last commit though.

2. The wording on the UK exception is unfortunate, as it bundles the whole EU in it:

   ACH/EFT contributions are forced by this extension to be recurring only. Support for the UK server has been excluded due to different legal issues with EU direct payment.

   Is the regular SEPA (mandate) supported or not?

   This is not clearly written on the extension page either.

3. iATS offers their service to the whole EU (maybe more), so "operating in Canada, US, and UK" is not doing them any favours on the extension page, even though they don't have offices outside the three. But this is severe nitpicking already, so you can ignore this one.

When hitting Edit on a recurring contribution.

1. I go to my contribution page.
2. Select POS payment method to see the swipe option.
3. Fill out the information, swipe the card, and click Confirm Contribution.
4. Then I see this screen:
   
5. So while still on this screen I select Credit Card payment method and I see:
   

Most payment processors provide this service. (like authorize)

Any thoughts about this approach.

Why maintain the code and risk / responsibility when the processor can assume that.

As per issue #26 - generate more/better error messages when recurring payments fail.

In CiviCRM Extensions panel, this plug-n shows an update to 1.3 but fails to install due to "unable to extract...ZIP"

Please advise.