Posted May 5May 5 I am trying to make sense of the Subscriptions system. I think it might be improved and simplified.Early PaymentsWhat is the thinking which allows members to pay their subscription early? I suggest that if their card details are on file, and the payment fails, they would enter a grace period where they would be invited to pay manually. At the end of the grace period, another attempt should be made for payment with the card on file. And if this fails, subscription services are then suspended/removed. (All automated, of course.) I can see the advantage of allowing early payments at a site like Invision, where non-payment (and suspension of services) impacts more than a single individual - none of us would wish to see our websites go offline because of payment glitch of some kind. So having the option to pay early makes sense. But in most cases, allowing early payments only adds potential confusion and complexity.CreditsIn testing, I allow for upgrades and downgrades, with pro rata refunds applied as account credits. But for credits to be applied to the account, I must also allow the member the option to manually add credits to their account. I think this is totally unnecessary in most situations. Yes, to account credits for refunds arising out of downgrades, but I fail to see the advantage of members being able to load up their account with credits they cannot have refunded (if they decide to leave; they are banned; I stop providing the product; etc.). Yes, I could potentially manually refund their card in such situations and/or provide in the ToS that no refunds of credits are possible in these situations, but I'd prefer to avoid this potential situation altogether.Default Payment MethodWhen a member pays early, they are presented with the option to pay using account credits, but the default is to pay by card. I note that if they do not pay early, and there is an automated payment, this will first use account credits and only use the card on file if there are insufficient credits. This is the correct way of doing this of course. But the default option being to use the card on file rather than account credits when paying early does not make sense to me and is contrary to the action taken during an automated payment. And I think it worth adding that option to instead use account credits during manual payment by the member is easily missed - I missed it during testing.In SummaryI think for most usual cases, Subscriptions could be simplified. No manual early payments; and no ability for members to manually add account credits. If these changes are made (or provided as admin options), the default payment method for prepayment not being account credit becomes somewhat moot (though, still applicable where/if pre-payment is still allowed).
May 5May 5 15 minutes ago, Como said:Early PaymentsWhat is the thinking which allows members to pay their subscription early? I suggest that if their card details are on file, and the payment fails, they would enter a grace period where they would be invited to pay manually. At the end of the grace period, another attempt should be made for payment with the card on file. And if this fails, subscription services are then suspended/removed. (All automated, of course.) I can see the advantage of allowing early payments at a site like Invision, where non-payment (and suspension of services) impacts more than a single individual - none of us would wish to see our websites go offline because of payment glitch of some kind. So having the option to pay early makes sense. But in most cases, allowing early payments only adds potential confusion and complexity.I'm not honestly sure what the suggestion is here? You can set any product so they can renew early from the "Client area settings" tab already. If the payment fails, it already informs the customer and tells them a payment must be made manually, and you can set a grace period for payments on the pricing tab. The only thing it wont do is to attempt to take a card payment again after its failed once.20 minutes ago, Como said:CreditsIn testing, I allow for upgrades and downgrades, with pro rata refunds applied as account credits. But for credits to be applied to the account, I must also allow the member the option to manually add credits to their account. I think this is totally unnecessary in most situations. Yes, to account credits for refunds arising out of downgrades, but I fail to see the advantage of members being able to load up their account with credits they cannot have refunded (if they decide to leave; they are banned; I stop providing the product; etc.). Yes, I could potentially manually refund their card in such situations and/or provide in the ToS that no refunds of credits are possible in these situations, but I'd prefer to avoid this potential situation altogether.If you go to Payments>Withdrawals, you can set up settings in which allow people to withdraw credit, based on rules you set
May 5May 5 Author 19 minutes ago, Marc said:I'm not honestly sure what the suggestion is here? You can set any product so they can renew early from the "Client area settings" tab already. If the payment fails, it already informs the customer and tells them a payment must be made manually, and you can set a grace period for payments on the pricing tab. The only thing it wont do is to attempt to take a card payment again after its failed once.Hi @Marc This is for Subscriptions, not a store product. Unless I am mistaken, 'Client area settings' exists only for products, there is no option to prevent the member from paying early in Subscriptions.19 minutes ago, Marc said:If you go to Payments>Withdrawals, you can set up settings in which allow people to withdraw credit, based on rules you setBut what I am suggesting is for members to not be allowed to generate credits in the first place. Allowing for the buildup of credit and subsequent withdrawal adds potential complications and refund fees. It seems unnecessary to allow this, but it is forced upon me (unless I am missing something).
