agileware/au.com.agileware.ewayrecurring

CiviCRM payment processor extension for eWay which implements recurring payments using tokens and eWAY Rapid API

eWay Recurring Payment Processor for CiviCRM

CiviCRM payment processor extension for eWay which uses the latest eWay Rapid API and ensures PCI DSS compliance.

Supports both once-off and recurring payment utilising the secure token payment method. This essential for automating the process setting up recurring donations and memberships in your CiviCRM securely and reliably. This payment processor also allows you to specify a particular day of the month to process all recurring payments together.

You will need to have an eWay account to use this payment processor on your CiviCRM website.

Installation

1. Download the latest version of this extension
2. Extract it to your CiviCRM extensions directory, as defined in "System Settings / Directories".
3. Go to "Administer / System Settings / Extensions" and enable the "eWay Recurring Payment Processor (au.com.agileware.ewayrecurring)" extension.

Upgrade instructions

If you are changing from a different eWay Payment Processor or upgrading from eWay Recurring 1.x, please read the Upgrade Instructions

eWay API Key and Password

Configure the payment processor with the required eWay API Key and Password as obtained from the eWay Account. eWay provides step by step instructions for generating these details.

eWay Account Configuration

It is recommended to set the following options in the eWay account.

Log into MYeWAY and go to My Account tab > User Security > Manage Roles. Click on the Role to get to the Role Permissions.

Enable the Allow Beagle Alerts Customer IP Override permission for the role assigned to the API account. This is required for any CiviCRM site which is operating behind a proxy server such as Nginx, CloudFlare etc.

This can be indicated by eWay error response with text: Function Not Permitted to Terminal

Recommended eWay Shared Page Settings

By default, when a credit card payment is processed by eWay, the transaction is not confirmed in CiviCRM until either:

1. the customer waits for the default 5 seconds before being returned to the website or
2. the customer clicks the Finalise Transaction button.

It is often the case that neither of these events occur which results in the CiviCRM Contribution record being created with a Status of Pending (Incomplete Transaction).

The responsibility of marking these Contributions as Completed then becomes a manual process of reconciling the eWay payment with the Contribution record, which is not ideal.

To avoid this situation, it is recommended to change the Redirect After Payment Processing delay default from 5 seconds to 0 seconds. Thereby reducing the likelihood of the transaction not being confirmed in CiviCRM and thus ensuring that the Contribution Status is set to Completed.

To change the Redirect After Payment Processing option:

1. Login to MYeWAY.
2. Hover the mouse over the Settings tab then click on Shared Page.
3. Locate the Redirect After Payment Processing option.
4. Change the option to 0 seconds.

For more details see, https://go.eway.io/s/article/Can-I-customize-the-eWAY-hosted-Payment-page?language=en_US

Recommended setting for Redirect After Payment Processing is 0 seconds.

eWay Transactions Verification

The eWay Transaction Verifications job verifies the pending transactions in eway. This is required for when CiviCRM is unable to verify the transaction immediately, for example if the end user does not press the Return to Merchant button or if the contribution was made via a Drupal Webform.

Visit civicrm/admin/job to enable eWay Transaction Verifications job.

Failed eWay Transactions

Recurring contribution transactions could fail for one of several reasons; in these situations, the extension will mark the recurring contribution as failed and retry the transaction at an interval up to a maximum number of times, both of which can be configured.

To update the Maximum retries and Retry delay (in days) go to civicrm/ewayrecurring/settings. The default Maximum retries is 3 and Retry delay is 4 days.

CiviCRM template overrides

This extension applies changes to the following CiviCRM templates:

1. CancelSubscription - hides an option to send cancellation request, as all processing is done locally
2. Amount - adds a field to specify the day for recurring payment in the contribution page settings
3. UpdateSubscription - adds a field to change the next payment date

About the Authors

This CiviCRM extension was developed by the team at Agileware.

Agileware provide a range of CiviCRM services including:

• CiviCRM migration
• CiviCRM integration
• CiviCRM extension development
• CiviCRM support
• CiviCRM hosting
• CiviCRM remote training services

Support your Australian CiviCRM developers, contact Agileware today!

au.com.agileware.ewayrecurring's Issues

100% discount = Cannot change contribution status from Completed to Failed

