How QCMM Resolves Overlapping Promotions and Locks the Checkout Price

Explain that Promotions do not stack, the lowest eligible price wins, ordering resolves ties, and the accepted Promotion is locked into the purchase snapshot.

This guide follows the accepted QC Memberships & Meetings 2.0.21 implementation and applies to Max / All Access. This category follows the commercial path from checkout through payment, discounts, tax, Site Credit, invoices, receipts, refunds, and preserved billing history. When older walkthrough or project-manual wording conflicts with 2.0.21 source or later accepted Authorized-Domain behavior, the current implementation takes precedence.

Before You Begin

• Confirm the Plan is published and its price, currency, duration, renewal behavior, and customer-entered fields are correct before accepting live payments.
• Use PayPal Sandbox for payment testing and Live credentials only after the complete test path is verified.
• Record the expected Promotion, Coupon, Site Credit, tax, and invoice result before testing so each adjustment can be checked independently.

Current QCMM Behavior

Step-by-Step Workflow

1. Start from a published Plan or unpaid billing record and verify the displayed customer, currency, amount, discount, tax, credit, and balance.
2. Choose the available PayPal funding option and complete the provider flow in the intended Sandbox or Live environment.
3. Return through the QCMM-controlled payment flow and allow server-side capture/finalization to complete.
4. Check the billing/payment event and the subscription or standalone-invoice result.
5. Repeat with the same business rule only after correcting the exact failing layer; avoid creating duplicate payment attempts as a diagnostic shortcut.

How QCMM Resolves Overlapping Promotions and Locks the Checkout Price

Explain that Promotions do not stack, the lowest eligible price wins, ordering resolves ties, and the accepted Promotion is locked into the purchase snapshot is part of the current QCMM 2.0.21 behavior. Treat the stored QCMM record and server-side authorization as authoritative: frontend controls guide the user, but QCMM still validates identity, ownership/access, current object state, entitlement, and request integrity when an action is submitted.

Commercial records should be auditable after the sale. Price, discount, Coupon/Promotion, tax, credit, payment method/reference, due/paid state, and refund context belong to the billing history for that transaction; later Plan edits should not silently recalculate the past.

Current Details That Matter

• PayPal checkout is available on Basic+; optional PayPal, card, Venmo, Pay Later, and PayPal Credit buttons depend on PayPal availability and eligibility.
• Scheduled Promotions and Coupons are Max/All Access features. New coupons use first-payment behavior while historical recurring values remain preserved for old records.

How This Fits into QC Memberships & Meetings

This category follows the commercial path from checkout through payment, discounts, tax, Site Credit, invoices, receipts, refunds, and preserved billing history. A reliable QCMM configuration keeps Joomla authoritative for users, groups, access levels, sessions, mail transport, and Scheduled Tasks while QCMM owns Plan, subscription, billing, scheduling, Meeting, Custom Field, resource, and member-facing state.

For How QCMM Resolves Overlapping Promotions and Locks the Checkout Price, verify the behavior with the role that will actually use it. Administrator, member, Host, and Fulfillment Editor experiences intentionally differ. A successful test as Super User does not prove that a normal user has the correct ownership, access, timing, or feature entitlement.

Permissions, Entitlement, and Data Safety

• Joomla menu access, QCMM object ownership/access, role-specific permissions, and commercial feature entitlement are separate checks.
• QCMM re-authorizes state-changing requests server-side; never treat a visible or hidden frontend control as the security boundary.
• Do not expose PayPal credentials, encrypted settings, legacy keys, private room credentials, or other secrets in screenshots, URLs, public documentation, or community posts.
• Preserve subscription, billing, booking, attendance, Custom Field, credit, and entitlement history when correcting a problem; current QCMM is designed to repair in place rather than erase evidence.
• When Effective tier falls, premium configuration/history is preservation-first: features can become unavailable without deleting the saved data.

Verify the Result

• The amount captured or credited matches the final QCMM balance after discounts, tax, and Site Credit.
• The billing record retains the intended Promotion/Coupon and payment-method snapshot.
• A membership checkout activates or updates the correct subscription; a standalone invoice payment remains a standalone billing payment.
• The customer can see the appropriate paid/due state and Pay Now action in the frontend when applicable.

Common Mistakes to Avoid

• Testing Live PayPal credentials before the Sandbox path and return/capture flow are proven.
• Assuming every PayPal funding button is always available; PayPal determines eligibility for optional methods such as Venmo or Pay Later.
• Recalculating historical discount context from a Plan that has since changed instead of preserving the billing snapshot.
• Using an unrelated membership checkout to collect a standalone invoice balance.

Troubleshooting

• Separate account/guest activation, payment-intent creation, PayPal browser/popup policy, provider capture, and QCMM finalization into distinct checkpoints.
• Verify Sandbox versus Live credentials/environment before interpreting a provider error as a QCMM billing calculation problem.
• Reproduce the exact action with the smallest safe test and record the user role, Plan/subscription/booking/billing identifiers, current state, and time zone where relevant.
• If a control is missing, check Joomla access, QCMM permission/ownership, record state, Effective tier, and task health before assuming packaged files are damaged.
• If behavior is asynchronous, inspect the owning Scheduled Task and its last result instead of repeatedly performing the business action.
• After a correction, rerun the same scenario from the real frontend; a successful Administrator save alone is not end-to-end verification.

Operational Best Practice

Treat the billing ledger as history, not a scratchpad. Test commercial rules in Sandbox or with a controlled zero/low-risk path, reconcile provider and QCMM states, and use dedicated invoice/credit/refund actions so later support can understand exactly what happened.

Community Discussion

Want to compare membership or Meeting workflows, share practical QCMM tips, or discuss how other Joomla site owners use this feature? Visit the QC Memberships & Meetings Community. For private support, bug reports, account-specific entitlement or billing problems, or feature requests, use the QuantaCade support system.