Please Log in or Create an account to join the conversation.
As you've discovered a user isn't treated as expired for integration purposes until the grace period has ended. You can send an email exactly on their expiration date (or before/after) using CBSubs Mailer though if needed.Our plans have emails setup for awaiting payment, payment completed, renewal confirmation etc. Emails are triggered and delivered as these events occur. We also have an email setup for Plan Expiry. When a plan expires this “Expiry” email is not currently triggered. The plan shows as “expired” in CBSubs subscriptions. Question: What triggers the sending of the “Expiry” email? (Added: We now not that the plan show as "expired" on the actual date of expiry but the expiry email is not triggerred until the "grace period" ends, we can work with that.)
Don't understand what you mean by downgrade strategy, sorry. They should have no issues purchasing your other plans unless you specifically configured your plans to prevent that via conditions.(Note: at present we have not set a downgrade strategy, we see that we can set a downgrade from one plan to another using the Plan > Integrations > CB Fields area or in Auto Actions but we have not done this yet.) What is the recommended approach?
The basket and invoice are one in the same. Your admin is paying their basket incorrectly. They aren't paying the basket at all. They're simply renewing the subscription manually. They need to use CBSubs > Baskets and pay it there.However, we cannot see how an invoice is generated and made available to the member. Is an invoice available?
Stripe supports a couple of wire transfer payment methods and once we release a new build with the other payment methods I suppose you could look into using stripe to automatically handle wire transfer payments, but aside from that no.Is there some way this payment direct to our Administrator can be supported by the Subscriptions > Basket facility?
That should already be the case, but you can not utilize frontend registration while logged in. Your admin should be able to create those users from backend fine with full access to your various plans. Note in a lot of cases the access and condition checks are against the profile owner and not the user viewing the profile.Is there any way we can present the standard registration screen to the Administrator when she is logged on?
I don't believe so.We would like to present all plans, including some not public, on the standard registration screen to the Administrator while logged on with restricted plans presented based on her ACL access. Is this possible?
Not exactly a rule, but a timing issue. We do not keep passwords plaintext. So this means they're only plaintext during operations asking for them. So either during registration, during login, or during profile edit (if password was changed). Depending on what CBSubs email you're using and when it's sent will determine if the password is available or not. If sent during registration it should be fine. However, I suggest you stop sending password in emails all together.We note that in the Plans area emails and also in the CBSubs Mailer there is the option of using substitutions. We note that the substitution [Password] or [password] is permitted (and works) in some cases and not others, what is the rule?
Please Log in or Create an account to join the conversation.