Skip to content

Releases: iATSPayments/com.iatspayments.civicrm

1.5.2 Security (Revised from 1.5.1)

15 Jun 22:01
Compare
Choose a tag to compare

As identified by Chris Burgess (https://github.com/xurizaemon), the extension had the potential to be storing client credit card data on production sites, contrary to PCI requirements (for typical sites using this extension). This condition occurs only on Drupal sites with the 'framework logging' setting turned on (default is off). Under these circumstances, debug code was writing the credit card data into the Drupal watchdog log.

This release includes a fix to that code (by only writing this debug data when using the test environment), as well as a short list of other resolved issues, including the ability to use the www2.iatspayments.com as the payment processor domain for sites that don't support the new SSL requirements.

A separate releases to support CiviCRM 4.3 is also available as 1.4.3.

1.5.1 Security

14 Jun 21:04
Compare
Choose a tag to compare

As identified by Chris Burgess (https://github.com/xurizaemon), the extension had the potential to be storing client credit card data on production sites, contrary to PCI requirements (for typical sites using this extension). This condition occurs only on Drupal sites with the 'framework logging' setting turned on (default is off). Under these circumstances, debug code was writing the credit card data into the Drupal watchdog log.

This release includes a fix to that code (by only writing this debug data when using the test environment), as well as a short list of other resolved issues, including the ability to use the www2.iatspayments.com as the payment processor domain for sites that don't support the new SSL requirements.

Separate releases to support CiviCRM 4.3 and 4.2 that are still using this extension will be available shortly.

Post Valentines Day

19 Feb 17:58
Compare
Choose a tag to compare

This is a significant upgrade, but does not include 4.7 support (that's the next release).

The major feature improvements include:

  1. Better editing of recurring contributions (i.e. of additional fields like next scheduled contribution).
  2. Viewing of recurring contribution card information ('card on file'), editing and one-time processing of credit card on file (https://github.com/iATSPayments/com.iatspayments.civicrm/wiki/Card-on-File)
  3. More sophisticated error handling (https://github.com/iATSPayments/com.iatspayments.civicrm/wiki/Recurring-Contribution-Failure-Handling)
  4. Recurring contribution advanced features, like fixed day of the month (https://github.com/iATSPayments/com.iatspayments.civicrm/wiki/Recurring-Contribution-Job)

More details in this blog post: https://civicrm.org/blogs/adixon/recurring-payments-advanced-functions

Under the hood, there's been a little refactoring of the initial recurring contribution handling to use a new workflow that separates the initial setup from the first contribution (to support fixed date recurring contributions, and also to be more like the standard recurring contribution workflow in CiviCRM).

Halloween

30 Oct 17:58
Compare
Choose a tag to compare

This is a minor technical release that allows CiviCRM 4.7 to automatically load the extension in installation.

It also adds the extension version number to the comment field sent to iATS for better tracking/debugging.

And it uses the new recurring receipt option for ACH/EFT and UK DD recurring contributions now as well.

Thanks to mlufty for the fix to the locking code that prevents multiple parallel recurring contribution system jobs. There is also a fix to the code that filters out IPv6 addresses from breaking iATS servers.

Recurring contribution email and ACH/EFT improvements

11 Sep 17:33
Compare
Choose a tag to compare

Recurring contributions created by this extension now can be switched to include email notifications to the donor.

A variety of improvements to the ACH/EFT forms is also part of this release.

1.4.0

16 Jul 14:53
Compare
Choose a tag to compare
  1. This is the first CiviCRM 4.6.x version compatible release. The major compatibility issue was the naming convention for the two api Jobs. Using the previous versions of this extension with 4.6.x meant that these jobs would not run.
  2. We've taken the opportunity to refactor the javascript to comply with the new 4.6 standards, and move most of it into js files and out of the inline scripts in the templates.
  3. We've also converted recurring payment generation to follow the pattern of creating a pending contribution and using the completetransaction api, allowing for better bookkeeping and membership integration (i.e. recurring contributions attached to memberships will now renew the membership).
  4. We're now including a civicrm report that knows about the iATS-specific logging tables, so you can supplement the iATS Admin page with reports that flag upcoming Credit Card expiries, for example.

Thanks to lola, kurund and eileen for additional patches.

1.3.2 Bugfix release

01 Apr 15:10
Compare
Choose a tag to compare

This release includes a collection of small improvements, no new user features.

  1. faster ACH verification.
  2. CiviCRM tracking information sent to iATS for their statistics (i.e. to track the use of CiviCRM in their system)
  3. Canadian spelling on ACH form 'cheque',
  4. iATS fraud tracking for ipv6
  5. Activity Reporting bugfix
  6. Locking during generation of recurring contributions for prevent duplicates in case of multiple parallel cron runs

Introducing UK Direct Debit

19 Dec 14:37
Compare
Choose a tag to compare

This is the first tagged release of the CiviCRM iATSPayments extension to include support for UK Direct Debit.

Please note that the UK Direct Debit functionality in this code is still considered 'beta' and is recommended for use in production environments that are somewhat forgiving and with attentive administrators.

This release also includes a fair amount of bug fixes and improvements to the overall code, particularly the North American ACH/EFT verification code that is now more reliable under adverse conditions, and will verify your transactions sooner than before.

This update recommended for all installs, except those with CiviCRM version 4.3 or less, for which support has now been dropped.

NOTE: to ensure all different types of transactions are working across all CiviCRM pathways [our test matrix includes 20 type of transactions at the moment] - a small patch to CiviCRM core is required. You can find iATS_4.4.10.diff and iATS_4.5.4.diff in the repository. If you use another version of CiviCRM you may have to adjust the line numbers in these patches.

SWIPE Updates and bugfixes

11 Sep 19:16
Compare
Choose a tag to compare

This release fixes a number of issues related to the new SWIPE payment processor type, including a reconcile call so that the payment processor appears in existing installations.

It also fixes the issue identified in request #12.

Credit Card Swipe

04 Sep 12:53
Compare
Choose a tag to compare

This release adds new encrypted credit card 'swipe' functionality to the iATS Payments extension. It allows you to use an iATS encrypted USB card reader to capture and encrypt credit card details before they reach your CiviCRM environment. The functionality is useful for quickly and securely capturing card details to process transactions at in-person events.

To use it, you'll need to create a new payment processor via the Administration screen, of type 'iATS Payments SWIPE'. If you don't see it, you may need to disable and re-enable the extension (to be fixed in the next release).

When this SWIPE payment processor is enabled AND set to the default, it will force all backend Contributions via ‘+Submit Credit Card Contribution’ payments to use the card reader instead of manually typing in the clear text data. To go back to manual entry, just toggle the SWIPE processor to disable.

This only works with the encrypted USB card readers sourced from iATS Payments. Please email [email protected] for more info.

The release also includes some small bug fixes, including:

  1. issue #23 cancelling a recurring contribution subscription will no longer give you a confusing and erroneous error message.
  2. issue #31 handling missing email addresses properly.