You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The text was updated successfully, but these errors were encountered:
Thanks for reporting. I don't think we ever used this scenario, but we also rarely use payment processors anyway.
Could you check if the (pending) contributions generated by the payment processor are properly linked to the membership? In general, maybe you could investigate what the differences between the two payment processors are on that area.
in this situation we shouldn't have the two unnecessary contributions with the 'pending' status. But because the membership is not updated, CiviSEPA adds them again to the batch.
I'm a bit wondering how you wouldn't use the SEPA payment to update a membership especially for recurring payments.
This 'issue' (maybe it's not a real issue) is really bothering our client because after the batch is validated, the memberships don't get updated and a new 'pending' payment is added to a batch.
How could this be improved?
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:
The text was updated successfully, but these errors were encountered: