Skip to content

PayPal Mobile for iPhone updates

PayPal has updated their iPhone mobile app which I’ve written about previously here and here.

According to the PayPal Blog post:

It features some great enhancements based on feedback straight from our users and general fixes for an even smoother experience.

The post goes on to say:

Our latest research findings indicated that our customers wanted easier access to their History to increase efficiency on the go.  We also learned that ALL of the App’s great features needed to be  right up front, where they’re easy to find.  We’ve taken this feedback to heart and we think you’ll notice – and really like! – the adjustments we made.

So the updated app now has a screen showing all features in one place for easier access.  As noted above, PayPal has also added a very useful transaction history screen which includes support for filtering your transactions so you can find what you’re looking for quickly.

Click here to read the complete post on the PayPal X Developer Network including some particular things you should note if you’re interested in trying out the app.

Notes from the week of 2011-07-24

PayPal X Platform

Wireless and mobility

APIs and development

Personal things

Running

PayPal Invoicing APIs in beta

Today I’d like to write a little bit about PayPal’s Invoicing APIs, currently in beta.

The Invoicing APIs allow you to create and send electronic invoices.  Here’s PayPal’s high level description of how the APIs work, excerpted from the Invoicing APIs page on X.com:

To initiate a request for payment, merchants initiate an API call to PayPal. Customers receive the invoice via email and click on an included link to view the invoice on PayPal’s website. Customers who have a PayPal account can log into their PayPal accounts to pay the invoice. Invoices paid using PayPal are usually paid to the merchant’s PayPal account right away. Customers can also pay using a check, debit, or credit card.

The PayPal Invoicing API Developer Guide (click here for PDF) provides an introduction to using the API.  The guide details the three API calls currently available to developers via NVP, SOAP, or JSON:

  • CreateInvoice – used to create and populate the required fields in a new invoice; used in conjunction with SendInvoice
  • SendInvoice – used after creating an invoice to send it to the payor
  • CreateAndSendInvoice – alternatively, you may use this call to both create and send an invoice in one operation

PayPal illustrates the single operation creating and sending an invoice thusly:

https://www.x.com/servlet/JiveServlet/downloadBody/3751-102-1-4091/invoicing_apis_548x322_01.jpg

Click here to read the complete post on the PayPal X Developer Network including links to the available SDKs and planned additions to the Invoicing APIs.

"Towers of the Ennedi" gives me the exploration itch

This North Face documentary about climbing the spires and arches of the incredibly stark and remote Ennedi desert in Chad is inspirational and beautiful. It gives me the trail running and exploring itch!

The North Face®: Towers of the Ennedi from Camp 4 Collective on Vimeo.

PayPal acquires carrier billing capability via Zong

https://i0.wp.com/blog.zong.com/wp-content/uploads/2011/07/ZongPayPal_LogoTreatment3.png

PayPal recently announced that their parent company, eBay, is acquiring Zong (@zong).  Once the deal closes, Zong will become a part of PayPal.

Zong provides a mobile payments system that bills consumers via their mobile phone carrier billsThis Zong screencast shows you how the system works (if the YouTube embed below isn’t working for you, click here to go directly to the video).

Zong CEO and founder David Marcus (@davidmarcus) had this to say in his announcement of the acquisition on the Zong blog:

I am so excited by the unique combination of PayPal’s 8 million merchants, brand power, risk management expertise, and financial stability, with Zong’s Carrier DNA, its largest direct carrier payments network, product innovation, and best-in-class carrier billing technology. This industry first is going to allow us to scale what we’ve built over the course of the past 3 years (and then some) in a massive way!

Click here to read the complete post on the PayPal X Developer Network including a discussion of why this acquisition matters for PayPal, PayPal merchants, and PayPal X Platform developers.

Notes from the week of 2011-07-17

PayPal X Platform

Big data

APIs and development

Personal things

Running

iOSDevCamp at PayPal

Heads-up to everyone in or near the SF Bay Area this week:

https://i0.wp.com/www.iosdevcamp.org/images/iosdevcamp.png

This year’s iOSDevCamp is being held Friday through Sunday, 15-17 July 2011, at PayPal’s San Jose offices.  In the words of the organizers:

iOSDevCamp (previously know as iPhoneDevCamp and iPadDevCamp) is an annual not-for-profit gathering to develop applications for iOS, including iPhone, iPad, and iPod touch, using both the native SDK and web standards.

If this sounds kind of BarCamp-y to you, that’s because it is.  The iOSDevcamp About page goes on to say:

The event was initially inspired by BarCamp, SuperHappyDevHouse, and MacHack, to develop Cocoa Touch and web based applications for iPhone and iPod touch. Out-of-town guests are always welcome.  Attendees include iOS developers, web developers, UI designers, entrepreneurs and testers, all working together over the weekend. Development projects include both solo and team efforts. While some attendees wish to work solo during the event, we encourage attendees to team up, based on expertise, to work in ad-hoc project development teams. All attendees should be prepared to work on a development project during the event.

Click to read the complete article on the PayPal X Developer Network including a link to register for the event.

Key takeaways from alternative payment systems series

A while back I asked you for input as to which alternative payment systems you’d like to see compared to PayPal.  Thanks to some great feedback from community members, I was able to map out and write a six part series.

This series examined the following alternative systems:

https://www.x.com/servlet/JiveServlet/downloadBody/3666-102-1-4069/20110527_article_googleSM.jpg

