Tag Archives: Objective-C

Inside the PayPal Mobile SDK 2.0


We’re pleased to announce the 2.0 release of the PayPal Mobile SDK. This major version update introduces important new capabilities as well as improvements under the hood. In this post we’ll highlight a few of the major changes, with some narrative about how we got here.

TL;DR? Check out the PayPal Developer Docs for an overview. In-depth docs and SDK downloads can be found in the PayPal iOS SDK on GitHub or PayPal Android SDK on GitHub.

SDK Focus

In writing the first version of the Mobile SDK last year, our team focused on four high-level values:

  1. Fast and delightful user experience making payments
  2. Simple, equally delightful developer experience taking payments
  3. Consistent, bulletproof quality across devices and platforms
  4. Opendirecttechnical communication between developers (you!) and us

To keep the bar high, we limited the first SDK release to only single payments, using PayPal or credit card (with card.io scanning). While the developers looking for a basic drop-in payment library have found the first version helpful, we knew a complete native mobile payments solution needed to offer more. So, without losing focus on simplicity, quality, and community, we’ve written the 2.0 Mobile SDK to enable seamless commerce in modern, sophisticated mobile commerce and marketplace apps.

Future Payments

The marquee feature in 2.0 is Future Payments. With Future Payments, developers can gather payment information from a customer just once, and use it to process all future payments from that customer. If you’ve added PayPal as a payment option in Uber, then you’ve used it. Uber piloted this feature with us to provide their customers with a PayPal payment option that’s fast and simple. With 2.0, we’re opening up Future Payments to all mobile developers.

So how does it work? To identify who should get paid, you give the SDK a public Oauth2 client_id as input. The SDK then authenticates a user and asks for payment authorization; it returns a short-lived OAuth2 authorization code. Your app sends that authorization code to your servers. Your servers use this code to request OAuth2 access and refresh tokens with the future_payments scope. You can use the access token right away to charge the user, and store the refresh token for the future. Any time that you need to make payment API requests for this user in the future, you can exchange that refresh token for an access token, and you’re off to the races — no need to bother the user again.

Phew! It sounds more complicated than it actually is, and the SDK includes step-by-step integration guides:

Auth & Capture

One frequently requested feature is the option to decouple authorization of a payment from capture at a later time. This is a standard capability offered by credit card gateways. It is useful, for example, when shipping physical goods – you can authorize your customer’s payment when the order is placed, then later capture the funds only when the goods actually ship.

The 2.0 SDK uses new, flexible PayPal REST payment APIs – you can create a payment with either a sale or authorization intent. Thanks to the improved APIs, our team was able to add Auth/Capture support with only minor code changes. And, notably, the intent setting works identically for PayPal and credit card payments.

REST and OAuth 2.0

As PayPal continues to optimize mobile-first platform offerings, the PayPal Mobile SDK team works closely with counterparts in the API teams to set the roadmap and nail the integration with the OAuth2 Identity services and REST Payments API.

The 2.0 SDK now uses only the new PayPal APIs. Migrating to these APIs was critical to making the 2.0 SDK a reality. Now that we’re on the new stack, the SDK is well positioned to gain new capabilities in pace with the platform. We look forward to adding further improvements!

Check it Out

Learn more about the 2.0 PayPal Mobile SDKs by checking out the PayPal Developer Docs. When you’re ready to take a look at the APIs, sample code, README, and integration docs, head on over to GitHub:

We’d love to hear your integration experience and feedback.

About the PayPal SDK Team

We’re a distributed team (Portland, Austin, San Jose) that creates great tools for developers and delightful experiences for their users. When not releasing sweet PayPal SDKs, we can be found variously drinking copious amounts of coffee, writing science fiction, biking long distances, snuggling with a Ziggy, or driving down the California coast. Want to get in touch or see what we’ve worked on? Find us on GitHub: DaveBrentTomMattJeffJuwonAviJosh, AbhijeetMikeAvijit, Roman, and Bunty.

A small thought on Objective-C categories


I recently hit what seems to me a cute little example of how Objective-C Categories might be used. If you are unfamiliar with them, the Apple docs are good. They are often used to extend pre-existing classes from Apple i.e. where you don’t have the source code.

I had what could be termed a Domain Model in an iOS project. It did not know anything about the user interface, naturally. There came a point where the Model was to be connected into the UI. The UI was already written to use a C-style enumeration of Model types (when the UIPickerView presented different values to choose from, and the UI code handled the user’s pick).

The Model had no internal need for a categorized, constrained list of the domain types. If you have seen things like the expression problem or a visitor design, you will probably have thought about where to put code. It is not always an easy thing to decide. In my case, the Model was a fine fit for regular OO where you can add new types implementing a standard set of methods, rather than something ‘procedural’ or ‘functional’ where you have a fixed set of types and are more interested in adding new methods for all of them.

Anyway, I simply added an enumeration directly in the Model layer. Each Model class exposed a read-only property of that enumeration type. Problem solved; the UI could get on with life. There are times when you cannot or don’t want to boil the ocean.

But if one had a strong urge to avoid putting UI knowledge inside the base level of the Domain, how to do it? Something that came to mind was to use Categories: extend the Domain classes with the enum property for UI consumption, leaving the base Domain classes alone. Given how the project was already going, the overhead would be an extra pair of files (one .h, one .m) per Domain class, of which there are only 3 since it is a small R&D project. Each of those files would be pretty succinct. Additionally, the UI files would change their imports from e.g. “DomainModelClassX.h” to “DomainModelClassX+TypeEnumeration.h”.

The advantage is that the base Domain code still doesn’t know anything about this enumeration, while the UI gets what it wants. Disadvantages include there being more files in the project (not an inherent evil, but something to be wary of); that the UI code needs to know the right files to import; and that concerns are split across several files (future developers might find this design obscure vs. the enum-in-Model approach). When I consider that the Categories could pull out further UI-Model specific code like display strings for the various Model types, I’m even more attracted to the Category approach. It seems like a pretty nice way to make the two layers meet.

There are of course other ways to wrestle with all this in Objective-C, let alone other languages. Scala, Perl, and PHP support traits. C# supports extension methods. Lisps support multimethods. (You could probably even perversely use an Aspect Oriented Programming library to address the issues.) Some of those languages also offer stronger static typing than Objective-C in this arena, if that floats your particular boat.