CiviCRM Community Forums (archive)

I have the following set up, which is working:   A number of membership types which are set as "require auto-renew" and a duration of monthly.  The payment processor is Authorize.net.  So when someone joins as a member via the CiviContribute page associated with these auto-renew membership types, everything works as expected.

However, sometimes real-life is not neat and tidy: Someone joined as a member, and the first 6 months the credit card transactions were processed by Auth.net and the results sent to CiviCRM. So for the first 6 months the membership was extended by one month for each new transaction.    On month 7, the credit card failed.  As a result no contribution showed up in CiviCRM and the membership went into "expired" status.     At this point, the bookkeeper called/emailed the member and requested a new credit card to cover member dues for month 7 and beyond.  Once the bookkeeper has the new credit card, how can they re-activate the membership so as to not lose the continuity of the membership period?

No I did not.

My understanding is that will only trigger a one-time credit card transaction.  It will not create a new "subscription" ie automated recurring payments with the payment processor.

Is this correct?

On month 7, the credit card failed.  As a result no contribution showed up in CiviCRM and the membership went into "expired" status.

The correct behaviour here is a bit disputed - I'm of the camp that says a contribution should be created but the status should be 'failed'

Just some more thoughts on this but if it is paid by CC then is there even a way to do this currently?  It would imply that the CC be stored for future usage?  That would be a PCI-compliance issue all to it's own.  Not sure there is a solution that requires CC storage.  Would there be a way to set this up for the CC processor to store and so forth?  Seems like that is the side that needs to store the CC info else CC has to be encrypted from my understanding.  Could a dev tell us if a CC is even stored in the first place or if CC recurring is even possible and if so is there a specific processor that must be used?

Hmm, and a manual transaction using the same card and Authorize.net works?  And I am also assuming the CC hasn't changed or expired correct?  So just to be clear the payment just failed to process based on the auto-renew system in Civi? Sorry just trying to be clear and hopefully provide some form of help.

NASACT -

The reason the card failed is because of an issue with the card itself. CiviCRM is not causing the failure.    I am not trying to avoid the failure, as cards can start failing for a variety of reasons beyond the non-profit's control. ( such as person has spent more than their credit limit, card was stolen and then replaced by the bank, etc. )

What I am trying to get a handle on is: How the bookkeeping staff should react after they have called their member and received a new card number to cover an auto-recurring membership.

If the same situation occurred with an automated contribution set up in CiviCRM, there is no issue. The bookkeeper can simply click "Submit a credit card Contribution" on the contact's contribution record, and then set up a new automated recurring credit card contribution.   The fly-in-the-ointment in the case of auto-recurring membership, is there does not seem to be any way to create a brand-new auto-recurring membership in the back-office.

Sarah, I enter the database via PHP My Admin to edit memberships in these cases.  It works ok.  I am using 3.4.8 and Paypal Pro.  Supposedly in future versions, 4.1 or 4.2 there will be a more robust feature set for editing auto-renewing memberships if Paypal pro is the processor.