Scenario: Contribution page for a membership, user has 100% discount code. Upon completion, gets stated error message.

Why: ewayrecurring_civicrm_preProcess() calls validateEwayContribution() for the contribution thank you page...

Validate eWay contribution by AccessCode, Invoice ID and Payment Processor.

...problem is, there is no AccessCode for $0 contribution.

Solution: update validateEwayContrbution() to make sure total_amount is greater than zero.

diff --git a/sites/all/civicrm_extensions/au.com.agileware.ewayrecurring/eWAYRecurring.php b/sites/all/civicrm_extensions/au.com.agileware.ewayrecurring/eWAYRecurring.php
index b00302422..ee7792762 100644
--- a/sites/all/civicrm_extensions/au.com.agileware.ewayrecurring/eWAYRecurring.php
+++ b/sites/all/civicrm_extensions/au.com.agileware.ewayrecurring/eWAYRecurring.php
@@ -459,20 +459,23 @@ function validateEwayContribution($paymentProcessor, $invoiceID) {
       'return' => [
         'contribution_page_id',
         'contribution_recur_id',
+	'total_amount',
         'is_test',
       ],
       'is_test' => ($paymentProcessor->_mode == 'test') ? 1 : 0,
     ]);
 
     if (count($contribution['values']) > 0) {
-      // Include eWay SDK.
-      require_once extensionPath('vendor/autoload.php');
-
       $contribution = $contribution['values'][0];
-      $eWayAccessCode = CRM_Utils_Request::retrieve('AccessCode', 'String', $form, FALSE, "");
-      $qfKey = CRM_Utils_Request::retrieve('qfKey', 'String', $form, FALSE, "");
+      if ($contribution['total_amount'] > 0) {
+        // Include eWay SDK.
+        require_once extensionPath('vendor/autoload.php');
+
+        $eWayAccessCode = CRM_Utils_Request::retrieve('AccessCode', 'String', $form, FALSE, "");
+        $qfKey = CRM_Utils_Request::retrieve('qfKey', 'String', $form, FALSE, "");
 
-      $paymentProcessor->validateContribution($eWayAccessCode, $contribution, $qfKey, $paymentProcessor->getPaymentProcessor());
+        $paymentProcessor->validateContribution($eWayAccessCode, $contribution, $qfKey, $paymentProcessor->getPaymentProcessor());
+      }
 
       return [
         'contribution' => $contribution,

Happy to submit a PR if you agree it's a good solution.

Warning after upgrade to wordpress/civicrm 5.72.1 re Deprecation Permission 'view payment tokens'

Wordpress: 6.5.2
CiviCRM: 5.72.1 (just upgraded and get the warning below now)
PHP: 8.1
MySQL: 8
eWay Recurring Payment Processor extension: 2.6.6

Warning error on any CiviCRM screen:

Deprecated: Permission 'view payment tokens' should be declared with 'label' and 'description' keys. See https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_permission/ Caller: CRM_Core_Permission::assembleBasicPermissions in mywebsite/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php on line 1129

Deprecated: Permission 'edit payment tokens' should be declared with 'label' and 'description' keys. See https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_permission/ Caller: CRM_Core_Permission::assembleBasicPermissions in mywebsite/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php on line 1129

Can anybody help me with this warning. It leads to 2 x warnings being displayed on every page displayed. Also I noticed that when I went to check the eWay payment processor CiviCRM would NOT display the configured record. Note: Once I commented out the line 1129 as per above it would display the eWay record. Have tested a live donation with the commented out code and it works currently.

Thanks in advance for your help.

Contribution is not handled when it is made from a webform.

We are using the updated code of this ext for one of our clients - and it seems the eway response is only handled for a contribution page and not when the payment is made through webforms? See https://github.com/agileware/au.com.agileware.ewayrecurring/blob/master/eWAYRecurring.php#L278

I've looked into the code to fix this and handled the response in a custom module using a webform hook that is called at the end of the process similar to what is processed by the ext when a civicrm thankyou page is displayed.

/**
 * Handle eway return on webform.
*/
function hook_preprocess_webform_confirmation(&$vars) {
  civicrm_initialize();
  $sid = CRM_Utils_Array::value('sid', $_GET);
  $accessCode = CRM_Utils_Array::value('AccessCode', $_GET);
  if (!empty($sid) && !empty($accessCode)) {
    module_load_include('inc', 'webform', 'includes/webform.submissions');
    $submission = webform_get_submissions(array('sid' => $sid));
    $contributionID = $submission[$sid]->civicrm['contribution'][1]['id'];
    $contribution = civicrm_api3('Contribution', 'get', [
      'sequential' => 1,
      'id' => $contributionID,
      'sequential' => TRUE,
      'return'     => array('contribution_page_id', 'contribution_recur_id', 'is_test'),
    ]);

    if (count($contribution['values']) > 0) {
      $res = CRM_Core_Resources::singleton();
      $ewayPath = $res->getPath('au.com.agileware.ewayrecurring');
      // Include eWay SDK.
      require_once $ewayPath . '/vendor/autoload.php';

      $contribution = $contribution['values'][0];
      $pp = CRM_Financial_BAO_PaymentProcessor::getProcessorForEntity($contributionID);
      $def = array();
      $par = array('id' => $pp);
      $ppObj = (array) CRM_Financial_BAO_PaymentProcessor::retrieve($par, $def);
      $paymentProcessor = new au_com_agileware_ewayrecurring('live', $ppObj);
      $paymentProcessor->validateContribution($accessCode, $contribution, $qfKey);
    }
  }
}

The above is working fine for us and do complete the transaction after returning from the eway site. Do you agree something similar should be handled within the ext to also support webform payments?

Also, I did some changes to the request params that we send to eway, eg country_id instead of country at https://github.com/agileware/au.com.agileware.ewayrecurring/blob/master/au_com_agileware_ewayrecurring.class.php#L302 and converting it into an iso code as done below that line.

Does this allow for credit card details to be updated by the card owner (contact) via the civicrm interface, eg the Contact Dashboard?

CronJob result is plain html of the front page for recurring eWay_Recurring payment cron job

/usr/local/bin/php73.cli ~/www/www/wp-content/plugins/civicrm/civicrm/bin/cli.php -u name -p "pass" -e Job -a run_payment_cron --processor_name=eWay_Recurring > /dev/null 2>&1

/usr/local/bin/php73.cli ~/www/www/wp-content/plugins/civicrm/civicrm/bin/cli.php -u name -p "pass" -e Job -a execute

My civicron.sh file has the above code which seems to be calling eWay_Recurring job , everytime it runs the Cron Job Result sent to my email address(as its configured in cpanel) is HTML of my frontpage.
When I check the logs it does not show anything related to cron job, but everytime cron is run, I get the full html.

Running 'master', missing eway libraries

Hi

I've tried to run 'master'. Am getting

Error: Class 'Eway\Rapid\Client' not found in au_com_agileware_ewayrecurring->getEWayClient() (line 131 of /Users/jrobens/Sites/colongwilderness

The composer.lock and composer.json look fine.

composer require eway/eway-rapid-php
composer install

Files exist anyway.

Any hints?

Background

I was on CIVIEWAY-10. Since been shown that the contact/memberships page doesn't display. Due to duplicated packages. Has been fixed in recent branches but is a fairly large change

[Mon Jan 28 16:58:16.928615 2019] [:error] [pid 20546] [client 127.0.0.1:61523] PHP Fatal error: Cannot declare class GatewayRequest, because the name is already in use in /Users/jrobens/Sites/colongwilderness15/web/sites/all/modules/civicrm/packages/eWAY/eWAY_GatewayRequest.php on line 40,

I'm trying the master as a result.

Additionally I could not get receipts with recurring payments to work on CIVIEYWAY-10.

File listing.

ls -R vendor/eway/eway-rapid-php/
CHANGELOG.md LICENSE.md README.md composer.json include_eway.php resource src

vendor/eway/eway-rapid-php//resource:
lang

vendor/eway/eway-rapid-php//resource/lang:
en.ini

vendor/eway/eway-rapid-php//src:
Rapid Rapid.php

vendor/eway/eway-rapid-php//src/Rapid:
Client.php Contract Enum Exception Model Service Validator

vendor/eway/eway-rapid-php//src/Rapid/Contract:
Arrayable.php Client.php Http HttpService.php

vendor/eway/eway-rapid-php//src/Rapid/Contract/Http:
ResponseInterface.php

vendor/eway/eway-rapid-php//src/Rapid/Enum:
AbstractEnum.php BeagleVerifyStatus.php LogLevel.php SettlementReportMode.php TransactionType.php
ApiMethod.php FraudAction.php PaymentMethod.php ShippingMethod.php VerifyStatus.php

vendor/eway/eway-rapid-php//src/Rapid/Exception:
InvalidJsonResponseException.php MassAssignmentException.php MethodNotImplementedException.php RequestException.php

Recurrings that fail still have their next payment date pushed out to the next cycle

per https://chat.civicrm.org/civicrm/pl/3ro58imtqpf3dnu1jdu35zotca

when the first 'attempt' to charge the card happens the next_scheduled_date is jumped forward by the relevant cycle even if the payment isn't successful. the processor then lets civi know it was a fail, and tries again, etc, etc and reports each fail till it gives up.

but meanwhile the next_scheduled_date is showing as 'next year', which means a bunch of reports etc get screwed up. Not hard to adjust them but it didn't make sense to me to have the 'next payment' date pushed out 'immediately' rather than waiting for a payment to succeed

and this also affects memberships, ie if the payment fails 3 times (or whatever the limit is) the associated membership seems to be still showing as auto-renew even though this has just failed its max times

Eileen commented that this might have been done to avoid double payments but 'we' now usually use the status to do that (there is a status 'Processing' intended for this use)

Latest version 2.4.1 breaks the site

Looks like the civix upgrade hasn't completed correctly. Updating this extension to latest 2.4.1 version breaks the site -

Fatal error: Cannot redeclare eWAYRecurring_civicrm_entityTypes() (previously declared in .../web/sites/default/civicrm/extensions/au.com.agileware.ewayrecurring/eWAYRecurring.php:301) in .../web/sites/default/civicrm/extensions/au.com.agileware.ewayrecurring/eWAYRecurring.php on line 561

If we remove eWAYRecurring_civicrm_entityTypes, there are other function errors like -

Error: Call to undefined function _ewayrecurring_civix_civicrm_xmlMenu() in ewayrecurring_civicrm_xmlMenu() (line 25 of /.../web/sites/default/civicrm/extensions/au.com.agileware.ewayrecurring/eWAYRecurring.php).
PHP Fatal error: Uncaught Error: Call to undefined function _ewayrecurring_civix_civicrm_alterSettingsFolders() in /.../web/sites/default/civicrm/extensions/au.com.agileware.ewayrecurring/eWAYRecurring.php:291

Error: Call to undefined function _ewayrecurring_civix_civicrm_managed() in ewayrecurring_civicrm_managed() (line 255 of /.../web/sites/default/civicrm/extensions/au.com.agileware.ewayrecurring/eWAYRecurring.php).

Replace calls to errorExit with throwing Processor Exception

ie https://github.com/agileware/au.com.agileware.ewayrecurring/blob/master/au_com_agileware_ewayrecurring.class.php#L624

and

https://lab.civicrm.org/dev/financial/-/issues/131

(It's pretty trivial to do - e.g https://lab.civicrm.org/dev/core/-/commit/c0bac359f666619465181d2f526d5f9b8748beb4
)

Does recur payments work via webforms?

Blog here mentions recurring payment to be working with drupal webforms.

From the README doc, webform recur payments seems to working as well

The eWay Transaction Verifications job verifies the pending transactions in eway. This is required for when CiviCRM is unable to verify the transaction immediately, for example if the end user does not press the Return to Merchant button or if the contribution was made via a Drupal Webform.

Visit civicrm/admin/job to enable eWay Transaction Verifications job.

I just tried adding an eway processor to a Drupal 7 webform with recur setup. The payment submitted via the webform is considered as a normal payment and no recur series is started for the amount.

Does this extension actually support recur payments via drupal webforms?

Recurring not taking recurring payment

I have installed and configured eWay recurring on my CiviCRM Wordpress site. The CRON jobs are running for the eWay Recurring Payments and eWay Transaction Verification jobs. Users make the initial payment OK when selecting the recurring option, however the subsequent payments are not being taken. The payment cycle is every 7 days. What should I be looking for to find out what is going wrong? I have fairly basic skills.

User deprecated function: Deprecated function CRM_Core_ManagedEntities::get, use api.

Lots of red error messages :(

Looks like is coming from here

au.com.agileware.ewayrecurring/eWAYRecurring.php

Line 213 in 5774d16

$paymentProcessorID = CRM_Core_ManagedEntities::singleton()->get('au.com.agileware.ewayrecurring', 'eWay_Recurring')['id'];

Sorry don't have time to do a full fix right now but looks like this needs something like:

$paymentProcessorTypes = \Civi\Api4\PaymentProcessorType::get()
  ->addSelect('id')
  ->addWhere('name', '=', 'eWay_Recurring')
  ->setLimit(25)
  ->execute();
foreach ($paymentProcessorTypes as $paymentProcessorType) {
  // do something
}

TokenCustomerID validation error when saving updated billing details for recurring payment

Steps to reproduce:

• Path 1:
  • Navigate to a contact who has an active (preferably test) recurring payment which uses the ewayrecurring payment processor
  • Click More -> Change Billing Details next to the recurring payment record in the Recurring Contributions tab
  • Click Add Credit Card
  • Add (test) credit card details in eWay
  • Click OK in the Civi dialog to update the credit card list
  • Select the new credit card and press Save
• Path 2:
  • Navigate to Change Billing Details as before
  • Select a previously-saved credit card
  • press Save

Symptoms:

On our Test and Production sites, both of these paths produce an ever-spinning triangle. When reloading the page, Civi displays a popup message "Error: TokenCustomerID Required". However, the selected credit card details do appear to have updated in the database (civicrm_contribution_recur.payment_token_id has changed).

Affected systems:

This happens on our production site and also a test site running a clean copy of Civi. In both cases the Civi version is 5.33.5 and the ewayrecurring version is 2.3.9.

Possible patch:

The behaviour seems to improve slightly (or at least it's different) after this patch:
AsylumSeekersCentre@fb0e1ce

Caveats:

With this patch in place, updating the billing details to use a previously-saved credit card (Path 2) now produces a redirect to eWay when pressing Save (but also seems to save the details, I just close the eWay window). Without this patch, this procedure produces an ever-spinning triangle but no redirect to eWay. I think the database is updated in either case.

Closing thoughts:

Is the issue simply cosmetic? Can we trust the saved token to work despite this error message? Are other sites affected or have I missed something in the setup of the test site?

Sending receipts for each recurring payment

Hi Justin - any opinion about this. we have a customisation for this but @konadave says there were a couple of places in eWay where is_email_receipt is explicitly set to FALSE/0, and setting it to TRUE/1 might be all it would take, and that presumably we could also add a setting for it on the settings form for eWay.

any thoughts? would you agree this is a valid solution and would you accept a PR?

Process recurring payment

No recurring payments have been processed since the introduction of this extension.

I can see the below job displayed on civicrm/admin/job?reset=1 page.

This seems to be calling run_payment_cron API to process the payments. But it looks like there isn't any api included in this extension? @agileware-dev Is there some changes that is yet to be pushed to this repo ?

Deprecated: Non-static method CRM_eWAYRecurring_eWAYRecurringUtils::getCustomerTokenFromResponse() should not be called statically

My extension version 2.2.12 .
I suggest we should fix this in latest version as well.
Should we use $this->getCustomerTokenFromResponse() ?

Log files filled with same log messages

seeing a lot of similar messages in the log files. With log viewer ext, this fills up the whole page -

Seems to be from https://github.com/agileware/au.com.agileware.ewayrecurring/blob/master/eWAYRecurring.process.inc#L53. I see most of the log statements are already commented in the file. Was this left out for any specific reason?

Update billing details for contribution link is blank

CiviCRM is currently 4.7.31

eWay_Recurring (au.com.agileware.ewayrecurring) 1.5.2
The template looks like it is loaded from here web/sites/all/modules/civicrm/CRM/Upgrade/4.6.10.msg_template/message_templates/contribution_online_receipt_html.tpl

The %1 link is blank in

You can update billing details for this recurring contribution by visiting this web page
How do we fix this?