# 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

<!-- Which payment methods are required for MVP in Q1 2022? -->

- [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 :)