Rank: Member
Joined: 3/15/2007(UTC)
Posts: 126
|
To all of our customers, clients and BV users,
We were notified this morning that Authorize.net has been down now for about 6 hours. From what I understand their facility was involved in a major fire and they are currently working to get everything backup and running.
Until they get their issues resolved we recommend all authorize.net user switch to manual processing in your site to still be able to receive orders. Just capture the payments after Authorize.net is back up and running.
I will post back here with more information as I get more information. |
|
|
|
|
|
|
Rank: Member
Joined: 3/15/2007(UTC)
Posts: 126
|
|
|
|
|
|
|
|
Rank: Member
Joined: 2/21/2007(UTC)
Posts: 1,113
|
Folks also want to remove any links to Auth.net seals and logos - it will slow down the load of the page |
|
|
|
|
|
|
Rank: Member
Joined: 3/28/2008(UTC)
Posts: 8
|
Does anyone have any tips for how to handle this sort of failure gracefully? We'd ideally like to accept the customer's order with an "On Hold" status in the case that Authorize.net is not responding. This would then allow us to process the payment manually as needed without having to reject the customer's order at time of payment (as was happening this weekend). I realize that it's possible to have the order workflow accept all declines, and I believe that's the default behavior until the workflow is modified as described in this tutorial. However, I don't know offhand if that works when there's no response at all from Authorize.net. More specifically, reverting to the original behavior of that workflow wouldn't suit our needs, since we don't want to start accepting all declines. For instance, we definitely want to display a message to the customer if they've used a declined card. We want them to have the opportunity to input a valid card during their time on the site rather than having our customer service people chase them down offline for a different card. Any and all ideas and input are appreciated.
|
|
|
|
|
|
Rank: Member
You have been a member since:: 11/13/2004(UTC)
Posts: 189
|
See if this works for you:
Admin>Options>Payment>Credit Card>Edit
Select:Authorize at Checkout, Capture Funds Later |
|
|
|
|
|
|
Rank: Member
Joined: 3/28/2008(UTC)
Posts: 8
|
Originally Posted by: "Rudy"  See if this works for you:
Admin>Options>Payment>Credit Card>Edit
Select:Authorize at Checkout, Capture Funds Later I'd considered that, but I don't think it fits our needs for a couple of reasons: 1. If Authorize.net isn't responding, will the "authorize" part of that even work? Wouldn't we still be getting errors? 2. We're looking for a long-term solution, and "Auth now, capture later" isn't a payment flow we'd want to employ all the time. If Authorize.net crashes again next month, we'd want our system to handle that failure automatically instead of needing us to change the settings after losing another 6+ hours of orders.
|
|
|
|
|
|
Rank: Member
You have been a member since:: 11/13/2004(UTC)
Posts: 189
|
If authorize.net is down the card will not authorize.
However the order will come through and you can capture
the funds later when they are running.
Depending on which version of BV you are using it will be
noted on the order as "Problem Order" or "On Hold" |
|
|
|
|
|
|
Rank: Member
Joined: 12/23/2003(UTC)
Posts: 909
|
If authorize goes down next month, the end all solution is that your system automatically switches to a completely different payment processor. I suggest tapping a developer for a stop gap solution to catch this.
I've had a few phone calls and emails about this authorize problem. For clients processing live, they're doing what Rudy has mentioned until it all clears up. Win some, lose some... |
|
|
|
|
|
|
Rank: Administration
Joined: 4/2/2004(UTC) Posts: 2,393 ![United States]( "United States") Location: Hummelstown, PA Thanks: 6 times
Was thanked: 163 time(s) in 158 post(s)
|
Ben,
If your payment gateway (i.e. Authorize.net) is down, you cannot authorize, capture or 100% validate a credit card. BV does perform several credit card checks before sending a card number to the gateway; it checks things like the starting numbers match the chosen card type (Visa, MasterCard, AMEX, etc) and that the expiration date is not passed. You can also require the CVV code at checkout which should defer some people with a stolen card number.
The only bullet-proof solution, as Matt mentioned, is to have a second payment gateway on standby. This seems like overkill given the infrequency of gateway problems. |
Aaron Sherrick
BV Commerce
Toll-free 888-665-8637 - Int'l +1 717-220-0012 |
|
|
|
|
|
Rank: Member
Joined: 11/6/2003(UTC)
Posts: 1,903
|
Having the second processor is the best option for true redundancy.
Aaron is right, for most merchants it is overkill, however for the merchants doing 6 digits plus a month it is VERY cheap insurance (about 300.00/yr)
When your site starts generating real revenue and you start to rely on its income, you need to eliminate as many single points of failure as possible. It is actually pretty easy to get redundant here, but it needs to be done in advance because it takes time to set the accounts up. |
Noah |
|
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.