I tested sepaPP today with PHP 8.1.11 and could not activate this extension on my CiviCRM 5.53.0 with WordPress 6.0.3.
Can anybody confirm this? CiviSEPA itself seems to work fine: Project60/org.project60.sepa#645

Starting with Release 5.69.0, CiviCRM supports the long awaited Smarty3 framework. Currently, Smarty3 support is optional, and can be switched off if extensions are incompatible. However, extensions should be updated soon, as it is announced that Smarty2 support will end during the lifetime of CiviCRM 5.69ESR.

If Smarty3 is activated, CiviCRM produces php errors when trying to access contributions:

[error] 
$Fatal Error Details = array:3 [
  "message" => "Unable to load template 'file:CRM/Admin/Form/PaymentProcessor/SDD.tpl'"
  "code" => null
  "exception" => SmartyException {#18831
    #message: "Unable to load template 'file:CRM/Admin/Form/PaymentProcessor/SDD.tpl'"
    #code: 0
    #file: "/html/wordpress/wp-content/plugins/civicrm/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php"
    #line: 195
    trace: {
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php:195 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php:232 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php:116 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Region.php:81 {
        CRM_Core_Region->{closure}
        › $smarty->assign('snippet', $snippet);
        › $html .= $smarty->fetch($snippet['template']);
        › $smarty->assign('snippet', $tmp);
        arguments: {
          $template: "CRM/Admin/Form/PaymentProcessor/SDD.tpl"
        }
      }
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Region.php:157 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Smarty/plugins/block.crmRegion.php:26 { …}
      /html/wordpress/wp-content/uploads/civicrm/templates_c/de_DE/86/f3/1d/86f31d4430e4332d43fa5209278976ff58db7744_0.file.snippet.tpl.php:79 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php:123 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php:114 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php:216 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php:232 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php:116 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Display.php:117 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Display.php:83 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php:203 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php:103 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php:355 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Utils/Wrapper.php:98 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:295 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:69 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:36 { …}
      /html/wordpress/wp-content/plugins/civicrm/civicrm.php:1231 { …}
      /html/wordpress/wp-includes/class-wp-hook.php:324 { …}
      /html/wordpress/wp-includes/class-wp-hook.php:348 { …}
      /html/wordpress/wp-includes/plugin.php:517 { …}
      /html/wordpress/wp-admin/admin.php:259 { …}
    }
  }
]


2024-01-21 12:16:45+0100  [debug] $backTrace = #0 /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(443): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /html/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException(Object(SmartyException))
#2 /html/wordpress/wp-content/plugins/civicrm/civicrm.php(1231): CRM_Core_Invoke::invoke((Array:4))
#3 /html/wordpress/wp-includes/class-wp-hook.php(324): CiviCRM_For_WordPress->invoke("")
#4 /html/wordpress/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters("", (Array:1))
#5 /html/wordpress/wp-includes/plugin.php(517): WP_Hook->do_action((Array:1))
#6 /html/wordpress/wp-admin/admin.php(259): do_action("toplevel_page_CiviCRM")
#7 {main}

There might be more Smarty3 compatibility issues. Hopefully, they are all of the same kind.

Hi,

I try to use a SEPA mandate as a way of paying for a membership registration of a club.

I use Wordpress (6.1.1) with CiviCRM (5.57.3) and extensions civiSEPA (1.8.0) and civiSEPAPP (1.1.0).

I configured a Payment Processor (PP) named "my SEPA Mandat" with Processor Type "SEPA Direct Debit".
Then I created a Contribution Page and added "my SEPA Mandat" as a PP.
I add a new Page in Wordpress with a shortcode [civicrm component="contribution" id="2" mode="live" hijack="0"].

Now when accessing the WP page it gets directly redirected to the main page (i.e. an error occurs). If I access the page when logged in I get the following warning:

This contribution page is configured to support separate contribution and membership payments. This SEPA_Direct_Debit plugin does not currently support multiple simultaneous payments, or the option to "Execute real-time monetary transactions" is disabled. Please contact the site administrator and notify them of this error

also in the log I get the following infos:

