Document Support for CiviCRM from payment processors

I have in active development:

Payment processing feature page that cites the sponsoring payment processors
Individual payment processor pages similar to partner detail pages

In addition, I believe that we should:

Update the extension readme.md on extensions in gitlab
Update extension pages on c.o (for as long as these will exist)

changed the description

Thanks, @josh - looks great.

Thanks.

Here as some suggestions on how to better inform users of this arrangement:

Display a prominent notice on the CiviCRM Payment Processor configuration page in CiviCRM. This will notify new users, but not existing users. This should be persistent for any Payment Processor involved in the kickback program.
Display a System Status Alert and link to the page on civicrm.org with more details. This will notify new and existing users. This alert can be dismissed by the user, when required.

added comp:Payments label

added triaged label

@justinfreeman can you provide a link to the law in AU please?

Display a prominent notice on the CiviCRM Payment Processor configuration page in CiviCRM. This will notify new users, but not existing users. This should be persistent for any Payment Processor involved in the kickback program.

Do you mean that this should display for all users or just those based in the AU? If it's all users, then that feels problematic to me as such disclosure would not be necessary for a majority of users.

Display a System Status Alert and link to the page on civicrm.org with more details. This will notify new and existing users. This alert can be dismissed by the user, when required.

We'd be using an in-app alert system intended for technical alerts about their system to inform them of a purely financial arrangement with CiviCRM LLC. That doesn't seem like a good fit to me. It's inconsistent and it's arguably not necessarily "publicly" available to users (for sys admins, yes, but not everyone is a sys admin).

My opinion is that these in-app messages are unnecessary and probably will do less to inform the public than more prominent recognition w/ detailed explanation on public facing sites such as c.o, docs, etc. Likewise, the interface has enough stuff in it. Adding more, especially that doesn't seem necessary, doesn't sit right.

@josh the key objectives from my perspective are simple and two-fold:

Informed
Consent

CiviCRM users must be informed that this transaction is taking place, which needs to inform both existing and new users. The information needs to be clear and readily available. ie. it is not the responsibility of the CiviCRM user to "search for it".

CiviCRM users must be able to consent or decline their participation in this transaction. This could be achieved by having the provision to opt-out of this transaction and therefore their CiviCRM site would not send the tracking code to Stripe, PayPal etc.

Where "CiviCRM users" refers to those individual and organisations managing their CiviCRM site.

My email to you on 17 Feb 2021 included this link which has the explainer, https://hwlebsworth.com.au/referral-arrangements-and-secret-commissions-know-your-obligations-or-the-consequences-could-be-serious/ and the article being referred too for VIC is here, http://classic.austlii.edu.au/au/legis/vic/consol_act/ca195882/s179.html

Regardless of the legalities. I think that not having any sort of informed consent in place currently, is a problem.

I understand that that is the law in the AU, but that's not the case elsewhere, and that's what I'm trying to understand. Are you saying that this should be applied to all users? You may feel like all users must be informed, but others may disagree. I do, in fact. If it's the law in AU, then we should seek to comply. But I don't think AU law should extend beyond AU, so our obligation should end there.

While I agree that it's not the responsibility for the CiviCRM user to search for it, that doesn't resolve the point about who would see it in-app in the first place. Would all users need to see it? Would the organization's executive director? What if they don't have the permissions? I don't see where posting it in-app makes it any easier to find.

This seems like a technical solution that doesn't actually provide any higher probability of being read or noticed than public disclosure (which admittedly we don't yet have, ahem) on civicrm.org.

Let's not get into an argument about particular countries exporting their laws to other countries. That's definitely a beer conversation.

Why would you not want to inform and obtain consent from all CiviCRM users?

I do also want to be clear that the revenue share agreements have no impact on the fees associated with the payment processing. So, while I appreciate the idea of informed consent, it's a little odd to think they're consenting to something that has no impact.

Since I'm here (again), I'd highlight the legislation in the link you provided:

Under section 179 of the Crimes Act 1958 (Vic):

Whenever any advice is given by one person to another and such advice is in any way intended to induce or influence the person advised: to enter into a contract with any third person;… and any valuable consideration is given by such third person to the person giving the advice without the assent of the person advised the gift or receipt of the valuable consideration shall be an indictable offence5.

For the purposes of this provision the term “advice given” is defined as including any “suggestion intended to influence the person to whom the same may be made or given and every influence exercised by one person over another”.6

Similar provisions apply in New South Wales, Queensland, South Australia, Western Australia and Tasmania with the definition of “advice given” varying from state to state.

We're not advising, suggesting or otherwise influencing users in any way.

Why would you not want to inform and obtain consent from all CiviCRM users?

We do want to inform. I've listed the various public facing content we're actively working on. But what are we obtaining consent for? We don't ask for consent from clients of partners that pay dues or clients of providers that donate to MIH campaigns. Should we? Why?

I guess I don't understand what they're consenting to and therefore don't understand why we need to obtain consent. Again, I do believe we should inform and in fact celebrate/recognize the support we receive.

mentioned in issue marketing/civicrm-website#266 (moved)

I'll give this some more thought and get back to you later.

I've raised marketing/civicrm-website#266 (moved) as it's a similar sort of issue.

And just want to point out that I'm trying to find the right solution here too, just like you.

I know you are.

Recent updates:

Published blog post that highlights revshare agreements.
Published individual payment processing pages: Paypal, Stripe, TSYS, and iATS, all with disclosures.
Updated info.xml, readme.md and extension page for Stripe extension highlighting revshare, merged by @mattwire
Waiting for response from @KarinG and @andrewhunt for same (karin, andrew, check MM messages please)
Developed but not yet published "processing payments with CiviCRM" page as a specific feature page, includes disclosure of revshare agreement

To-do:

Complete and publish bullet 5 above
Complete disclosures in item 3 above

@justinfreeman are we at a point now where we can re-assess this issue please?

@josh great job on those points. And yes, I've opened up https://github.com/agileware/cf-stripe/issues/1 - this plugin has a short lifetime given the migration to Ninja Forms.

Recommend that you take time to reach out to the Ninja Forms team to raise the prospect of "revenue sharing" for the CiviCRM Ninja integration. Quay Morgan at Saturday Drive would be the best person to contact.

Once the "processing payments with CiviCRM" page is published and available in the main menu, then I think this issue can be closed.

mentioned in issue community/civicrm.org-website#19

Document Support for CiviCRM from payment processors

Child items ...

Activity