Merchant Integration Pattern

Client Classes

Client classes are the main entry point for merchants when integrating with our SDK. Merchants are expected to create and maintain an instance of the Client class. There should be a single merchant facing Client for each module.

Example Client class: https://github.com/braintree/braintree_android/blob/main/PayPal/src/main/java/com/braintreepayments/api/paypal/PayPalClient.kt

Launcher Classes

For modules that launch an external payment flow (either app switch or browser flow) we provide the merchant with a Launcher class that handles the launching and receiving a result from the payment flow.

Example Launcher class: https://github.com/braintree/braintree_android/blob/main/PayPal/src/main/java/com/braintreepayments/api/paypal/PayPalLauncher.kt

Internal Classes

All non merchant facing types must be hidden from the public SDK interface. There are different strategies used for Kotlin and Java.

Kotlin

All non merchant facing classes and functions must be marked with the internal Kotlin keyword. This will scope the class or function to the containing module.

There are cases where Kotlin types need to be shared across modules. The @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP) annotation should be used to scope the type to the Android SDK’s library group.

Java

For Java classes and methods, the @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP) should be used. Please note that new classes that are added to the SDK should be written in Kotlin.