Refunds after 120 days without ECC: Suggestion

[inLeague]

For those of you who aren't aware, Authorize.net has cancelled the Expanded Credit Capability/"ECC" program that allowed for unlinked refunds. This was the only way to issue a refund after 120 days, since Authorize.net does not retain cardholder information for the original transaction past that.

ECC is a very old program and it frankly sounds like a terrible idea, particularly with security standards today. It has no requirement that the refund has anything to do with the original transaction, so there is an obvious problem with anybody who has access to merchant credentials having a lot of opportunity to misbehave.

Our use case is pretty different and I believe that there is a lot of possibility here for Authorize.net and its customers without any additional exposure to risk, and that is the use of the Customer Proiles feature to enable the option for refunds after 120 days.

In an ordinary, non-profile transaction, Authorize.net has got to save the customer credit card number for every transaction. They don't want to do this a second longer than they have to, which is why the 120 day limit is there. OK, no problem. But with a customer profile transaction, they don't have to save anything that they don't already have: the customer provided their card info in a secure manner and Authorize.net will hang on to it until the customer deletes it. 

The API already accepts the use of payment profile IDs to issue refunds. So why not carve out an exception that allows merchants using customer profiles to issue refunds for any period of time, so long as the payment profile is still active? If the customer deletes the profile, you wouldn't be able to do this; but if they don't, the argument that "we don't have the card info to issue a refund" just isn't true. There's not a lot of potential for abuse because the transaction is still a linked refund; you're not holding on to anything you weren't already going to hold on to; and you have none of the security problems of unlinked refunds.

We talked to your service department about this and the suggestion was 'escalated' but not taken seriously. They thought we were asking for something just for our account. We're not. We're asking for something for everybody's account, because the current configuration of refund options is based on assumptions from ten years ago and the use of ECC to resolve the problem. Both of those things should get a fresh look with all of the new tools that Authorize.net has added since then. We are happy to assist with this process as our customers (who are sports leagues for which people sign up 8-12 months in advance) are pretty grumpy about having to write hundreds of checks when refund time comes.

[mwh]

I think the best solution is to make the refund window longer than 120 days.  The current 120 window is way too short.  Many competitor gateways operate with a 365 day window.

I send in an idea to extend the window all the way back in 2017 in the Ideas section, and the only thing that happened was that it was changed to "Under Review".  

Make it a an add-on option and charge merchants an extra $10 a month for it.  I would gladly pay an extra $120 a year to not have to deal with card info.

[inLeague]

That is also a perfectly good option, but it doesn't really help the risk mitigation on Authorize.net's side. They don't want to keep card data past 120 days. Charging $10/mo to cover that risk sounds reasonable to me, but providing a mechanism that doesn't add to the risk in the first place seems better still.

[inLeague]

After a year of trying to navigate Authorize.net past 1st level support (who are super friendly but ultimately have no leverage) -- we are giving up on Authorize.net.

ECC is an ancient system that should be shut down, but it's impossible to get anybody to talk to about a replacement. Nobody will take ownership of any problems. It's your typical, giant finance company experience.

We are writing off the tens of thosuands of dollars we spent converting our software to use Authorize.net and starting from scratch with Stripe. Within the first week it was a better experience between the API documentation being consistent and modern and 24/7 support available on IRC. I wish I'd thought to go that route last year.