Reply
Posts: 300
Kudos: 51
Solutions: 35
Registered: ‎03-13-2017

API / Features documentation

[ Edited ]

Use the features you want to build the payment solution you need.  

You'll be up and running in minutes.

 

 

Features :  https://developer.authorize.net/api/

 

SDKS :      https://github.com/AuthorizeNet

 

API reference :  https://developer.authorize.net/api/reference/index.html

 

Response Code :  https://developer.authorize.net/api/reference/responseCodes.html

 

 

Follow me at

https://twitter.com/anuragg29

https://www.linkedin.com/in/anuragg



Send feedback at developer_feedback@authorize.net
Member
Posts: 2
Registered: ‎01-03-2018

Re: API documentation

I see that there is a schema definition one can use to pull fields. Is there a way to pull say a "custom" schema in which if custom fields were created for a particular instance and the schama can be parsed? 

 

Apologies if this is confusing and I can clear it up if I need to. Rather new here. 

Two APIs I'm using are in the transaction reporting (getSettledBatchListRequest & getTransactionListRequest).

 

Thanks in advance! 

Posts: 300
Kudos: 51
Solutions: 35
Registered: ‎03-13-2017

Re: API documentation

Hi @bsknowlton1

 

Will need more details on it ?

 

Also are you using our SDKs for calling the mentioned APIs ?

 

https://github.com/AuthorizeNet 

Follow me at

https://twitter.com/anuragg29

https://www.linkedin.com/in/anuragg



Send feedback at developer_feedback@authorize.net
Member
Posts: 2
Registered: ‎01-03-2018

Re: API documentation

Appreciate the quick response. I'm not using any of the SDKs. Building one of my own on Ruby with limited functionality.

 

Details, I'm doing a integration/transformation on the two methods above. The details in the documentation specify a concrete/static set of fields on the response, but was wondering if there could be custom fields returned and how I'd be able to get those fields on the fly. 
** To note, I need to build the object definition for the end user to be able to transform and map across another system. So if a field isn't in the definition it won't show up.

 

Thanks again! 

Posts: 300
Kudos: 51
Solutions: 35
Registered: ‎03-13-2017

Re: API documentation

Hi @bsknowlton1

 

We will not send any other custom fields for these APIs other than what is documented in the XSD for it . 

 

Any reasons for not using our SDKs for it ?  it will be much easier for you .

 

Thanks

 

Follow me at

https://twitter.com/anuragg29

https://www.linkedin.com/in/anuragg



Send feedback at developer_feedback@authorize.net
Contributor
Posts: 12
Registered: ‎03-05-2018

Re: API documentation

The  API Reference seems not to include a reference for the In-Person Payments. Where would I find that, please? Searched all over your site, googled, no luck :-(

 

Thanks for helping!

Posts: 300
Kudos: 51
Solutions: 35
Registered: ‎03-13-2017

Re: API documentation

Hi @ohoppe

 

Have you seen the inperson feature page at https://developer.authorize.net/api/reference/features/in-person.html 

 

Hope it helps .

 

 

Follow me at

https://twitter.com/anuragg29

https://www.linkedin.com/in/anuragg



Send feedback at developer_feedback@authorize.net
Contributor
Posts: 12
Registered: ‎03-05-2018

Re: API documentation

Hi Anurag

 

Thanks a lot for your reply!

 

When clicking on the link it says, "Page Not Found". The only documentation I found was this page and the pages it refers to. But this is not thorough developer documentation as you find it e.g. on this API Reference page. And the documentation that comes with the In-Person SDK for Android is also nowhere near that thorough. In fact, when following the instructions given with the In-Person SDK it wouldn't work. The best "documentation" available so far is the sample app, but that doesn't explain the background (like that you seemingly cannot run this in a Background Service but need an Activity because the SDK will add their own Actvity e.g. for signature capture) nor does it provide details on the available classes, functions and their parameters etc.

 

All in all a very disappointing experience so far with this In-Person SDK for Android. Tried 3 different Android tablets with different (recent) Android versions and it would not work. You have no choice of hardware and the provided hardware only works (or tries to work) with the Audio plug which is apparently not well supported (yet) by computing devices for data transfer. And you cannot use it with a desktop PC running Linux which is not so uncommon in the POS world. And you seemingly cannot customize the UI or integrate it with your already existing UI. And the documentation is apparently lacking, far behind the API Reference.

 

Would have expected better from Authorize.net.

Posts: 300
Kudos: 51
Solutions: 35
Registered: ‎03-13-2017

Re: API documentation

Hi @ohoppe

 

Thanks for your feedback . We have provided these inputs to the concerned teams . 

 

The in person SDK readme file do have a section on using without UI . 

 

 

https://github.com/AuthorizeNet/inperson-sdk-android#quick-chip-in-the-background

 

Below is a list of devices that Authorize.Net has tested and confirmed works with our mPOS Mobile Application/VPOS v2 Application and supported secure card readers. These readers support additional devices that Authorize.Net has not tested, but may work as well. Authorize.Net does not guarantee all device compatibility.

 

https://support.authorize.net/s/article/Authorize-Net-mPOS-Mobile-Application-VPOS-v2-Application-Te...

 

Also we will be launching the Chipper 2X BT pretty soon .

 

Hope it helps !!!

 

Thanks

Follow me at

https://twitter.com/anuragg29

https://www.linkedin.com/in/anuragg



Send feedback at developer_feedback@authorize.net
Contributor
Posts: 12
Registered: ‎03-05-2018

Re: API documentation

Just checked on the supported Android tablets. The Samsung Galaxy Tab 4 10.1 and Tab 2 10.1 are both discontinued, and the Tab S2 9.7 is double as expensive as e.g. the Tab A 10.1 which is an outstanding tablet with 1920x1200 resolution, 2/16 GB memory, 1.6GHz octacore processor and up to 13h battery life. A standard EMV transaction works on this Tab A to the extent that it will always only authorize, but not capture. It will return "Transaction Declined", but the authorization was successful and capture can be done in second step via "regular" Authorize.net SDK (or REST call). Whereas the swipe (magnetic stripe) is not working.

 

Would be nice if this tablet could be fully supported also!

 

Thanks for considering! :-)