Alternatives to using AIM

[kschaller79]

We're in the process of re-designing our payment gateways (using Java) and one of the new requirements is to add Authorize.Net to the list of gateways for our clients. Typically our clients tend to have unusual requests or always in need of adding additional data. What seems to be the easiest approach for us is using NVP request strings because you don't have to write code for adding custom fields. In the case of Authorize.Net, the API is object based xml (or JSON) bindings, so each new additional field is a code change.

Is there a particular reason why Authorize.Net is phasing out NVP request strings? There still are gateways that support both XML and NVP. I know AIM use is highly discouraged for new solutions, but it fits within our current design. We will store custom fields the client can add in our database and we'd prefer to not code every possible optional field (which can be a lot for processor-specific fields). For instance, most clients are fine with the basic setup but 1 client will want level 2 and another will want level 3 card transaction support.

So I am looking for coding alternatives on how to handle this scenario otherwise I have a ton of hard coding to do and if statements to write if NVP is not the answer. I have seen some examples of using a HTTPS POST via Java sockets with a request string, but it was from 13 years ago. I'm not sure if that url is still active anymore without testing it.

[brianmc]

Hi @kschaller79,

The decision wasn't so much NVP or XML/JSON but more about reducing the number of APIs that we have to maintain/document/secure/etc.  We chose to move forward with the Authorize.Net API because it offered a complete coverage across all our functionality (AIM NVP is only for payment transactions, not customer profiles for example).    I can absolutely see the benefit of NVP for your use-case I will say that sometimes a very loosely typed API can be a little more difficult to debug and manage operationally.  Also, while this may not help a lot, it probably does make sense to increase the number of fields you always send and reduce the optional fields for clients (usually the more data you have the better - for example, to be a certified solution we have a set of fields that partners always need to send, over and above the required fields).  We try really hard to keep the API very consistent even across processors so perhaps there will be fewer special cases than you think (not downplaying the issue here, totally understand).

You could look at some kind of xml/json mapping/templating solution that would allow you expose that loose set of optional fields to clients but then drop them in to the appropriate object at runtime.

Lastly I would say that we welcome the feedback and we haven't completely ruled out the possibility of supporting some kind of flat structure as part of the new API (imagine REST API with URL-form-encoded input)

Hope this helps and feel free to explore further options on this thread,

Brian

[kschaller79]

Hi @brianmc,

Thanks for your response. I completely understand the reason for simplifying your APIs with an emphasis on a merchant-centric approach. We are a 3rd party vendor that processes mainly one-time credit card transactions for our clients (although sometimes they can be annual transactions). Unfortunately, we cannot scale back the amount of optional fields the client requests. Part of our new platform, which Authorize will be apart of, is to allow more customization that we were previously allowed to do with the current platform. It also sets us above our competition doing so (plus the headaches accompanied with it).

We will host our own checkout pages and store PCI DSS data in the event of service downtime. We also may use reporting and batch processing down the road, depending on client interest.

Since we mainly deal with one-time payment transactions, is it possible to use AIM in the short term until a REST POST query parameter string option were available? I'm trying to see what options we have. In that scenario, it would not be a major change to convert. Since it is a new service, we also have some flexibility in our timelines. 

We can use the existing API if needed (maybe field mapping + Java Reflection as a possiblity), but it keeps us limited to what we have coded at the time.

[brianmc]

Definitely you can use AIM in the short term, we will always support that method, so no worries there.  Only caveat is that in the future new features may not be fully supported in AIM.

Brian