Answers.Body: <p>I'm not sure what exactly is your setup, but I can offer a couple of remarks.</p>
  <p>The project60 membership extension offers two different functions in that area:</p>
  <ol>
  <li><p>Assigning contributions to memberships, either individually (automatically and/or manually) or by linking a recurring contribution object (e.g. a CiviSEPA mandate) to the membership.</p>
  </li>
  <li><p>Extend the memberships' end date based on the assigned contributions, and therefore implicitly update their status.</p>
  </li>
  </ol>
  <p>You can use those functions separately, in particular if you have already solved/automated one of those steps in a different way.</p>
  <p>Does that help? The documentation you linked above has recently been improved and should be pretty extensive.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-22T10:23:49.413Z
Answers.Text: the function we need is only the first one. What is unclear is if we should create the membership with its related contribution and use the membership extension to change the status of the membership or if we should first create a recurring contribution paid with SEPA and use the membership extension to create or update a dedicated membership. Is that clear enough?
Answers.UserDisplayName: Guillaume Sorel
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-21T07:02:12.240Z
Answers.LastActivityDate: 2024-05-21T07:02:12.240Z
Answers.UserDisplayName: Björn Endres
Body: <p>We are working on a membership with automatic renewal (recurring payment) option that would be paid through SEPA payment processor. We've done many tests and reached the point where the payment of the contribution (status change from Pending to complete) updated according to CiviSEPA's normal process doesn't update the membership status, which stays stuck on 'pending'. This involves that every batch period (month for example) the initial contribution stays on 'pending' and a new contribution is created. The membership is hence not considered as completed.</p>
  <p>We've tried with a CiviRules and with the Projet60-Membership extension but it's not helping us that much.</p>
  <p>Following this documentation <a href="https://docs.civicrm.org/project60-membership/en/latest/automation/#configure-scheduled-jobs" rel="nofollow noreferrer">https://docs.civicrm.org/project60-membership/en/latest/automation/#configure-scheduled-jobs</a> I'm now wondering if and how the <code>Job.process_membership</code> could be in any help to achieve this.</p>
  <p>Other way to ask the question: is there a way to 'connect' CiviSEPA and a recurring membership?</p>
  
Tags: <civimember><civisepa>
Title: Job.process_membership and SEPA for recurring payments for membership
ThreadText: # Job.process_membership and SEPA for recurring payments for membership
  
  (Asked by: username_0 on 2024-05-17)
  
  We are working on a membership with automatic renewal (recurring payment) option that would be paid through SEPA payment processor. We've done many tests and reached the point where the payment of the contribution (status change from Pending to complete) updated according to CiviSEPA's normal process doesn't update the membership status, which stays stuck on 'pending'. This involves that every batch period (month for example) the initial contribution stays on 'pending' and a new contribution is created. The membership is hence not considered as completed.
  
  We've tried with a CiviRules and with the Projet60-Membership extension but it's not helping us that much.
  
  Following this documentation <https://docs.civicrm.org/project60-membership/en/latest/automation/#configure-scheduled-jobs> I'm now wondering if and how the `Job.process_membership` could be in any help to achieve this.
  
  Other way to ask the question: is there a way to 'connect' CiviSEPA and a recurring membership?
  
  **Tags:** civimember, civisepa
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-05-21. Score: 1
  
  I'm not sure what exactly is your setup, but I can offer a couple of remarks.
  
  The project60 membership extension offers two different functions in that area:
  
  1. Assigning contributions to memberships, either individually (automatically and/or manually) or by linking a recurring contribution object (e.g. a CiviSEPA mandate) to the membership.
  2. Extend the memberships' end date based on the assigned contributions, and therefore implicitly update their status.
  
  You can use those functions separately, in particular if you have already solved/automated one of those steps in a different way.
  
  Does that help? The documentation you linked above has recently been improved and should be pretty extensive.
  
  > **Comments:**
  > **username_0**: the function we need is only the first one. What is unclear is if we should create the membership with its related contribution and use the membership extension to change the status of the membership or if we should first create a recurring contribution paid with SEPA and use the membership extension to create or update a dedicated membership. Is that clear enough?  
  
  ---
  
  