Issue with recurring memberships

[allinappliadmin]

We're are struggling to create a recurrent membership plan paid with CiviSEPA(pp). After lots of reading (documentation, SE) and testing (civirules, membership extensions...) and opening issues, I think we've identified this issue (except if this is a global misunderstanding from our part).

Actual behaviour
When the Membership is set on recurrent and payment managed with SEPA, there is a hole in the process between membership, contribution and SEPA mandate: when the mandate is closed and marked as received then the contribution status switches from pending to completed BUT the membership status stays on pending i.e is not updated. This means that the membership entity will 'ask' for a new SEPA contribution in the next batch even though the contribution has been really received and is completed. This results in having for one single term of the membership a completed contribution and a pending contribution created by the membership entity that stays on pending. And this unnecessary pending contribution will be created by CiviSEPA and added to the next SEPA batch.

Expected behaviour
We've tested exactly the same process with a credit card payment with Stripe processor and once the contribution is marked as completed the membership 'receives' the information and also switches to completed, until the next period when a new payment will be submitted to Stripe.

I'm maybe discovering cold water but what fails until now, is the update of the status for the membership once CiviSEPA has updated the status of the contribution. In other words, the synchronization between SEPA and contribution works, but not the one between Contribution and Membership

[bjendres]

Thanks @allinappliadmin for your post.

The integration of CiviSEPA with memberships is what the https://github.com/Project60/org.project60.membership extension is supposed to do, as mentioned in the readme. However, that does not follow the payment-processor approach, and rather connects recurring contributions (like SEPA mandates) to the membership. But it also allows "payment synchronisation". i.e. assigning certain contribution types to memberships, so you can use the same framework.

If you want to continue with a payment-processor approach, you'd probably have to fix/implement this in the SEPA payment processors (https://github.com/project60/org.project60.sepapp and https://github.com/systopia/de.systopia.sddpp), which we're not using ourselves.

[allinappliadmin]

ok thanks Björn, at least it's clearer for me now what I can/can't do with the state of the art. I'm also testing with CiviRules which could fill the gap we've identified.

[Detsieber]

You might look deeper into project60.memberships: This extension will: 1) connect completed payments (contribution) to the corresponding memberships 2) recalculate membership statuses You will find some documentation here: https://software-fuer-engagierte.de/sites/default/files/document/20230911_CiviCamp2023_CiviMember%20bei%20Digitalcourage.pdf Message ID: ***@***.***>

[allinappliadmin]

thanks @Detsieber for the tutorial!