Alternative Payment Systems, Part 6: Comparing Options
This is the sixth and final installment in my multi-part series comparing alternative payment systems to the PayPal X Platform and each other. Part one introduced Amazon’s Flexible Payments Service, part two discussed Facebook Credits, part three focused on Google Checkout, part four examined Dwolla, and part five explained mobile payment options, especially the Square and Intuit GoPayment mobile credit card reader-based systems.
In this article, I summarize the key strengths and weakenesses discussed for each of the alternative systems in the previous five articles. This is done in comparison with the PayPal X Platform and PayPal solutions. I then consolidate features, availability, pricing, and related information for each system, PayPal and alternatives alike, into a table for easy cross-comparison. By the end of this article and series, you should understand the major payment system options available to you and be able to make recommendations on which system(s) would be appropriate for a specified set of payments requirements.
Strengths and weaknesses of each alternative system
Let’s make a quick review of the keys advantages and disadvantages of each system. I’ve also called out how each compares to the PayPal X Platform.
Amazon Flexible Payments Services (FPS)
Amazon FPS provides a sandbox-based development and testing environment to PayPal’s. Both allow you to create test accounts, build applications using their systems, and test deploy those applications into their sandboxes for free.
Both FPS and PayPal’s Adaptive Payments support a variety of payment types (periodic, deferred, micropayments). Both allow for the construction of marketplaces with multiple parties in the payments chain. Both support API-based processing using standard programming and scripting language SDKs. FPS does not appear to support more advanced Adaptive Payments capabilities such as Chained and Parallel payments, however.
The short of it: FPS most closely compares to PayPal’s Adaptive Payments, just one component (albeit an important one) of the PayPal X Platform. In that regard, FPS may be seen as a subset of the PayPal X offerings.
From my perspective, there’s no compelling reason for developers to choose Amazon’s more limited FPS over the full PayPal X Platform unless their customers require support for Amazon-based purchases. Existing FPS developers, however, might find much to love in the full breadth of the PayPal X Platform.
Facebook Credits is a virtual and online currency currently tied to the Facebook application platform exclusively. The PayPal system accepts a wider variety of funding options and is a more general purpose system.
Facebook’s Credits API is similar to the PayPal X Platform’s Express Checkout. But Express Checkout can be used with applications built for any Internet-ready container and environment while Credits only works for Facebook-based applications.
If you aren’t required to use Facebook Credits for an application you must run in their platform, I wouldn’t. It doesn’t make sense to pay big fees to Facebook when there are less expensive options such as PayPal’s (see the table below for more on pricing). And given the superset of capability available to you via the PayPal X Platform, Credits looks even less appealing.
Google Checkout is relatively easy to implement, affordable, and reliable. The Google brand is also well trusted by consumers.
However, Google Checkout does not provide anywhere near the full capabilities of the complete PayPal X Platform. It compares most directly to PayPal’s Website Payments, Fraud Management Filters, and Embedded Payments technologies. Even if you include Google In-App Payments and Google Wallet, neither of which are currently generally available, Google solutions still fail to provide the full functionality available commercially today in the PayPal X Platform.
Given the choice between the two, I would recommend the PayPal X Platform in most cases unless a merchant was already locked in a fairly tight business relationship with Google.
Dwolla lists a number of consumer and merchant advantages for their system. Unfortunately, most of them are not unique to Dwolla. In fact PayPal and some of the other alternative systems we’ve discussed in this series also offer similar person-to-person money transfers, shopping features, real world payments support, mobile apps, and integration into various shopping carts. And Dwolla’s “no credit cards” model in practice limits the customer base available to you if you use their system.
I like Dwolla’s support for a REST API and its use of JSON for server communications. They also offer SOAP support, if you need that. But PayPal’s much wider variety of APIs along with the various documentation, examples, and SDKs available from the X.com site trump Dwolla’s API offering.
I believe many developers trying out Dwolla will find it limiting compared to the capabilities of the PayPal X Platform. See the table below and make your own decision as to whether you should try it for your particular payments needs.
Square and Intuit GoPayment
Both Square and Intuit GoPayment make it easy for you to begin accepting credit card payments in real world settings. Both allow you to accept these payments from readily available mobile devices with free mobile card reader attachments. Both allow for digital receipts. And both require relatively little of the consumer, giving them at least a decent shot at success as mobile payments shakeout.
But one of their big strengths, their focus on credit card processing, is also one of their major shortcomings. Both Square and Intuit GoPayment handle in-app credit card purchases. But what if your consumer wants to pay with cash? Or via a non-app mobile channel such as SMS? What about recurring transactions? There are many payment areas and flows such as these where both Square’s and Intuit’s mobile systems fail.
In summary, Square and Intuit GoPayment offer small subsets of the PayPal X Platform’s and PayPal solutions’ capabilities. If you only need in-app credit card based mobile payments, Square or Intuit might be sufficient. If you need anything more, PayPal provides solutions where Square and Intuit GoPayment don’t.
Comparing all the options
Now that we’ve reviewed some of the the strengths and weaknesses of each payment system, you may wish to cross-compare each against the others. What better way than via a nice, big table?
|Payment system||Geographic availability||Pricing, per transaction||Web-based shopping cart and checkout||Adaptive Payments-like capabilities and flexibility||Mobile payments (browser, in-app, and/or SMS)||Credit card support||Debit card, bank account, and/or cash funding options||Web API support||Language support||Sandbox environment||SDKs||Application platform and container|
|PayPal X Platform||More than 190 countries worldwide||Most transaction types 1.9% – 2.9% + $0.30 USD (click here for details)||Yes, via Website Payments, Express Checkout, and other options||Yes, full set of Adaptive Payments APIs||Yes, full browser (PayPal Mobile app, Mobile Express Checkout), in-app (Mobile Payments Libraries), and SMS support||Yes (several options depending upon merchant needs)||Yes (debit card and bank transfers both supported; cash indirectly via bank transfers)||SOAP, JSON, XML, NVP||Java, PHP, ASP.NET, C#.NET, VB.NET, C++, Ruby, Python, Perl||Free test accounts and deployment while you develop your applications||Java, PHP, ASP.NET, Ruby, Android, iOS (iPhone and iPad)||Works with any application environment or container via Web APIs|
|Amazon Flexible Payments Service||All transactions are in U.S. dollars. Bank account and account balance transfers are U.S. only; credit card purchases on FPS-powered websites are supported for international customers.||U.S. customers: 2.9% + $0.30 for credit card transactions above $10; 1% more from non-U.S. customers (click here for full details on FPS pricing)||Yes||Yes, but a subset (see FPS article for details on what is and is not available)||Yes (browser based Amazon MPS; no in-app or SMS options)||Yes||Yes (bank debits supported)||RESTful||C#, Java, Perl, PHP||Yes||C#, Java, Perl, PHP||Any via RESTful API|
|Google Checkout||Merchants must be in the U.S. or United Kingdom; buyers may be in over 140 countries||2.9% + $0.30 for transactions below $3,000; percentage decreases in steps after that for bigger purchase amounts||Yes||No||Yes (browser-based only, no SMS support; In-App Payments not yet generally available)||Yes||Yes (debit card or gift card)||XML and HTML APIs||Java||Yes||Java||Any via HTML or XML APIs|
|Dwolla||U.S. only||$0.25 to receive money||Available in several popular shopping carts (click here for info)||No||Yes, “core features” accessible via iPhone and Android apps||No||Bank transfers||REST and SOAP APIs||C# examples on Dwolla site||Test endpoint for SOAP API; nothing available for REST API||No||Any via REST or SOAP APIs|
|Square||U.S. only||2.75% per swiped card transaction||No (for real world purchases, not online)||No||Yes (Square Card Case for customers, Square Register for merchants)||Yes||No||N/A (system not open for third party developers)||N/A||N/A||N/A||N/A|
|Intuit GoPayment||U.S. only (but I couldn’t find anything definitive on the GoPayment site)||2.70% per swiped card transaction on the no-monthly-fee plan||No (for real world purchases, not online)||No||Yes (Merchant card reader system uses on-device app)||Yes||Debit cards||N/A (system not open for third party developers)||N/A||N/A||N/A||N/A||Payment system||Geographic availability||Pricing, per transaction||Web-based shopping cart and checkout||Adaptive Payments-like capabilities and flexibility||Mobile payments (browser, in-app, and/or SMS)||Credit card support||Debit card, bank account, and/or cash funding options||Web API support||Language support||Sandbox environment||SDKs||Application platform and container|
Click here to read the complete article on the PayPal X Developer Network including the key takeaways from this series.
From → Uncategorized