1155 | Mar 15 10:24:10 | [info] SepaPP: createPendingMandate had nothing to do
-- | -- | --
1153 | Mar 15 10:24:10 | [info] SepaPP: getPendingContributionID couldn't find a contribution ID.
1151 | Mar 15 10:24:10 | [info] SepaPP: createPendingMandate for contribution ID [] 

What is going on here, how can I solve the problem?

this is a follow up to #Project60/org.project60.sepa#611

Hi @lbl-knts. There's some stuff to unpick here.

The extension seems to differ if it's a one-time or recurring contribution.
Use case: a filled public contribution page with one-time contributions >creates a payment entry< within the contribution.
While having recurring contributions, the extension >does not create any payment< entry.

Yes, that's by design. Recurring contribution create a recurring mandate, which only generates a contribution when the transaction groups are generated. One-Off donations will only be collected once, so the contribution is created along with the mandate.

Any hints for what this differ?

Yes, you should maybe have a look a the documentation here: https://docs.civicrm.org/civisepa/en/latest/

If a recurring contribution wants to be made and it is - for example - set to "yearly" and there is no or an incorrect IBAN entered, the page is reloaded and the interval is reset to "monthly" (default). All the other information (such as name) is still saved so that user don't realise the change of the interval.

We had a strange situation where the memberships after batch validation were not updated and stayed empty without any membership join, date, end date. This had a major impact on the batches as the contributions were added every month again. After a long search it appeared to be related to the choice of the payment processor:

with the new one:

with the classical one:

If a recurring contribution wants to be made and it is - for example - set to "yearly" and there is no or an incorrect IBAN entered, the page is reloaded and the interval is reset to "monthly" (default). All the other information (such as name) is still saved so that user don't realise the change of the interval.

The NG payment processor doesn't seem to put the cycle day in a recurring mandate.

Actual behaviour:

The "new" SEPA processor throws an error during registration/payment on event page:

CRM_Core_Exception: Expected one Contribution but found 25 in /var/www/civicrm/pro/drupal/web/sites/default/files/civicrm/ext/org.project60.sepapp/CRM/Core/Payment/SDDNGPostProcessor.php on line 84

Exception trace

| Function | Location