The final article in the series summarized and cross-compared each of the systems with each other and the PayPal X Platform.  It included a table of key features, availability information, pricing, and other details important for developers and merchants considering their payments options.  Please note that the table appears clipped in the HTML version in many browsers; to see the full thing, you can view it in the PDF version of the article (click here to access the PDF).

I’ve also created a bit.ly bundle summarizing and linking to all six articles in the series (available here).

If you read the entire series, you will understand the major payment system options available to you and be able to make recommendations on which system(s) would be appropriate for specified sets of payments requirements.

Click here to read the complete post on the PayPal X Developer Network including the key takeaways from the series.

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

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

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

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
Facebook Credits Worldwide 30% Facebook platform purchases only No, except for some Embedded Payments type functionality For credit purchases only Yes Debit gift cards No JavaScript Test users supported Yes (Facebook JavaScript SDK) Only available on Facebook platform pages
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.

Alternative Payment Systems, Part 5: Square and Intuit GoPayment

This is the fifth installment of 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, and part four examined Dwolla.

This time we’re going to consider two leading mobile card reader options, solutions from Square (@square) and Intuit (via their GoPayment system, @gopayment). We’ll look at what both solutions provide from merchant and consumer perspectives, where to go to learn more about each, and how they compare with the PayPal X Platform and solutions including PayPal’s recently purchased FigCard.

Mobile payment options

The mobile wallet is on fire lately. Though everyone involved in payments seems to agree that paying with mobile phones and tablets is on the rise, they each seem to have their own spin on what solutions will win out in the long run. Before we dive into the specifics of the mobile card reader approach taken by Square and Intuit, let’s do a very quick review of the space so you can see where card readers fit in overall.

As I wrote in a January 2011 blog post on “Credit cards versus the mobile wallet“, credit cards and cash rule the offline payments world for now. Today’s businesses must accept these more traditional methods of payment while they consider and explore additional mobile payment options. But traditional card readers are tied to a given location via landline connections, require dedicated lines, and are simply not amenable to svelte, mobilized businesses.

Square and Intuit understand the opportunity in these problems. They are targeting the sweat spot of merchants that need to accept credit cards in a flexible, handheld, take-em-where-you-got-em way right now. They do this by providing merchants with free card readers that attach to popular mobile phones and tablets. These mobile devices are the brains of the system; payments are processed using on-device apps and transmitted using the wireless data access built into the device itself. Physical location is irrelevant as long as a data connection is available. This gives merchants the flexibility to accept traditional credit card payments wherever and whenever they want for simple to understand fees. More details on Square’s and Intuit’s implementations below.

What other options exist? PayPal is supporting a number of avenues for mobile payments both online (e.g. Mobile Express Checkout, or MEC, for any web browser enabled device and Mobile Payments Libraries native apps for iPhone and Android devices in particular) and off (from old school SMS based payments to Square and Intuit competition from their very smart purchase of FigCard). Since PayPal enables funding of your account via bank transfers and credit cards, you have cash and credit options through their system. And you have other players preparing to launch physical solutions including Google (heavily in the NFC-based mobile wallet camp), Isis (also built on NFC technology), and card.io (another credit card oriented solution; they “scan” card data via image capture rather than a mobile reader).

While it’s still unclear which online and/or NFC-based “wallet” may dominate in the future, it is clear that credit cards aren’t going away anytime soon. So no matter which other mobile payment solutions one considers adopting, most businesses do still need a credit card processing capacity, thus ensuring customers for the likes of Square and Intuit for quite some time to come.

Getting started with Square and Intuit GoPayment

Square has a straightforward homepage that immediately gets to the heart of the matter: Signing up to get a free card reader and starting to accept credit cards couldn’t be simpler.

The Square site also provides videos showing examples of their systems’ use as well as more information on Square’s related Register (turns an iPad into a card processing, receipt sending, and report crunching terminal all rolled into one) and Card Case (billed as “the friendly neighborhood way to pay”, this feature is meant to drive customer loyalty by enabling them to pay with a tab, find local deals, browse current menus and daily specials, and store digital receipts) applications. Square is clearly swinging for the fences when they claim they are for “everyone” (no business is too small or too mobile).

Key Square features:

  • Free credit card reader – plugs into audio port on Android, iPhone, iPad, and iPod Touch devices
  • Transparent pricing – 2.75% per swipe fee for all credit cards (Visa, MasterCard, American Express, and Discover); 3.5% + $0.15 per keyed in transaction
  • Next-day payout – funds are automatically paid out to your bank account daily

You can learn more about Square’s distribution channels and strategy in my related blog post “Who will corner the market on mobile card readers?“.

Similarly Intuit’s GoPayment site is structured around extreme simplicity and low cost.

GoPayment’s features are also clearly designed to make sense for just about anybody interested in accepting credit cards via mobile device:

  • Free card reader option – works with Android, iOS, and Blackberry devices (they also offer a combination card reader and receipt printer device for a fee)
  • Two tier pricing – 2.70% per swipe and 3.70% for keyed transactions (same set of card accepted as Square above) on the no-monthly-charge “Low-Volume Plan”; 1.70% per swipe, 2.70% per keyed on the $12.95/month “High-Volume Plan”
  • 2-3 days for payout – funds paid into your bank account

So both Square and Intuit intend for their mobile payment systems to be easy and (relatively) inexpensive for any medium or large business. And maybe for a lot of small fries like me, too!

Click here to read the complete article on the PayPal X Developer Network including comparisons of Square and Intuit GoPayment to PayPal offerings.

Design a site like this with WordPress.com
Get started