PayPal iOS SDK

# PayPal iOS SDK Welcome to PayPal's iOS SDK. This library will help you accept cards, PayPal, Venmo and alternative payments in your iOS app. **The PayPal iOS SDK permits a deployment target of iOS 12.0 or higher**. It requires Xcode 12+ and Swift 5.1+. ## Supported Payment Methods  - [Credit Cards](#) - [PayPal](#) - [Pay with Venmo](#) - [Apple Pay (iOS)](#) - [Google Pay (Android)](#) - [Samsung Pay (Android)](#) - [APMs/LPMs (iDEAL, giropay, etc.)](#) ``` OPTION 1: config = PaymentConfig(token: "TOKEN") cardClient = CardClient(config: config) venmoClient = VenmoClient(config: config) cardClient.checkoutWithCard(cardRequest: ...) ``` ``` OPTION 2: client = PaymentClient(accessToken: "REAL-CLIENT-ID") cardClient = CardClient(pyplClient: client) venmoClient = VenmoClient(pyplClient: client) cardClient.checkoutWithCard(cardRequest: ...) ``` ``` OPTION 3: merge request details with client venmoClient = VenmoClient(client: client, otherParamsNeededForVenmo...) paypalClient = PayPalClient(client: client, returnUrl: ...) ``` ### Brainstorming Session 2 (7/20/21) - Want to use the current client pattern that is used by the BT SDK - Concerns of fetching Client Config taking too long before payment method usage - Can we synthesize any portion of the mobile SDKs from the orders APIs? Spend less time on networking and more on merchant facing integration - If relying on orders API, what is / is not supported? - Have hardcoded postman requests that help define SDK interface - What endpoints will we be targeting with different features? - What is the MVP? #### Analytics - Amplitude ? - Limitations in # of events. Could be an issue. - Lighthouse ? - No more Arachne - Can support access Amplitude & Lighthouse logs? Would we need to do additional work to support that transition - Should we break up events on development vs product level? - Is breaking up the events b/w two different places more confusing than one central location? ### Brainstorming Session 1 - Hello. Each take a bullet. - Logical separation between payment components and UI components - - [Plugins](https://martinfowler.com/eaaCatalog/plugin.html) with modularity? - Localization, is there a lean way of doing this? - How can this be made into a simple integration experience? Is it possible to do this in under 10 (or other arbitrary number) lines of code for merchants? - CI/CD - How are we going to publish these SDKs? - Cody: Use GitHub Actions? Deploy to Maven Central often? - Steven: Jetpack strategy you deploy alpha builds often and collect feedback, then can cut a release. [Jetpack All Channel Release Notes](https://developer.android.com/jetpack/androidx/versions/all-channel) show from a high level Jetpack component semantic versioning scheme (alpha, beta, rc). - David: During development, let's test out CI & release process so we can learn a lot. - Tim: Snapshot builds are a good option w/ retention policies. Builds kick off "develop" branch and get feedback before an official release. - Sammy: Simplifying is great. GitHub Actions work great w/ BT SDK. - Aki: Let's incrementally automate things as it annoys us as we get closer to GA. - Cody: If we can automate the changelog w/ commit messages, that'd be great. - Modularization or packaging. Is there a core/common package? - How do these components communicate w/ each other? - What languages are we using? Kotlin and Swift? - How will internal teams surface components through the SDK? - Are there standards and best practices for how to contribute to it? - Open-source ftw ftw - Standard way of communicating between SDK and merchant application - develop in the open vs develop on PayPal github + publish to public github - What inputs do we need from merchants? client id, other token? - Is it possible to consolidate EC / BA / order ID into a single token type that we consume? - Will the structure of the SDK be determined by the underlying product offering? e.g. PayPal, Hyperwallet etc - Will there be a strict alignment of the SDK api across each platform? Will there be flexibility to take advantage of the strength of each underlying platform - What is the smallest feature set we can launch with? - What are the security concern when we start open sourcing? - Support UI components in storyboard (iOS) - Merchant integration entry point / authorization - client tokens, tokenization keys, something else? - Are we using BT as the base or are we starting from scratch? - Will BT and BT drop in be combined? are we keeping drop in SDK separated? - How limited is our Mobile SDK API design by the existing JS SDK? Is that SDK also morphing? - Develop in public repos +100 - Defining intial scope of the SDK - Setting the stage for modularity from the start - Focusing early on on unit & integration testing strategy b/w modules in each SDK - Establish style guides & consistent patterns throughout each SDK; set this stage from the start - Persist Braintree's deprecation policy! Keep it alive :)