PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Authorize.net ARB

  1. Paperman
    Member

    Hi,

    I have everything set up and it seems to be working beautifully.
    My question is just because I'm not sure, let me explain.
    I have set up an authorize.net feed as a subscription ($6/month for the next 12 month).
    When a user signs up, I see the $6 charge in my authorize.net account but in the transaction details it says: "Recurring Billing Transaction: N"
    Additionally, there's an option in the transaction details to "Create ARB Subscription from Transaction".
    I just want to make sure that my subscription feed is set up properly even though in the authorize.net transaction details it doesn't appear to be getting these transactions as ARB.

    Thanks again for a WONDERFUL plugin.

    Posted 5 years ago on Monday January 7, 2013 | Permalink
  2. The first month is charged immediately upon form submission, so the recurring payments are adjusted to take that first payment into account. Does that explain what you are seeing?

    Posted 5 years ago on Monday January 7, 2013 | Permalink
  3. Paperman
    Member

    I guess and I'll find out in a month.
    Thanks!

    Posted 5 years ago on Monday January 7, 2013 | Permalink
  4. Please let us know if you experience any trouble. This is the way the system is designed to work.

    Posted 5 years ago on Monday January 7, 2013 | Permalink
  5. Paperman, I have the same question as you do, can you let me know if your recurring payment does come out automatically.
    Thanks,

    Posted 5 years ago on Saturday February 2, 2013 | Permalink
  6. tex77
    Member

    Can anyone explain WHY GravityForms handles ARB this way?

    I understand it's important to verify the credit-card in real-time, at the moment the ARB Subscription is created. But doing that with an AIM Capture transaction, and actually charging the initial payment via AIM (instead of ARB), causes two problems:

    1) This one initial payment will be separate from all the subsequent recurring transactions for the Subscription (in a different area of the AuthNet Merchant Interface, i think). And these must then be tied together, by some shared field, like an Invoice Number, Customer ID, or Email Address.

    2) Some ARB Subscription data will seem wrong. For example, a subscription purchased today (Feb 12), should have a Start Date of Feb 12, but instead ARB shows Mar 12. That's not really correct. GF shifts the Start Date because we already got the initial payment, so we don't want to charge for it twice. It might also confuse the number of occurrences. But this could be confusing for the merchant (and customer, if there's a client-portal on the site).

    Instead of these problems, why not just use the AIM Auth-Only transaction, to verify the credit-card at the moment the ARB Subscription is created. Then the first charge will be done -- by ARB, not by AIM -- the very next day (at 2pm PST).

    Just wondering about the benefit of the GravityForms approach, so I can explain the problems to my client.

    Posted 5 years ago on Wednesday February 13, 2013 | Permalink
  7. I'll bring this to the development team so they can share their thoughts.

    Posted 5 years ago on Wednesday February 13, 2013 | Permalink
  8. 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.
    I am not sure which direction we will take, but I will sure take your comment into consideration.

    Posted 5 years ago on Wednesday February 13, 2013 | Permalink
  9. tex77
    Member

    Hi Alex. Thanks for the insight about the strategy here. Two more problems i now see with this:

    Problem 1) The Start-Date in AuthNet is actually DIFFERENT than the Start-Date in the GF Entry.

    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.

    Problem 2) An annual payment cycle:
    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.

    Posted 5 years ago on Wednesday February 13, 2013 | Permalink
  10. I'll make sure Alex sees your latest comments. Thanks for continuing the dialog.

    Posted 5 years ago on Thursday February 14, 2013 | Permalink
  11. 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.
    Thanks for all the info.

    Posted 5 years ago on Thursday February 14, 2013 | Permalink
  12. tex77
    Member

    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.

    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).

    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.

    Posted 5 years ago on Tuesday February 19, 2013 | Permalink
  13. 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:

    "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."

    This sets up a dangerous situation that would facilitate donor fraud.

    Posted 5 years ago on Friday June 14, 2013 | Permalink
  14. stefanweise
    Member

    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!

    The error code customers keep getting:
    The credit card expires before the subscription start date. Please use another form of payment.

    Authorize.net has this listed in their documentation:
    API Error Code: E00018
    Error Code Text: The credit card expires before the subscription startDate.
    Description: The credit card is not valid as of the start date of the subscription.

    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

    Posted 5 years ago on Wednesday June 19, 2013 | Permalink
  15. 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.

    Posted 5 years ago on Wednesday June 19, 2013 | Permalink
  16. stefanweise
    Member

    @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.

    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?

    Posted 5 years ago on Tuesday July 9, 2013 | Permalink
  17. Richard Vav
    Administrator

    Authorize.Net Add-On v1.4 was released earlier this week.

    If require further assistance please open a new support ticket or a priority support ticket if you are a developer license holder. Thank you.

    Posted 5 years ago on Thursday July 25, 2013 | Permalink

This topic has been resolved and has been closed to new replies.