https://legacy.forums.gravityhelp.com/topic/authorizenet-arb Gravity Support Forums Topic: Authorize.net ARB en-US Mon, 20 Apr 2026 02:53:59 +0000 http://bbpress.org/?v=1.0.1 q https://legacy.forums.gravityhelp.com/search.php https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-376055 Thu, 25 Jul 2013 06:01:35 +0000 Richard Vav 376055@https://legacy.forums.gravityhelp.com/ <p>Authorize.Net Add-On v1.4 was released earlier this week.</p> <p>If require further assistance please open a new <a href="http://www.gravityhelp.com/request-support/" rel="nofollow">support ticket</a> or a <a href="http://www.gravityhelp.com/priority-support/" rel="nofollow">priority support ticket</a> if you are a developer license holder. Thank you. </p> https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-370999 Tue, 09 Jul 2013 10:57:33 +0000 stefanweise 370999@https://legacy.forums.gravityhelp.com/ <p>@Alex Cancado: Any update as to when this might be fixed? We're still seeing this issue and customers are getting pretty ticked off about having their cards charged multiple times. </p> <p>Alternatively, the older version of your add-on worked flawlessly, but you guys have no changelogs or older version repository anywhere. Any chance i can get access to older versions of this add-on? </p> https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-332656 Wed, 19 Jun 2013 18:27:31 +0000 Alex Cancado 332656@https://legacy.forums.gravityhelp.com/ <p>We are aware of these issues and we are working on a new version of Authorize.net that will solve them. We have all the functionality done and are now testing it out. We should have it released soon. </p> https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-332401 Wed, 19 Jun 2013 14:07:00 +0000 stefanweise 332401@https://legacy.forums.gravityhelp.com/ <p>To repeat bartoncollege's issue above, we're now seeing the exact same problem happening with almost all ARB transactions processed by the authorize.net add-on and the latest version of GF. It looks like this has been happening since the release of 1.7.5. I can't find any version history or older version of GF to revert back to and i think this is a crucial issue that should be fixed ASAP!</p> <p>The error code customers keep getting:<br /> The credit card expires before the subscription start date. Please use another form of payment.</p> <p>Authorize.net has this listed in their documentation:<br /> API Error Code: E00018<br /> Error Code Text: The credit card expires before the subscription startDate.<br /> Description: The credit card is not valid as of the start date of the subscription.</p> <p>Authorize.net support has informed us that something isn't right in the way the form is processing the data and how it interfaces with their API </p> https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-323599 Fri, 14 Jun 2013 15:52:29 +0000 bartoncollege 323599@https://legacy.forums.gravityhelp.com/ <p>I'd like to throw this in for consideration as another issue for how ARB is currently handled by GF. We've got a third-party developer helping us customize a GF form, and they discovered the scenario below as a problem that could potentially occur:</p> <p>"We also learned about one other potential issue with subscriptions which is where the initial purchase succeeds, but subscription creation fails. In this case, it will also void the transaction. However, the user is left with an error on the form alerting them that something failed, but also they get an email saying the transaction succeeded when in fact it would have been cancelled. There is nothing we can do about that first email, as it comes from Authorize.Net. It might be possible to improve the message displayed, or to send another email explaining the situation. However, we believe that would likely require making some customizations to the Gravity Forms Authorize.Net plugin to enable this."</p> <p>This sets up a dangerous situation that would facilitate donor fraud. </p> https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-150406 Tue, 19 Feb 2013 18:14:13 +0000 tex77 150406@https://legacy.forums.gravityhelp.com/ <p>HI Alex. Thanks for taking this feedback into consideration. As your team brainstorms, I'd like to offer another ARB issue to consider -- how the AuthNet Feed specifies the Cycle for the entire form. </p> <p>Currently, all entries from a form must have the same Cycle (1 month, 12 months, etc). So the form can't have a field that allows the user to select the Cycle (and perhaps adjust the price accordingly, for a discount on annual subscription vs monthly). </p> <p>I used a hook to adjust the cycle, based on the value of my Payment Cycle field (radio-buttons for Monthly and Yearly). Alternatively, I think we could just use separate forms for each Cycle, and require the user to make that selection as a preliminary step, prior to seeing the main payment form. But that's a pretty awkward user-experience, and more confusing for the site-owner to setup and maintain. It'd be great if the cycle could be set by a field (perhaps a new field in the Pricing group), rather than the AuthNet feed. </p> https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-146938 Thu, 14 Feb 2013 11:35:09 +0000 Alex Cancado 146938@https://legacy.forums.gravityhelp.com/ <p>Yep. I do see how these inconsistencies can create confusion. I will be brainstorming this with the team and see if we can resolve them.<br /> Thanks for all the info. </p> https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-146887 Thu, 14 Feb 2013 07:58:18 +0000 Chris Hajer 146887@https://legacy.forums.gravityhelp.com/ <p>I'll make sure Alex sees your latest comments. Thanks for continuing the dialog. </p> https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-146653 Wed, 13 Feb 2013 15:01:24 +0000 tex77 146653@https://legacy.forums.gravityhelp.com/ <p>Hi Alex. Thanks for the insight about the strategy here. Two more problems i now see with this:</p> <p>Problem 1) The Start-Date in AuthNet is actually DIFFERENT than the Start-Date in the GF Entry. </p> <p>I know GF advances the Start-Date because the initial payment was already done (via AIM), and we don't want to double-charge that. And this new Start-Date value is sent to ARB, but the GF Entry is NOT also updated with the new value. So ARB shows 3/13/2013 while GF shows 2/13/2013.</p> <p>Problem 2) An annual payment cycle:<br /> Another issue related to this advancing of the Start-Date: if the Cycle is set to 12 Months (in the AuthNet Feed settings), then the new/fake Start-Date will be an entire year after the actual Start-Date. So an order placed today, on 2/13/2013 shows a Start-Date of 2/13/2014. This could cause even more confusion than a 1-month cycle, to anyone looking at the data for this subscription. </p> https://legacy.forums.gravityhelp.com/topic/authorizenet-arb#post-146603 Wed, 13 Feb 2013 12:45:31 +0000 Alex Cancado 146603@https://legacy.forums.gravityhelp.com/ <p>The initial motivation was to make sure the first payment was actually captured before the form was submitted. That would ensure that we could rely on that submission being paid for. However, since then we have had a few issues with this approach (and your point is valid), and have decided to implement a two step (Auth then Capture) when submitting the form. We are still testing this new approach, and I think a natural progression would be to clean up the way we split that first payment from the ARB, but this needs to be analyzed a bit more.<br /> I am not sure which direction we will take, but I will sure take your comment into consideration. </p>