Since its inception, PayPal has worked with partners and merchants to build what I believe is the best overall online and mobile (and increasingly, offline too) payments system available today. More recently, they have listened to the development community to learn how to best make this system available to developers. The result: The PayPal X Platform.
I write a lot about the PayPal-based payments and solutions on the PayPal X DevZone. But it seems to me that in order to fully appreciate PayPal capabilities, and how developers can best use them, one should consider how they relate to alternative payment systems and options.
This article is the first in a series in which I’ll examine alternative payment systems. This time around I’ll introduce Amazon’s Flexible Payments Service (abbreviated as “FPS”). I’ll discuss what FPS is, where to go to learn more, how to use it, and how it compares to PayPal’s offerings. Future articles will look at other payment systems.
What is Amazon FPS?
Amazon FPS is a part of the Amazon Web Services (aka “AWS”, collectively on Twitter at @awscloud) cloud-based technologies and solutions. The full breadth of available AWS services are beyond the scope of this article; I’ll leave it as an exercise for the reader to visit the AWS site and learn more if interested.
Let’s focus on the general purpose payments portion of AWS offerings, Amazon FPS. Amazon says the following about FPS on its homepage:
It is built on top of Amazon’s reliable and scalable payments infrastructure and provides developers with a convenient way to charge Amazon’s tens of millions of customers (with their permission, of course!). Amazon customers can pay using the same login credentials, shipping address and payment information they already have on file with Amazon.
As you can see, FPS is meant to provide a single cross-merchant payments mechanism similar to PayPal’s platform. Amazon goes on to note:
With Amazon FPS, developers can accept payments on their website for selling goods or services, raise donations, execute recurring payments, and send payments.
FPS is starting to sound similar to PayPal’s Adaptive Payments, isn’t it? We will dwell on this further later in the article. For now, let’s look at where you can go to learn more about FPS if you’re so inclined.
FPS documentation
If you’d like to dive deeper into FPS, the first place you should visit is the FPS homepage.
From there you can link to a variety of developer and consumer oriented documentation and information including:
- “Service Highlights for Developers” explains the advantages to the FPS system as Amazon sees them; a key point here is that Amazon promises that FPS should be low friction for existing Amazon customers.
- Amazon also provides a similar “Service Highlights for Consumers” listing reasons why they believe consumers may like using their system.
- “Amazon FPS Functionality” discusses FPS “quick starts”; more on this below.
- “Pricing” gets down to the nitty gritty of what it costs to play in the FPS world; I’ll compare this with PayPal costs later in this series.
- “Developer Resources” links to a resource center for code samples and documentation, FPS developer discussion forums, the Amazon FPS Sandbox (again, this should seem very familiar to PayPal developers used to the PayPal Sandbox), an Amazon Payments site that lets you manage your account through a web browser rather than via the Account Management Quick Start mentioned previously, and FPS FAQs.
FPS Quick Starts provide simplified API sets meant to help developers implement common transaction types. Example Quick Starts include:
- Basic Quick Start for one time payments
- Advanced Quick Start for periodic or delayed payment features required by subscription and usage-based services
- Marketplace Quick Start to facilitate transactions between buyers and third party sellers (taking a cut for your facilitation)
- Aggregated Payments Quick Start for bundling up multiple payments (micropayments are possible) into a single larger transaction
- Account Management Quick Start for programmatic access to FPS account activity
Using FPS
In order to get started with FPS, you do need to create an Amazon Payments Sandbox account. You can do this by clicking on the “Sign Up for Amazon FPS” button on the FPS homepage and then logging in with an existing Amazon account or creating a new one. This will take you to the FPS signup page:
You can skip the rest of the signup for now and start using the FPS Sandbox immediately via the link at the lower right. Doing so gives you a success page similar to:
and from there you can click to get to the Sandbox homepage:
At this point you would be setup to access the “Amazon Flexible Payments Service Getting Started Guide” and create Sandbox accounts for testing. You could also read through the guide, download the FPS SDK for your preferred language (Amazon provides C#, Java, Perl, and PHP SDKs for using the RESTful FPS API as of this writing), and start developing using the FPS web service for payments.
Click here to read the complete article on the PayPal X Developer Network including a comparison of FPS to the PayPal X Platform and Adaptive Payments.
PayPal recently published a case study with one of their partners, consumer electronics superstore Crutchfield, discussing increases in mobile conversion when Crutchfield tested streamlining purchases using Mobile Express Checkout (MEC).
The big ticket findings from the study are truly impressive:
- MEC increased purchase rates 33.7%!
- 65% of the MEC customers are new to Crutchfield
The PayPal blog post on the findings noted that Crutchfield’s VP of Direct Marketing told PayPal:
Testing validated that PayPal is driving significant conversion lift on our mobile site. This is evidence that providing a fast and easy checkout is an integral part of the mobile shopping experience.
This is consistent with other retailers’ use of MEC, though of course exact numbers vary from partner to partner.
Click here to read the complete post on the PayPal X Developer Network including more on how you can implement MEC in your own mobile purchase flows.
eBay, PayPal, and Magento recently announced that eBay is acquiring Magento and that all three are merging their developer platforms together. As a part of this, all three of their existing developer communities are being merged into one as well, via the X.com site.
These steps will form the new X.commerce platform. (Lawyerese: This is “subject to customary closing conditions” and until the transaction closes eBay/PayPal and Magento remain separate companies and operate separately.)
The new X.com homepage describes the change thusly:
X.commerce is the first cloud-based platform enabling developers, merchants and service providers to create innovative solutions in the commerce space. Using an open source environment, X.commerce offers the fundamental technologies needed for commerce – shopping carts, payment services, inventory management, marketplace integration, SEO, tax guidance and more, all in one location.
You can watch the CEO of eBay describe this merger and the X.commerce vision below (or if the embedded link isn’t working correctly, click here to watch it on Youtube):
Click here to read the complete post on the PayPal X Developer Network including a link to the new X.commerce blog.
I recently had occasion to procure a shiny new iPhone 4 (read: old iPhone died) and have been trying out all kinds of apps given all the space I now have to fill. I’ve been looking at iOS payments, finance, investing, shopping, and marketing apps in particular.
Based upon my investigations, and building on the groundwork Travis Robertson laid with his previous series of Android QR code reader reviews, I thought I’d kick off a new intermittent series of iPhone app reviews by looking at the best QR, UPC, and Data Matrix code scanner I’ve come across for iOS to date.
That iPhone code reader is the AT&T Code Scanner (click here to download). Watch the Youtube video embedded below (or click here if the embed isn’t working) for an overview of the scanner and how it works.
If you’re like me, you’re thinking “What?!?”. It is a bit non-obvious why AT&T would have a code reader of their own. Maybe it’s to increase traffic, though I believe the app will work over other networks, too. Or maybe it’s to keep a finger on the pulse of things since clicking on a scanned link hits AT&T’s server first, thus recording what link you scanned in via the reader.
Whatever the reason AT&T decided to offer it, their app is a good scanner. Here’s the skinny from my perspective.
Positives: Fast. Locks onto a code placed inside the screen input box usually before you even get a chance to get the code centered or focused upon (see the blurry example below showing one code I scanned for an idea of just how forgiving AT&T’s app is). Offers to connect you to the encoded information (often a URL but the app also supports scanning note, phone call, and contact card information among other things) very quickly after scanning the code. Also offers options to create your own codes via an AT&T site and to configure a number of settings for how you are notified when you scan something.
Click here to read the complete review on the PayPal X Developer Network including a look at app negatives and my overall impression and rating of it.
If you follow the DevZone blog you know that I have a thing for development consoles.
They make my life easier by bootstrapping my use of new and changing APIs, especially in the prototyping phase. What’s not to love?
Given my interest in consoles in general and my work with Facebook technologies including the Facebook Graph API in particular (see this post on the Graph API if you need a primer on the technology and the sorts of things you can do with it), I was delighted to come across a recent ProgrammableWeb article on a “semi-unofficial” Facebook Graph API Explorer. Facebook Partner Engineer Simon Cross (@sicross) has built what is in effect a Graph API console to help you learn about and use Facebook’s API.
It seems a bit cleaner than the roughly comparable Apigee Facebook console (click here to see that console in action in an earlier blog post of mine), though of course Simon doesn’t have to provide consoles for other APIs besides Facebook’s so it might not be completely fair to compare Apigee’s to his. Still, I like the streamlined look of Simon’s interface. And I love the Explorer’s metadata section which provides very useful information on connections and fields for a given node. For instance, here’s the output when one pulls up my account via a Graph API query:
Compare that to the same call in Apigee’s console:
Click here to read the complete post on the PayPal X Developer Network including a suggestion for improving the Explorer by taking a page from Apigee’s playback.
A couple of months ago I wrote a four part series on LinkedIn for the DevZone blog. Among other things, I covered the LinkedIn REST API, embeddable widgets, their JavaScript API, and third party libraries for using all of this LinkedIn goodness.
Since that time LinkedIn has gone public (LNKD anyone?). And perhaps more importantly for developers, they’ve also released an update to their APIs including the addition of new Jobs and Companies APIs. LinkedIn notes that you can use the new Companies API to:
Display a detailed overview of company information in combination with LinkedIn data. Search across company profiles by industry, location, size, and more. Enable your users to follow a company and see suggested companies to follow.
and the Jobs API like so:
Search LinkedIn’s jobs by company, industry and more to display relevant jobs to your users. Post and retrieve LinkedIn jobs for a company, and enable people to save jobs to their LinkedIn accounts and retrieve job suggestions.
LinkedIn provides a number of example calls on the API overview page. As of this writing, it doesn’t appear that the LinkedIn Apigee console has been updated for these new APIs yet, so for now you’ll need to try them out outside of that tool.
Click here to read the complete post on the PayPal X Developer Network including links for more detailed information on the new APIs.
I wrote about PayPal’s original Mobile Checkout technology in the article “PayPal in Your Pocket” last year.
Subsequent to that PayPal released details to its successor, Mobile Express Checkout (MEC), as part of the Innovate 2010 developer conference. You can read much more about MEC and see it in action in my subsequent article “Streamlining Purchases with Mobile Express Checkout“.
When MEC was released, I posted a question on the X.com developer forums asking if that meant that the older PayPal Mobile Checkout (PMC) was now deprecated. PayPal DTS responded that as of then (November 2010), developers were being encouraged to use MEC instead of Mobile Checkout. DTS also noted that Mobile Checkout was still being supported for the time being, but it was clear that new development should be done using MEC. Click here to read the forums discussion for the details.
I moved on with MEC and hadn’t thought any more about this for several months until I saw recently that PayPal X developer Jukka Saarelainen noted a recent email received from PayPal stating the older technology was scheduled for end-of-life later this year. According to Jukka, the email reads:
“We wanted you to know that on 1 September 2011, the PayPal Mobile Checkout (PMC) product will be discontinued. From that date on, the PMC service will not function.”
Click here to read the complete post on the PayPal X Developer Network.
PayPal X Platform
- My latest @PayPalX post: Which payment systems interest you? http://bit.ly/l3G1Qv (all feedback greatly appreciated) #
- Google Wallet commentaries http://bit.ly/iiJhmr via @paymentsnews #
Wireless and mobility
- Was just speaking with a friend about #mobile strategy for his business yesterday; timely gotchas to avoid http://oreil.ly/k4Acxt via @radar #
Running
- Ran 6.21 miles in 1 hour and 9 mins and 38 secs and felt great. Mile paces 8:25, 8:40, 8:37, 8:19, 8:32, and … http://dailymile.com/e/VEx2 #
- This @outsidemagazine article on persistence hunting http://bit.ly/iXrgcG is interesting from running, hunting, *and* anthropological angles #
- Ran 6.85 miles in 1 hour and 14 mins and 42 secs and felt alright. Tempo plus cooldown after. http://dailymile.com/e/VM6X #
May has been a particularly busy month with a lot of news and development on the payments and developer fronts. Let’s dive in!
I published the final part of my “Integrating Payments into WordPress” series this month, part3 on building your own PayPal WordPress plugin. This series showed you how to install and use WordPress, add new capabilities with plugins, and build your own payments-related WP plugins using the PayPal APIs. Click here to read the final part (you can click through to the previous articles from the top of this one too).
My DevZone blog posts from May included:
- I reminded readers of the original Android Developer Challenge deadline set for May 14th; subsequently PayPal extended the deadline to June 8th
- PayPal announced its purchase of FigCard, a very smartly done mobile wallet/checkout solution that requires no new hardware on the consumer’s side of things (this should make adoption much simpler if PayPal can find some traction with merchants)
- Apigee announced their new Source feature for their consoles (initially, for the Twitter console) which should make RESTful development even simpler and faster
- I wrote about O’Reilly Media’s free online Strata conference exploring Big Data
- PayPal updated their Android app to include mobile check capture capability
- Google launched their NFC-based mobile wallet solution, dubbed Google Wallet; PayPal responded with a lawsuit for trade secret violations
- I asked for reader input on a new series of articles I’m writing for the DevZone on comparing alternative payment systems to the PayPal X Platform; if you haven’t already, please give your input via this one question form
Click here to read the complete post on the PayPal X Developer Network including a summary of other key payments and developer related news from last month.
I’m currently writing a series of articles for the DevZone comparing the PayPal X Platform and its capabilities to alternative payment systems.
So far, I’ve written articles discussing Amazon’s Flexible Payments Service (FPS), Facebook Credits, and Google payment technologies including Google Checkout and Google Wallet (read my related blog post from last week on the latter by clicking here).
My articles look at the strengths and weaknesses of each of those systems, and especially how they compare to PayPal-based development and deployment. For instance, FPS provides a similar sandbox-based development and testing environment to PayPal’s Sandbox and provides somewhat similar functionality to PayPal’s Adaptive Payments, but it is limited to merchants and consumers with Amazon accounts. Similarly, the Facebook Credits API is similar in functionality to PayPal’s Express Checkout, but is only usable by Facebook Platform-based applications whereas Express Checkout can be used with applications built for any proper Internet-ready application container and environment.
The series explores those points and much more, even down to the level of payment flow through some of the alternatives (example: Facebook Credits as pictured below).
Click to read the complete post on the PayPal X Developer Network including information on other systems to be considered and a request for your input on them. You can also access the included survey directly below:
BillDay.com 