sdk-dotnet
sdk-dotnet copied to clipboard
AuthorizeNet
Why is there no netstandard library for this API?
New issue created in hope that someone working on this API can give all of us an official response as to why there is no netstandard library for this API.
As you probably already know, any library for .net should be written for netstandard whenever possible. The benefit is to only write the library once and it can be shared across all .net environments/frameworks. Therefore the cost saving benefits for a netstandard library are pretty obvious.
Some folks in the github community have already ported this sdk-dotnet to netstandard2.0 by themselves. But this is not a solution for the community at large. An official - production ready - netstandard version of the API is required for compliance reasons.
We have been using Authorize.Net as a gateway on a few .net websites for many years. We are very familiar with Auth.net and appreciate its services, but we are also growing exceedingly concerned that auth.net does not seem to have much software development capabilities when it comes to their API. It is a bit frightening to see that they do not have yet a netstandard library already available and production ready. It is even more frightening to see that they did some work on creating one for netcore which has been in beta for many months). Why would they create a library using netcore? It does not make any sense at all and it looks like they do not understand the .net technology stack and how to use it. I am truly baffled by the lack of quality regarding this API.
A company of that size - specially in such a serious space as payment processing - should have this nailed many months ago for sure. But no, thus far they have no solution to this and they have not yet publicly communicated on when will they will release a netstandard library - if at all.
You would think that simply as a mark of respect for their many customers, auth.net would be more transparent regarding such an oversight on their part.
I just don't understand... don't know what else to say... it's nuts.
Hi @FredBell
Thank you for your inputs, kind words and continuous support. This is significantly helping us to prioritize and steer Authorize.Net to deliver incremental value to our developers community and Merchants.
As communicated on the other thread #162 .Net Standard work is in our backlog and will update soon on the release timelines !!
Thanks for your patience
Thank you for your response.
We are all looking forward to the day the netstandard version is released.
About the timeline for the release, can we hope to get the netstandard before the end of May 2019? And a production certified version 1 or 2 months after that?
We also hope the netstandard version will have the same API definitions as the current one. This will simplify future integration work and will make sure everyone uses the same netstandard version moving forward. Since at that point, the framework and core versions will become redundant.
I'm glad to see this getting some attention. It's a serious issue in an otherwise extremely nice API.
We are currently building our integration with Authorize.NET. I am very disappointed that there is still no netstandard.
I am going to have to write my own API wrapper now, which is going to take me time that I'd rather not spend compensating for the inadequacies of this library.
There really is no excuse for not making this SDK netstandard compliant, it doesn't fill me with any confidence in building a successful working relationship with Authorize.net. There is a reason that Stripe are dominating in this space, and you guys not offering adequate support for dot net developers is making it easy for them.
You have had an open issue for over 2 and a half years, it worries me that your development team don't understand that this is a priority.
@lxalln I 100% concur with you on this. I am extremely concerned about the lack of movement here.
I called support on this and basically got a non-answer. It's incredibly frustrating that they don't see this as a priority especially when it's fairly simple to get it working.
My customers are asking for Stripe integration, so I will probably head that direction instead of waiting on this.
I now have to write my own XML document just to use the API reliably (as their system can't handle real JSON, just their bastardized in-this-order version) - should I just go back to using DPM POST as an integration method?! This is 2020 - this lack of support, for want of what sounds like 4 lines of code, was understandable 5 years ago, I suppose. Not now.
@cdwiegand Few tweaks and you can make the current library compile under standard. I've been using it for a while now. They apparently are no longer going to support .NET or they just don't give a damn. I don't know which.
I thought I would share some light into this since I started this thread and I have some information which might be useful.
First let me say this - you might not like this information - if so - please do not blame me for it. I do not work for Authorize.Net - I simply use their services for my own business.
I talked to some Auth.net employees who told me this code on Github is not their code. They kind of support it a little bit but not really. The code is apparently written by various third parties and Auth.net think it is good enough to post here. I told them I thought this was deceptive to put this code here - as most folks thinks these are certified auth.net libraries.
Personally - after talking to Auth.net about this issue, I decided to build my own API using the official developer documentation on their website. Their documentation is in my opinion very good and it allowed to build a complete Json API. And I am very glad I did.
Making my own API I found that this old API was actually quite poor - both in terms of performance and code quality. I have now access to much better error messages in my new API. And it now follows .Net best practices around the use of HttpClient as well as for difference HttpException handling, etc...
Unfortunately - it took me quite a bit of time to write that API - so it will probably be the same for you. I also think it would have been better for Auth.net to offer a real "official" API for netstandard2.0 that would be of good quality.
So the bottom line is this:
- I would not wait for auth.net to offer a proper .Net API. It might happen one day - but I would not hold my breath for it.
- If you are not aware of the official Auth.Net documentation - please have a look at it - it is not bad.
- It is also very much possible to implement your own API for only the functionality you need - which is usually not that much.
That's it - I hope this will be useful to some of you.
Again - don't be mad at me if you do not like this information - I just thought I would share what I found...
Hah...good luck with that. It's amazing, isn't it?
On Wed, Aug 3, 2022 at 11:42 AM Jeff Mikan @.***> wrote:
Any update on trying a 4 year old beta into a release package?
— Reply to this email directly, view it on GitHub https://github.com/AuthorizeNet/sdk-dotnet/issues/263#issuecomment-1204126770, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGTUNNHGR7JZQ3ABFPFUL3VXKHNLANCNFSM4HEDYCSA . You are receiving this because you commented.Message ID: @.***>