0 | civicrm_api3() | /var/www/civicrm/pro/drupal/web/sites/default/files/civicrm/ext/org.project60.sepapp/CRM/Core/Payment/SDDNGPostProcessor.php:84
1 | CRM_Core_Payment_SDDNGPostProcessor::createPendingMandate() | /var/www/civicrm/pro/drupal/web/sites/default/files/civicrm/ext/org.project60.sepapp/sepapp.php:240
2 | sepapp_civicrm_postProcess() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Utils/Hook.php:275
3 | CRM_Utils_Hook->runHooks() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Utils/Hook/DrupalBase.php:73
4 | CRM_Utils_Hook_DrupalBase->invokeViaUF() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/Civi/Core/CiviEventDispatcher.php:310
5 | Civi\Core\CiviEventDispatcher::delegateToUF() | /var/www/civicrm/pro/drupal/vendor/symfony/event-dispatcher/EventDispatcher.php:251
6 | Symfony\Component\EventDispatcher\EventDispatcher->callListeners() | /var/www/civicrm/pro/drupal/vendor/symfony/event-dispatcher/EventDispatcher.php:73
7 | Symfony\Component\EventDispatcher\EventDispatcher->dispatch() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/Civi/Core/CiviEventDispatcher.php:260
8 | Civi\Core\CiviEventDispatcher->dispatch() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Utils/Hook.php:167
9 | CRM_Utils_Hook->invoke() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Utils/Hook.php:490
10 | CRM_Utils_Hook::postProcess() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Core/Form.php:599
11 | CRM_Core_Form->postProcessHook() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Core/Form.php:574
12 | CRM_Core_Form->mainProcess() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Core/StateMachine.php:144
13 | CRM_Core_StateMachine->perform() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Next.php:43
14 | CRM_Core_QuickForm_Action_Next->perform() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php:203
15 | HTML_QuickForm_Controller->handle() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php:103
16 | HTML_QuickForm_Page->handle() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Core/Controller.php:355
17 | CRM_Core_Controller->run() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php:319
18 | CRM_Core_Invoke::runItem() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php:69
19 | CRM_Core_Invoke::_invoke() | /var/www/civicrm/pro/drupal/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php:36
20 | CRM_Core_Invoke::invoke() | /var/www/civicrm/pro/drupal/web/modules/contrib/civicrm/src/Civicrm.php:88
21 | Drupal\civicrm\Civicrm->invoke() | /var/www/civicrm/pro/drupal/web/modules/contrib/civicrm/src/Controller/CivicrmController.php:80
22 | Drupal\civicrm\Controller\CivicrmController->main() | unknown:unknown
23 | call_user_func_array() | /var/www/civicrm/pro/drupal/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:123
24 | Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() | /var/www/civicrm/pro/drupal/web/core/lib/Drupal/Core/Render/Renderer.php:580
25 | Drupal\Core\Render\Renderer->executeInRenderContext() | /var/www/civicrm/pro/drupal/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:124
26 | Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() | /var/www/civicrm/pro/drupal/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:97
27 | Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() | /var/www/civicrm/pro/drupal/vendor/symfony/http-kernel/HttpKernel.php:169
28 | Symfony\Component\HttpKernel\HttpKernel->handleRaw() | /var/www/civicrm/pro/drupal/vendor/symfony/http-kernel/HttpKernel.php:81
29 | Symfony\Component\HttpKernel\HttpKernel->handle() | /var/www/civicrm/pro/drupal/web/core/lib/Drupal/Core/StackMiddleware/Session.php:58
30 | Drupal\Core\StackMiddleware\Session->handle() | /var/www/civicrm/pro/drupal/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php:48
31 | Drupal\Core\StackMiddleware\KernelPreHandle->handle() | /var/www/civicrm/pro/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:106
32 | Drupal\page_cache\StackMiddleware\PageCache->pass() | /var/www/civicrm/pro/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:85
33 | Drupal\page_cache\StackMiddleware\PageCache->handle() | /var/www/civicrm/pro/drupal/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php:48
34 | Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() | /var/www/civicrm/pro/drupal/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php:51
35 | Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() | /var/www/civicrm/pro/drupal/vendor/stack/builder/src/Stack/StackedHttpKernel.php:23
36 | Stack\StackedHttpKernel->handle() | /var/www/civicrm/pro/drupal/web/core/lib/Drupal/Core/DrupalKernel.php:718
37 | Drupal\Core\DrupalKernel->handle() | /var/www/civicrm/pro/drupal/web/index.php:19
38 | {main} |  

Entschuldigung, aufgrund eines Fehlers kann die Anfrage im Moment nicht ausgeführt werden. Bitte den Administrator oder Service-Anbieter kontaktieren und die Fehlermeldung sowie Details zur ausgeführten Aktion dafür bereithalten.

Expected one Contribution but found 25

Expected behaviour:

Event payments with SEPAPP NG should work as specified.

Translations for fields in the payment form are not effective.

After investigation, the textdomain used for localiztion is org.project60.sepa instead of org.project60.sepapp
Found in CRM/Core/Payment/SDD.php and CRM/Core/Payment/SDDNG.php.

It seems to not be possible to create a contribution for an organization. SEPAPP calls the default individual profile which creates a new individual and also comes with unnecessary mandatory fields like 'county' or 'other first names'.

So this is more or less a feature request to be able to use a custom profile with the desired fields and the ability to choose between individual / household or organization profiles.

