(s2Member Pro) Bug fix. Authorize.Net® ARB. s2Member Pro was incorrectly handling scenarios where a Customer was attempting to create an ARB Profile with a credit card that expires before the 2nd payment in the ARB Profile would clear. s2Member Pro always collects the first payment up front, and starts the ARB Profile to handle future payments. In cases where a Customer's card would expire before the second payment is collected, the creation of the ARB Profile would fail on the Authorize.Net® side, and s2Member Pro was not recovering properly. The result is that the Customer was charged for the first payment, and then left with a decline notice on-site ( not good ). In this release, s2Member Pro has been updated to avoid the situation where a Customer may be declined, with the error The credit card expires before the subscription startDate. In this scenario, s2Member will now allow the Customer's transaction to go through ( collecting the first payment in real-time ), and allowing the Customer to gain access. In this case, s2Member knows that future payments will fail because the card will expire beforehand, so an EOT Time for the Customer will be set during checkout.
Statistics: Posted by Jason Caldwell — July 31st, 2011, 11:33 pm
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.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
Statistics: Posted by Jason Caldwell — July 27th, 2011, 5:11 pm
Statistics: Posted by bethperkins — July 27th, 2011, 6:57 am
Statistics: Posted by bethperkins — July 26th, 2011, 6:34 am
Statistics: Posted by bethperkins — July 25th, 2011, 12:06 pm