Amazon FPS vs PayPal Express for a marketplace app

Ruby on Rails 10 Comments »


VS

We’re currently evaluating possible payment gateways for our new project, DoLeaf. Given that it’s a marketplace app, your standard one-size-fits-all payment system just won’t work. We need to be able to transfer money from any buyer to any seller, and hopefully take a cut for ourselves in the process. With that in mind, we’re looking at both Amazon FPS and PayPal Express (via ActiveMerchant).

Here is our list of pros and cons for each solution:

PayPal Express

Pros

  • Can assume that most sellers will already have a PayPal account.
  • Buyers are used to using PayPal.
  • Integrates with ActiveMerchant, and PayPal + AM looks fairly simple.

Cons

  • High barrier of entry for sellers:

    1. Seller must sign up for PayPal Premier or Business account.
    2. Seller must create API credentials (PayPal provides a walkthrough)
    3. Seller must provide us with their credentials (cut & paste, with the possibility of typos and such)
  • Credentials are quite sensitive and must be treated as such, with encryption in the database at the very least.

Amazon FPS

Pros

  • CoBrand UI can be used to install recipient tokens, making setup easy for sellers.
  • Tokens are transferred automatically, meaning no possibility of typos or transmission errors when seller is etting up.
  • Can run all the transactions for a cart quickly and seamlessly, rather than 1-per-seller.
  • Probably could set up a 1-click ordering sort of system.
  • Overall fees will probably be lower since there’s only 1 transaction per sale (rather than 1 for buyer-to-seller and 1 for seller-to-us)
  • Tokens are not nearly as sensitive as PayPal API credentials.

Cons

  • FPS and Remit are both still kind of unstable.
  • Locks us out of ActiveMerchant, unless we want to support multiple pathways.
  • No convenient pre-built seller interface. We’d probably need to create an account panel for handling refunds and such.

Thoughts

Overall, I’m leaning toward PayPal at this point. ActiveMerchant and the ability to possibly integrate future payment gateways with ease is a big plus in PayPal/ActiveMerchant’s favor. In addition, people are used to using PayPal for these sorts of transactions. So, buyers in the market we’re targeting will almost certainly have a PayPal account, but not necessarily an Amazon payments account. If only there were a way to make it easier for sellers to get set up.

Anyone else go down this path and come to a different conclusion?

RioFlexPay – Easy front-end interface for Amazon FPS – Coming Soon!

Uncategorized 5 Comments »

We’re 95% done on RioFlexPay, a front-end graphical user interface (gui) to the Amazon Flexible Payment System (FPS). We’ve got a splash page up right now, and we’re getting ready to put the production server together in anticipation of a pre-June deployment.

It’s been a tough ride, but we’re almost there! In a few short days or weeks, managing your FPS account will get much, much easier.

Stay tuned!

The search for credit card processing part 1 – TrustCommerce

Business, Plugins, Ruby on Rails 4 Comments »

We have finally gotten to the point where we are ready to start offering subscriptions to Obsidian Portal. We don’t expect there will be a lot of interest, but it’s always a sort of chicken v. egg problem. If you don’t have paying subscribers, then it’s not worth the effort to make the features. Conversely, without the features, no one is going to pay. On second thought, I guess it’s not chicken and egg, it’s pretty clear: you need features or no one will pay. ;)

Asking for payment means you will need to be able to accept it. Currency on the web is passed almost exclusively via credit cards (except for PayPal…), so that’s the direction we need to go in. That requires us to select a credit card processor. For today, we will be looking at TrustCommerce.

I won’t go into the details of how credit card processing works, mainly because I don’t really understand it myself. Suffice it to say, there are a lot of middle-men, and they are all trying to take a cut. Each cut is either a percentage of the total charge or a flat fee or both. So, a typical fee structure might be $0.30 flat fee plus 2.5% of the total transaction.

Note: If you don’t care about the analysis and just want to see a rundown of their prices, then jump to the pricing.

Go easy on me; it’s my first time

When selecting a processing agent, our first priority right now is ease of use. We don’t expect there will be a lot of people signing up for our premium service, so we don’t want to expend a lot of effort on a payment system only to never see it used. Also, we’re willing to pay a higher rate to the processor since 3% of $30/month is a lot different than 3% of $30,000/month. I’ll pay 3% vs 2.5% if the 3% service takes 2 hours to implement and the 2.5% service takes 10. So, for us, ease of use trumps competitive pricing.

