07-09-2011 09:04 AM
From many posts that I've reviewed, it's clear that the SDKs have not been thoroughly tested by professional testers.
The docs have either not been done at all, or not been reviewed for correctness by an "outside" party.
The net effect is that Authorize customers are doing the alpha testing plus the beta testing.
It's fairly common to see Authorize referred to by its costomers in fairly derrogatory terms.
Brand management doesn't get any worse than this, short of criminal prosecution.
Michelle, you could be a hero at Authorize by gathering up all this feedback and documented frustration and
reporting this to the development supervisors.
Alternately, you could steer me to that development supervisor and I'll make the case.
07-13-2011 08:21 PM
I switched over from the C# SDK to a Python SDK I wrote myself (it's posted publicly). Divorced from the SDK, the API works reasonably well, except for one annoyance.Unicode characters get encoded as UTF8, and then the resulting UTF8 gets encoded as UTF8 again. Doube encoded, so to speak, so you have to decode twice.
This must irk the hell out of EU folks. Consider for example, that with such a bug, it would be nearly impossible to use the usual name/addrees data for verification in the EU.
It's not that hard to build your own SDK from scratch, and I suspect that we can finish quicker than if we wait for the development team. I'm willing to help, and I know for certain that ,NET can replicate the functionality of my Python SDK. I'd have done my SDK in C# but my code has to run on Linux.
The trick is to forget the fancy OO stuff, and just get something basic, even crude, working. In the words of one of the first automotive maufacturing programmers, "any code that works is better than any code that doesn't".
07-15-2011 09:06 AM
Other examples of the above,
and I've only been playing with the SDK's for a few days. I sure hope I haven't made an expensive mistake here...
07-15-2011 10:46 AM
Thanks for the feedback on the SDKs. There definitely have been/are bugs that have been discovered that we're working on fixing. We do rely quite heavily on our developers to point out any issues and make suggestions for improvement. We do test everything before we release, but invariably, there will always still be things we need to fix.
Please continue to use these forums to report the issues you come across. The only way to make anything better is to hear about what's wrong!
reachpeople64, thanks for the report there. I'll pass those issues on as well.
Developer Community Manager
07-15-2011 09:08 PM
Michelle, I think you're missing the point.
Both development and testing, as with any engineering activity, can be done well or badly.
What's more than clear from these community postings, is that relative to code volume, Auth SDKs are vastly buggier than Microsoft applications. If your SDK development team were competing in a true market for Auth SDKs, they'd be either better or buried already. What surprises some of us is how little professional pride they appear to have.
This is what needs to be communicated to th SDK development supervisor. But maybe this is like the Python SDK...maybe the community will have to figure out how to do this by itself...
07-16-2011 04:39 AM
The very minimum that constitutes pre-alpha testing is to show even one single example in which the code returned the data as documented. Your customers conducted that test, and the answer was that the SDK did not.
Here is from Auth's own site:
The following is the XML response to a successful call to getTransactionDetailsRequest.
<?xml version="1.0" encoding="utf-8"?> <getTransactionDetailsResponse xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <messages> <resultCode>Ok</resultCode> <message> <code>I00001</code> <text>Successful.</text> </message> </messages> <transaction> <transId>1111111111</transId> <submitTimeUTC>2002-05-30T09:01:13Z</submitTimeUTC> <submitTimeLocal>2002-05-30T02:01:13</submitTimeLocal> <transactionType>authOnlyTransaction</transactionType> <transactionStatus>settledSuccessfully</transactionStatus> <responseCode>1</responseCode> <responseReasonCode>1</responseReasonCode> <responseReasonDescription>Approved.</responseReasonDescription> <authCode>000000</authCode> <AVSResponse>X</AVSResponse> <cardCodeResponse>M</cardCodeResponse> <batch> <batchId>12345</batchId> <settlementTimeUTC>2002-05-30T10:01:13Z</settlementTimeUTC> <settlementTimeLocal>2002-05-30T03:01:13</settlementTimeLocal> <settlementState>settledSuccessfully</settlementState> </batch> <order> <invoiceNumber>INV00001</invoiceNumber> <description>some description</description> <purchaseOrderNumber>PO000001</purchaseOrderNumber> </order> <authAmount>2.00</authAmount> <settleAmount>2.00</settleAmount> <tax> <amount>1.00</amount> <name>WA state sales tax</name> <description>Washington state sales tax</description> </tax> <shipping> <amount>2.00</amount> <name>ground based shipping</name> <description>Ground based 5 to 10 day shipping</description> </shipping> <lineItems> <lineItem> <itemId>ITEM00001</itemId> <name>name of item sold</name> <description>Description of item sold</description> <quantity>1</quantity> <unitPrice>6.95</unitPrice> <taxable>true</taxable> </lineItem> <lineItem> <itemId>ITEM00001</itemId> <name>name of item sold</name> <description>Description of item sold</description> <quantity>1</quantity> <unitPrice>6.95</unitPrice> <taxable>true</taxable> </lineItem> </lineItems> <prepaidBalanceRemaining>30.00</prepaidBalanceRemaining> <taxExempt>false</taxExempt> <payment> <!-- either creditCard or bankAccount will be here --> <creditCard> <cardNumber>XXXX1111</cardNumber> <expirationDate>XXXX</expirationDate> <cardType>Visa</cardType> </creditCard> <!--<bankAccount> <maskedAccountNumber>XXXX0000</maskedAccountNumber> <maskedAbaRoutingNumber>XXXX0000</maskedAbaRoutingNumber> <nameOnAccount>John Doe</nameOnAccount> <bankName>Bank of Blah</bankName> <echeckType>WEB</echeckType> </bankAccount>--> </payment> <customer> <type>individual</type> <id>ABC00001</id> <email>email@example.com</email> </customer> <billTo> <firstName>John</firstName> <lastName>Doe</lastName> <company></company> <address>123 Main St.</address> <city>Bellevue</city> <state>WA</state> <zip>98004</zip> <country>USA</country> <phoneNumber>000-000-0000</phoneNumber> <faxNumber></faxNumber> </billTo> <shipTo> <firstName>John</firstName> <lastName>Doe</lastName> <company></company> <address>123 Main St.</address> <city>Bellevue</city> <state>WA</state> <zip>98004</zip> <country>USA</country> </shipTo> <recurringBilling>false</recurringBilling> <customerIP>0.0.0.0</customerIP> </transaction>
07-16-2011 04:58 AM
As a parenthetical note about marketing, try googling "authorize transaction details api". The flack on this forum and this thread will be on the first page of results.
I believe that's because many pages on other sites contain links to posts in this thread. Free publicity, you could say.
Two weeks ago, when I was trying to solve this problem, googling "authorize transaction details api" brought up almost nothing but Auth stuff like below. That's good marketing, "here's what we can do for our customers' developers".
Now, on the first page of search results we see a lot of "here's what they can't do for their customers' developers" and "poor job of it' and "unreliable" and "frustrating", etc.
08-13-2011 12:10 AM
The documentation just needs more emphasis on [good] code samples and less on abstracts. People want to be able to download the SDK and then plug in a chunk of code - they don't want to have to wade through endless wads of documentation trying to translate it into code. In the case of the PHP API, it's doubly bad, since some of the API code is written from an XML perspective and some more from a pure PHP perspective, and the format varies quite a bit between, say, AIM and ARB. A lot of the test code is badly-written as well (endless use of echo, global scope variables, etc.) Given, if you're smart enough to look at the markdown files in the doc folder and mostly ignore the documentation, and assuming people are willing to help you in the Integration area, you can probably figure things out eventually. Paypal's API is equally muddy if you're charging internally, and I imagine that every major merchant system out there has its foibles, since the emphasis is always on adding features and not so much on documentation and implementation from an end-user perspective.
Has anyone found a merchant system that's actually easy to implement and use? Because we can bash Authorize.net all day and night, but unless there's a better alternative, doing so is rather pointless. I've used SecurePay and dabbled in Paypal, and neither was any easier to implement.