Mobile Checkout SDKs

• Credit/debit card payments are handled by the SDKs and allow you to keep a low PCI-DSS A rating
• Direct payment methods (e.g. credit/debit cards, SEPA)
• Real-time input validation
• Credit/debit card SmartSwitch: certain credit/debit card schemes are offered as one option on the payment page; the form auto-detects the scheme based on the PAN entered by the end customer
• Redirect payment methods (e.g. PayPal, Sofort) by using an external browser
• Delayed Payment submission flow (Android Checkout SDK only)
• Regular/recurring account registration
• Custom theming: match the look & feel of the payment page to your shop application

iOS Checkout SDK

• Review the Mobile Checkout SDKs section for information relevant for both the Android and iOS Checkout SDK.
• Review the MOBILE NATIVE integration documentation. This integration scenario is required for the iOS Checkout SDK. See Mobile Native reference.
• Refer to our Github resources here.

The iOS Checkout SDK comes with an example application, located in the /ExampleCheckout folder. This is the version for the Swift language. To get the example for Objective-C, go to the /ExampleCheckout-ObjC folder.

To run the example application, run pod install in that folder and next open the ExampleCheckout.xcworkspace

1. Install the iOS Checkout SDK in your app
2. Create a payment session and obtain the links.self URL from the LIST object.
3. (Optional) Apply your custom theming to the payment page.
4. Initialize and display the payment page using the links.self URL.

target 'ExampleCheckout' do
  pod 'PayoneerCheckout', '~> latest_version'
end

@objc public class PaymentResult: NSObject {
  public var operationResult: OperationResult?
  public var errorInfo: ErrorInfo?
  /// Contains value if something went wrong inside framework. In the most cases it would contain `InternalError` type.
  public var cause: Error?
  // MARK: Computed variables
  /// Contains result info from `operationResult` or `errorInfo`
  public var resultInfo: String
  /// A reference to `Interaction` object inside `operationResult` or `errorInfo`.
  public var interaction: Interaction
}

Callback handling

This is an important step of the framework's configuration. If you don't handle callbacks, you will receive the  VERIFY interaction codes from the framework instead of the actual result, and you will have to check payment results manually.

In some circumstances, the framework could open the SFSafariViewController browser window. This is normally done to allow the customer to complete their payment on the 3rd party website (e.g. in PayPal, or for any credit/debit card 3DS authorization). When the interaction on the 3rd party website is complete, a redirect with a specially prefixed URL will be called. The redirect should be handled by your application and routed to the framework.

To route such redirects to the framework:

1. Define your application ID in the callback.appID property in the payment session.

   {
     "callback": {
       "appId": "com.payoneer.checkout.examplecheckout"
     }
   }

2. Add the application ID as the new URL scheme in your application's configuration by adding the .mobileredirect suffix. The resulting URL scheme will look like the following: app.identifier.mobileredirect.
3. Route the information received from a redirect by sending a notification to the framework using NotificationCenter. See the Swift example:

   class AppDelegate: UIResponder, UIApplicationDelegate {
     func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
         NotificationCenter.default.post(name: .didReceivePaymentResultURL, object: url)
         return true
     }
   }

If you use Objective C, and support multiple iOS versions, add both code snippets :

Objective-C (AppDelegate.m), iOS 12

- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    [NSNotificationCenter.defaultCenter postNotificationName:NSNotification.didReceivePaymentResultURL object:url];
    return YES;
}

Objective-C (SceneDelegate.m), iOS 13+

- (void)scene:(UIScene *)scene openURLContexts:(NSSet *)URLContexts {
    NSURL *url = URLContexts.allObjects.firstObject.URL;
    if (url != nil) {
        [NSNotificationCenter.defaultCenter postNotificationName:NSNotification.didReceivePaymentResultURL object:url];
    }
}

Android Checkout SDK

• Review the Mobile Checkout SDKs section for information relevant for both the Android and iOS Checkout SDK.
• Review the MOBILE NATIVE integration documentation. This integration scenario is required for the Android Checkout SDK. See Mobile Native reference.
• Refer to the Github resources here.

• The Checkout SDK Example: it allows you to visualise payment pages quickly and debug possible results. The sources can be found here.
• The Checkout Shop Example: it shows you how you could integrate the SDK into a real shop application. The sources can be found here.

1. Install the Android Checkout SDK in your app.
2. Create a payment session and obtain the links.self URL from the LIST object.
3. (Optional) Apply your custom theming to the payment page.
4. Initialise and display the payment page using the links.self URL.

• If the resultCode is Activity.RESULT_CANCELED, it means the user closed the payment page and no further information is available. 
• When the resultCode is RESULT_CODE_PROCEED or RESULT_CODE_ERROR, the PaymentActivityResult contains a PaymentResult providing the information about the payment.

• The payment submission flow (RESULT_CODE_PROCEED) used to indicate that the payment was successful or that the user may proceed to the next step, as used in Delayed Payment Submission mode. 
• The error flow (RESULT_CODE_ERROR) used when the payment failed or an internal error occurred inside the Android SDK.