Since we’re talking about subscriptions as opposed to purchases, there is a recurring element to the payments. Since we want easy-to-implement solutions, we are scoping our search to only include the payment processors that offer a recurring service. This is a very important thing to note, especially if you’re in the same boat. A 1-time payment processor model (like Google Checkout) just will not work if you want to do subscriptions. The main reason is that you will have to store the users’ credit card info on your server in order to pass it to the payment processor each billing cycle. Do not do this! There are actual laws and regulations detailing what sort of security procedures you have to maintain in order to hold that sort of sensitive data. It’s much easier to simply pay someone else to deal with that crap. If you do choose to store their info in your database, you should be looking for a lawyer right now, not a payment processor.

Just plug in your credit card info

In Rails, ease of use means finding a plugin. I write a lot about plugins on this blog, so why should credit card processing be any different? Doing a quick Google search led me to the TrustCommerce subscription payment plugin.

Finding this bit of code brought a smile to my face, as I thought I had just finished 90% of the work. Sign up for an account, drop in the plugin, and wait for the money to roll in. Too bad there were a few red flags that derailed the money train.

Sitting by the phone

TrustCommerce does not list any pricing on their website. Instead, they say you have to sign up for a test account, and then you’ll be contacted. Not a big deal, I guess. So, I signed up for a test account.

The first red flag went up when I did not get an immediate callback. Sure, I signed up at 11:00pm Eastern Time, but that’s normal business hours in Internet time. In other words, if you’re an Internet company that requires phone contact, you had better have someone manning the phone at all hours. A lot of Web jockeys like me have a regular 9-5 job that precludes us from doing our business dealings during normal business hours. I want to deal with companies that understand this and have staff available during my normal business hours.

Red flags: 1

The ball sits in my court

The second red flag went up at their lackluster eventual response. My cell is in a dead zone at work, so whenever I leave for lunch, I get all my messages. On the day after requesting contact, I had a voicemail message from TrustCommerce. Still no pricing info, just a short message to call them back. Seeing as how I was busy, I couldn’t do it right away. Then I forgot. Dead silence on their end. No e-mails, no more calls, nothing.

Now a lot of people may disagree with me on this, but I think they should have been hitting my inbox and voicemail pretty hard. “Mr. Wedemeyer, we’re still interested in talking to you about blah blah.” or “Send us an e-mail with the best time to call you.” That’s how the mortgage people behaved when I used LendingTree. Sure, it was annoying, but you knew they wanted your business. To me, an anemic response indicates that someone isn’t really serious about recruiting me as a customer.

Red flags: 2

Little fish: prepare to get fried

When I finally did get in touch with someone from TrustCommerce, he was quite happy to answer my pricing questions. I don’t know if I’m allowed to post that info, but since they didn’t expressly forbid it, here you go:

Basic pricing

  • $95 1-time fee
  • $20 / month
  • $0.20 / transaction

Citadel (recurring payments)

  • $145 1-time fee
  • $10 / month
  • $0.10 / month / billing id (ie. subscription)

Holy crap! $240 just to get started, plus an additional $30 per month, just to be allowed to use their service? Seeing as how I expect Obsidian Portal to be making around $10 / month, at least until we can recruit more people, this is insane! I politely said thank you to the salesman, hung up the phone, and started writing this post.

I guess I see these huge front-loaded fees like this: If you’re making enough money that the fees don’t matter, then you already have a lot of subscribers, which means you’re already handling credit cards. Maybe their service is so great compared to the competition that it’s worth it for the big boys. But, if you’re a small time operator like me, forget about it.

Red flags: 240 + 30 / month

The search continues

Although I said pricing was not our top priority, the front loaded fees with TrustCommerce completely invalidate them as a viable option. It would be a very long time before we paid off the initial investment, and with our none-to-clear business prospects with Obsidian Portal, that’s a gamble I’m not willing to take.

In the next exciting chapter we will be looking at Amazon Flexible Payment System (FPS). This new web service from Amazon is meant to rival Google Checkout and PayPal. I’ve been extremely pleased with S3, and maybe they can do one better with FPS. Stay tuned to find out.

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in