topic API vs XML/SOAP for integration methods in Integration and Testing

API vs XML/SOAP for integration methods

smartk1977 — Mon, 12 Jan 2015 20:50:36 GMT

The sample SDK in location https://github.com/AuthorizeNet/sdk-java has given sample code using JAVA APIs. At the same time, the documentation under AIM/SIM/DPM/CPM has given xml guide or web services guide. Can we use JAVA APIs instead of XML/SOAP to integrated authorize.net?

Please let us know if there is any preference one has on others.

Re: API vs XML/SOAP for integration methods

RaynorC1emen7 — Tue, 13 Jan 2015 00:32:43 GMT

The API use XML, you can look at the source. Just make sure you tested everything you do with it before moving to production.

Re: API vs XML/SOAP for integration methods

smartk1977 — Thu, 15 Jan 2015 15:51:09 GMT

Thanks for clarification. In that case, I can happily use JAVA APIs and forget about SOAP urls (secure.authorize.net and api.authorize.net)

I am planning to perform the following steps to integrate AIM. Please confirm whether my process is correct:

Development

1) Create Sandbox account and obtain API Login Id and Transaction Key.

2) Use JAVA APIs (anet-java-sdk-1.8.1.jar) to integrate AIM. APIs use API Login Id/Transaction Key secured in a File/Data Base.

3) Execute code and confirm results in Sandbox Merchant interface.

Production

1) Create real Merchant account and obtain API Login Id and Transaction Key.

2) Replace previous values with production API Login Id/Transaction Key secured in a File/Data Base

3) Enable "Test Mode" in real Merchant account.

4) Execute code and confirm results in real Merchant interface.

5) Once I am comfortable, disable "Test Mode" and make it real.

Thanks for your time as this can be a guide line to many followers.

Re: API vs XML/SOAP for integration methods

RaynorC1emen7 — Thu, 15 Jan 2015 16:01:03 GMT

Everything except

Production

4) Execute code and confirm results in real Merchant interface.

When test mode is on, it is not going to create any transaction.

From http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Sandbox-Accounts-vs-Live-Accounts-Which-Does-What-Anyway/ba-p/9350

We also offer a Test Mode option on all live accounts which allows you to test connecting to the production environment.

Transactions that are run in the production environment in Test Mode are not stored anywhere and will return a transaction ID of zero. There will be no history of them. However, transactions run in the sandbox(without testmode) is available in the transaction history, which is another reason why a sandbox is the recommended method of testing.

Re: API vs XML/SOAP for integration methods

smartk1977 — Thu, 15 Jan 2015 20:58:49 GMT

Thanks for the artcile that clearly explains everything. This talks about changing the posting URL from the sandbox URL to the production URL. I understand that this is required If we use SOAP.

Since I am using JAVA API should I pass any information to methods to switch sandbox to production? If not, does APIs know which environment to call with just API Login ID and TransactionId? So far I am only testing on sandbox and so everything works as epxected.

Re: API vs XML/SOAP for integration methods

RaynorC1emen7 — Fri, 16 Jan 2015 00:19:18 GMT

When you

    Merchant merchant = Merchant.createMerchant(Environment.SANDBOX,
        apiLoginID, transactionKey);

the enviroment would set to the production for the production account.

Re: API vs XML/SOAP for integration methods

smartk1977 — Mon, 19 Jan 2015 18:34:42 GMT

I got it, although u meant the code needs to be

Merchant merchant = Merchant.createMerchant(Environment.PRODUCTION,
        apiLoginID, transactionKey);

I replaced SANDBOX with PRODUCTION