If you’re a Stripe or Paypal customer you may have had received communications around the Strong Customer Authentication (SCA) requirements.

Although the changes are pertinent, the SCA requirement has been delayed in the UK until 2021.

Stripe among other payment processors, have continued to indicate that their clients must update their systems to comply with the SCA regulations stating that failure to do so could result in declined payments however, having contacted Stripe they have confirmed that the enforcement is not going to take effect for British cards. However, if there are European card payments from outside the UK where there is no enforcement delay, then this may lead to declines.

Veda NFP Consulting is working with the CiviCRM community to update payment processors to comply with this regulation with the aim of having an update to the payment extensions within a few weeks, an updated CiviCRM Stripe extension was released on the 13th of September 2019 and we are in the process of evaluating the new version.

More information from the FCA here


CiviCRM online registrations / signups in wordpress are generally hit by session / qfkey errors, and are more common in wordpress than drupal. There is a list of incompatible plugins listed on the CiviCRM docs site –

We experienced this issue and now would like to share our findings with you in this post.


Open a CiviCRM event registration page in one browser, no details are completed, hit submit – throws an error, which is expected.

Open the same event registration page in another browser, again don’t compelte any details, hit submit => does not throw any errors, just refreshes the page OR throws invalid session key error OR if used with a shortcode gives id not found error.


If we look at the source code of a page in the second browser, the hidden qfKey element is ppopulated with qfKey from the first browser. Which is wrong because browsers would have their own different session key producing the separate qfKeys for civi. When we looked at the code, the code was correctly producing the new qfKeys, but html was producing different (stale) qfKey, causing invalid session key errors. Concluding that the page is getting cached somewhere.

We tried disabling all the cache plugins, and / or setting up cache plugins and adding exceptions for civi pages, which didn’t seem to work for our case.

There were some php save-path errors as well (php v5.6 on plesk), but resolving them didn’t solve our issue.

We started looking at theme, and found that the custom theme was using Timber which was caching the pages. (Timber helps you create fully-customized WordPress themes faster with more sustainable code. With Timber, you write your HTML using the Twig Template Engine separate from your PHP files.)

Specifying a small cache timeout with Timber solved the problem.

Conclusion / findings:

Disabling caching with Civi front end forms would resolve most of the session key errors with wordpress. It looks as though if we can automate and compare the qfkey generated by html vs code, this problem can be resolved quickly.

So, whats causes a page to cache? If its not wordpress, then it looks like a plugin or theme.

We hope you find this blog useful and that it will save you some time to troubleshoot this issue. Do leave us a comment below if you have any feedback!

GDPR and CiviCRM

Our new extension aims to enable charities/organisations to manage their supporters in a GDPR compliant manner. GDPR in itself does not introduce many new requirements however it does introduce a number of new obligations on organisations that hold and use data about individuals.

It’s important to understand that simply moving to an opt in process and regarding all existing contacts as being opted out overnight is probably not what is best for your organisation.  There are many factors to consider before determining whether to base your marketing contacts on an opt in . For example a membership organisation is likely to be well within its rights to base member communications on the organisation’s ‘legitimate interests’ unless the member explicitly opts out. You may also be able to import contacts from third party fundraising systems, where they have already stated that they are happy to be contacted by the charity they are fundraising for. The overall aim of this extension is to help organisations navigate the journey to GDPR compliance without compromising their presence with and income from their existing supporters.

Under GDPR, therefore, you need to be able to record whether your contacts have given consent to receive marketing.  If so, you must be able to show who consented, when they consented, how the consent was given, and exactly what the consent is for (including for which communications channel – post, email or phone, for example).

If you have not asked them to provide consent, your marketing would be based on ‘legitimate interests’.  In this case you must record any contact from them asking not to receive marketing, or specifying which marketing they do not want to receive.  You should also be able to show that your legitimate interests are not outweighed by their interests.  If people don’t respond to your communications over a period of time, the longer this goes on, the harder it might be to argue that you still have a legitimate interest in contacting them.

More details about GDPR and CiviCRM can be found at

The current version of this extension does the following;

  • Allow you to record the data protection officer for your organisation
  • A new tab ‘GDPR’ in contact summary will display group subscription log for the contact
  • Custom search ‘Search Group Subscription by Date Range’ which can be access from GDPR Dashboard
  • Access list of contacts who have not had any activity for a set period of days from GDPR Dashboard
  • Ability to force acceptance of data policy/terms and conditions when a contact logs in and recording this as an activity against the contact with a copy of the terms and conditions agreed to. This is currently Drupal specific.
  • The right to be forgotten, allowing users of CivicRM to easily anonymise a contact record, hiding any person details but keeping the financial and other history. The action also exists as an API and therefore can be bolted into other processes.

Future releases will include

  • User friendly communication preferences, moving to explicitly worded opt in mechanisms.
  • Communication preference to include medium per group. Currently CiviCRM supports include or exclude from a group but it does not allow for the selection of the communication medium that should be used for example happy to receive email newsletters but please don’t send me any other emails.
  • Recording audit information when a contact is exported
  • Allowing all exports to be produced with passwords if produced with the MS Excel Extension.