(this was originally posted here: Project60/org.project60.sepa#676)

With the extraction of SEPAPP from the SEPA extension, the settings form for the payment processor settings got lost.
Currently the settings for hide_bic and hide_billing have to be entered manually into the table civicrm_setting.

It would be nice to have a settings form to enter these settings via the UI.

Or, as a simple alternative, these settings could be entered automatically into the database during installation of SEPAPP (since I cannot imagine any use case to change these settings):

INSERT INTO civicrm_setting (name, value, domain_id, contact_id, is_domain, component_id, created_date, created_id) VALUES ('pp_hide_bic', 's:1:"1";', '1', NULL, '1', NULL, '2021-04-09 11:07:08', '2');
INSERT INTO civicrm_setting (name, value, domain_id, contact_id, is_domain, component_id, created_date, created_id) VALUES ('pp_hide_billing', 's:1:"1";', '1', NULL, '1', NULL, '2021-04-09 11:07:08', '2');

With the option "pp_hide_bic", the display of the BIC input field is disabled.
However, the BIC still needs to be processed in the background. And if the BIC related to the IBAN entered with the payment processor is not found (because it is a new one, that is not already downloaded), an error message is displayed and the BIC has to be entered manually.

Since the BIC is deprecated within SEPA rules already since several years, it would be desirable to get rid of that functionality:
We would like to be able to deactivate BIC processing completely, and would not need the littlebic extension anymore. This would result in having/needing no BIC in CiviSEPA anymore.

We should have another option (e.g. "pp_no_bic") that would trigger that behaviour.

Since CiviCRM 5.61, update or creation of PaymentProcessors always crash with this message:

Couldn't find PaymentProcessorType [xx]

After investigation, it occurs in these lines of sepapp_civicrm_postProcess():

try {
                $pp = civicrm_api3("PaymentProcessor", "getsingle", array("id" => $pp_id));
                if ($pp['class_name'] = "Payment_SDD" || $pp['class_name'] == 'Payment_SDDNG') {
                    $paymentProcessor = civicrm_api3(
                        'PaymentProcessor',
                        'getsingle',
                        array('name' => $form->_submitValues['name'], 'is_test' => 0)
                    );

                    $creditor_id      = $form->_submitValues['user_name'];
                    $test_creditor_id = $form->_submitValues['test_user_name'];
                    $pp_id            = $paymentProcessor['id'];

                    // save settings
                    // FIXME: we might consider saving this as a JSON object
                    CRM_Core_BAO_Setting::setItem($creditor_id, 'SEPA Direct Debit PP', 'pp' . $pp_id);
                    CRM_Core_BAO_Setting::setItem($test_creditor_id, 'SEPA Direct Debit PP', 'pp_test' . $pp_id);
                }
            } catch (Exception $ex) {
                throw new Exception("Couldn't find PaymentProcessorType [{$pp_id}]");
            }
        }

If checked-up the exception, and the message return by $ex->getMessage() is:

Expected one PaymentProcessor but found 11

In fact, there is a breaking change on Contribution CiviCRM 5.61, particulary, this PR.

The name attribute is no more passed, the the PaymentProcessor can't be fetched.

(This is a copy of the issue Project60/org.project60.sepa#565 )
We have an event registration with a price set, where one option is free (amount=0.00), whereas another option is payable.

With the NG payment processor, CiviCRM throws an error:

Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
Expected one Contribution but found 25

The "old" payment processor works fine, as well as the PayPal payment processor.

This was reported on CiviCRM: 5.19.4 on Wordpress, CiviSEPA: 1.4
Should be verified with the current version CiviSEPA 1.5 and the (now separate) SEPA PP extension

Some time ago a very old bug in CiviCRM Core was fixed (I think there were, strictly speaking, several errors). Before these fixes the SEPA agreement was ALWAYS displayed in e.g. contribution forms, regardless of whether the direct debit payment method was selected or not (#4204 and #4189).

The bug fixes have now resulted in the agreement no longer appearing in some forms. I looked into this and it turns out that it depends on which “Payment Processor Type” is used when configuring a payment processor. With “SEPA Direct Debit” everything is fine, with “SEPA Direct Debit (NEW)” the agreement is not displayed. Unfortunately I haven't figured out why ... so I don't know if it's a Core-Issue or placed correctly here.

Using version 1.1dev and SEPA extension 1.6alpha2 shows this error:

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/allingro/testwpcivi/wp-content/uploads/civicrm/ext/org.project60.sepapp-master/sepapp.civix.php on line 260

It also showed up with version 1.5 of the SEPA extension and version 1.0 of the companion extension

Actual behaviour:
The classical SEPA payment processor creates a (wrong) financial_transaction record in the table civicrm_financial_trxn, at the time the mandate is entered. These entries are marked as "completed", and have a wrong payment method.

When the SEPA group is marked as "received", another financial_transaction record is created, with the correct values.

This creates severe problems for use cases, that are using the table civicrm_financial_trxn: e.g. CiviCRM invoices, accounting export.

The issue is only happening with OOFF payments, not with FRST/RCUR payments.

Workaround:

With the SEPA NG payment processor, this does not happen.
However, the SEPA NG payment processor currently does not support event payments (see #17)

It seems that the NG Processor doesn't truncate the source value, which now (with STRICT mode being the DB default) causes errors.