Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Major
-
Resolution: Cannot Reproduce
-
Affects Version/s: 4.1.2
-
Fix Version/s: Unscheduled
-
Component/s: CiviMember
-
Labels:None
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Needs Funding
Description
Implementation to handle recurring + non-recurring membership signup
=========================================================
1. On configure contribution page - Memberships tab: check if selected price set provides option for user to select both auto-renew and non-auto-renew memberships. If so, check for valid processor and throw form error if any of selected processors don't support multiple payments in 1 call. Support for Auth.net and PayPal Pro initially.
"The membership price set associated with this online contribution allows a user to select BOTH an auto-renew AND a non-auto-renew membership. This requires submitting multiple processor transactions, and is not supported for one or more of the payment processors enabled under the Fees tab."
2. For online membership signup, if user selects auto-renew + non-auto-renew memberships, submit a separate payment transaction request for each (of corresponding type - subscription or simple payment).
NOTE: This means multiple contribution records are created and line_item rows are linked to the different contribution records (possibly a code change in line item creation).
NOTE: Ideally this can use the same codepath as we use when 'Separate Membership Payment' is checked (is_separate_payment).
— original post describing the problem —
create a membership type with renewing option required
create priceset and create a field that references this membership type
create a second field referencing a membership type that does not have auto-renew enabled
create a contribution page with this price set
with the above settings, the user could potentially select two memberships – one with auto-renew required and one without. when processed, the auto-renew membership is processed as if it were a one-time membership (i.e. the auto-renew function is never implemented).
it appears that the code isn't smart enough to process the auto-renew separately from the one-time payment. it is possible to have the dual payments with most processors, and we do support this in other configurations, so i don't think it's a limitation of the processor.