Thanks for reporting this important issue.~ and thanks for your patience too.bethperkins wrote:I submitted a problem earlier because the Authorize.net subscribe function was giving customers refusals when they tried to use a credit card with an expiration date that is prior to the date of their subscription renewal. Our customers sign up for a one year membership.
I'm now more worried because I think that Authorize,net approved the first transaction (the AIM transaction) and then refused to create the membership because the ARB transaction failed.
S2Member does not show the refused memberships in the user list but my client is saying he sees the money and names in his reports on Authorize.net.
Could this be the case? This would be very bad from a customer stand point and we need to get back to them asap if this is true. Can someone please explain how authorize,net ARB transactions are handled???
Beth
Thank you. I understand. Well, the first charge is processed NOT through an ARB Profile, but with a Direct Pay transaction. This ensures the first payment is always authorized/captured in real-time during checkout. Then, remaining future payments are associated with the ARB Profile, and this is why you see the Start Date in the future
( that's the intended behavior ). This is the best approach, because we've been down the other road with s2Member in the past, and there are several other problems that can arise when the very first payment is handled by the ARB Profile.
All of that being said. I DO understand the problem that you're reporting, and I'm going to have a look now to see if there is something we can do to improve/prepare s2Member for this scenario and recover gracefully, or even based on configuration of your Shortcode.