6 ms·
The lesson learned here isn't that FeeFighters fucked up their acquisition. It's that you should be especially wary building businesses that depend almost entir
by mvkel 14y ago
The lesson learned here isn't that FeeFighters fucked up their acquisition. It's that you should be especially wary building businesses that depend almost entirely on another startup.
Put another way, you should only use services that are pretty obviously going to stay around and aren't just a few years old with no solid track record.
A service may be perfect for your business to hook into, but is it really realistic to expect something like Samurai to stick around for 5-10 years?
EDIT: I would also say that yes, FeeFighters _did_ royally eff up the acquisition process in that they threw their customers under the bus. It lends credence to the idea that they probably had no customers to begin with.
Also, GroupOn is not the enemy here. They acquired technology, talent, whatever. It's in their best interest to negotiate terms that are favorable to GroupOn. If FeeFighters didn't go to bat for their current customers, why would GroupOn volunteer to take on that burden?
- whit537 14y agoYeah, no kidding. I ended up with a merchant account with fusty old FirstData out of the ordeal. I look at FirstData and their portal, www.mymerchantoffice.com, in a whole new light now. It may suck, but I can expect it to suck consistently for years to come. It also feels now like I should be vaulting cards with multiple vendors to avoid a single point of failure. As mentioned I went with Stripe, who are similarly green. I'm in the process of moving my merchant account over to Braintree. Also looking at WePay and Dwolla. Who else?
- polyfractal 14y agoBraintree is pretty great, I like working with their API and customer service (always ready and willing to talk on the phone, which is great). Avoid Authorize.Net like the plague. Horrifically bad XML API that will make you want to claw your eyes out.
- jmathai 14y agoBut it'll be a horrifically bad XML API for years and years :)
- chrismckee 14y agoYou should try WorldPay if your looking for shit but consistent. WorldPay will be around for ever, as will their dog-rough "web service" written by someone who hates the web and where verification tokens are optional. Checkout this FAB API http://www.worldpay.com/support/kb/bg/recurringpayments/rpfp.html#rpfp8009.html http://www.worldpay.com/support/kb/bg/recurringpayments/rpfp...
- jmathai 14y agoThat's not really much worse than Authorize.net. Don't get me wrong. I hate Authorize.net and don't plan on using them for anything in the future. I'd rather refactor code than write comma separated string code once knowing it will work forever.
- tzs 14y agoWhere is there XML in Authorize.Net's API? Here's how you charge a card using the AIM (Advanced Integration Method) interface (Perl sample code): my $post_values = { "x_login" => "API_LOGIN_ID", "x_tran_key" => "TRANSACTION_KEY", "x_version" => "3.1", "x_delim_data" => "TRUE", "x_delim_char" => "|", "x_relay_response" => "FALSE", "x_type" => "AUTH_CAPTURE", "x_method" => "CC", "x_card_num" => "4111111111111111", "x_exp_date" => "0115", "x_amount" => "19.99", "x_description" => "Sample Transaction", "x_first_name" => "John", "x_last_name" => "Doe", "x_address" => "1234 Street", "x_state" => "WA", "x_zip" => "98004" }; my $useragent = LWP::UserAgent->new( protocols_allowed => ["https"] ); my $request = POST( $post_url, $post_values ); my $response = $useragent->request( $request ); That's just a straightforward form post to a CGI. Result is a line of CSV data. No XML in sight. Does the non-AIM option (I forget what it is called) use XML?
- polyfractal 14y agoI don't have the code handy (was client work for a third party), but we definitely used XML through Auth.net's AIM. Here are the API docs for it: http://www.authorize.net/support/AIM_guide_XML.pdf http://www.authorize.net/support/AIM_guide_XML.pdf We also used XML through their CIM to manage customer profiles. To be fair, this was all in PHP, and the code was inherited so I'm not sure if there was a better way to deal with Auth.net's API. I do know that their dashboards were thoroughly unpleasant to deal with and I felt the API was obtuse in many different locations.
- tzs 14y agoInteresting. Here's the non-XML AIM guide: http://www.authorize.net/support/AIM_guide.pdf http://www.authorize.net/support/AIM_guide.pdf That's the one we use. I didn't even know they had an XML option--and now I'm going to try to forget it! :-)
- polyfractal 14y agoInteresting! I had no idea they had a non-XML option. If I was still working on the project, I'd totally push for that. Good to know for future projects =)
- pavel_lishin 14y agoI used Authorize.net at a previous employer, and don't remember the API being too terrible. We wrote a wrapper for it, and forgot all about it until we needed to add features.
- jusben1369 14y agoShameless plug for Spreedlycore.com where you can vault your cards separately and work with all the gateways listed here. This is an extreme example (gone into limbo in this case) but one of the motivations for our offering. You could have migrated to Stripe/Braintree etc via a config change.
- michaeledwards 14y agoThis looks really cool.
- BallinBige 14y agoSo true! First Data is the grandpa in the room. Their site doesnt render properly on Chrome even :(
- whit537 14y agoI experienced great customer service from FeeFighters prior to the acquisition, so in my experience it's not true that "FeeFighters didn't go to bat for their current customers." The "enemy" to my mind is the chaos that results from not being transparent and kind.
- ryanmolden 14y agoI believe he meant go to bat during the acquisition deal making. Regardless of how awesome their CS was pre-acquisition if there were no terms regarding current customers/continuity during the acquisition talks then they didn't "go to bat for their customers".
- whit537 14y agoRoger that. Thank you.