> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/integration/mobile-sdk.md). # Mobile SDK Accept payments through SEB E-commerce Payment Gateway in your mobile app with minimal code setup. The SDK handles the payment steps that take place on the device: it opens the checkout, supports hand-offs to banking apps and digital wallets, supports EMV® 3-D Secure, encrypts card data when you use a native card form, and returns one consistent payment result to your app. ### How the integration works Mobile SDK is a client-side library that works together with your backend. Your server creates the payment, and your app receives the values it needs to start the payment flow: * `paymentId` - the payment identifier; * `verificationKey` - the verification key obtained from the checkout link; * `checkoutRedirect` - the checkout link. Your app then passes these values to the SDK. The SDK presents the payment interface, guides the shopper through the payment flow, and requests the final payment status through your backend. {% hint style="info" %} Never embed shop secrets or OAuth 2.0 client credentials in a mobile app. Store and use them on your backend only. {% endhint %} Your backend also remains the source of truth for the payment status and order fulfilment. The result delivered to your app is intended to show the shopper what happened. Do not approve or fulfil an order based only on the SDK callback: trigger fulfilment on your backend from the platform's notifications. ### Available payment flows The documentation describes two ways to accept payments. Both flows use the same payment, backend contract, and result model. #### Hosted Checkout The SDK opens the ready-made checkout page inside your app. Use this flow when you want to offer all available payment methods without handling card data in your own UI. Hosted Checkout can support card payments, Pay by Bank, Click to Pay, digital wallets, and EMV® 3-D Secure. Your app listens for the shopper's return through the configured return URL, but it does not receive card data. #### Native card form You build the card form in your app's UI. The SDK encrypts the entered data on the device, starts the payment session, and handles 3-D Secure. Use this flow when the payment form must match your app's design and user experience. Card-data protection requirements still apply: pass card data to the SDK and keep it out of your logs, analytics, and other app systems. ### What this documentation covers Use the sections below according to your integration stage: 1. **Distribution** - download the SDK archive for your platform and verify its checksum. 2. **iOS SDK / Android SDK** - open the documentation for your platform. 3. **Overview** - learn what the SDK does, what it does not do, and what it requires. 4. **Installation** - add the SDK to your project. 5. **Quickstart** - make your first payment in Sandbox. 6. **Using the SDK** - configure Hosted Checkout or a native card form and handle the result. 7. **Guides** - learn about backend integration, error handling, and security. 8. **Reference** - find the configuration, request, result, and public API definitions. ### Environments and requirements The SDK supports two environments: * **Sandbox** - for development, testing, and integration validation; * **Production** - for live payment processing. For iOS, the current documentation specifies iOS 15.0 or later, Xcode 15 or later, Swift or Objective-C, and UIKit. A bridge is provided for SwiftUI. The SDK has no third-party dependencies and bundles no resources. SDK archives are distributed from this documentation site as ZIP files, rather than through a public package repository or registry. Verify the archive against the matching `.sha256` file before installing it. ### Before you start Make sure you have: * a backend that creates payments through SEB E-commerce Payment Gateway; * shop and OAuth 2.0 client credentials configured on your backend; * a backend endpoint for checking the payment status; * a return URL that brings the shopper back to your app; * access to Sandbox and test payment details. For your first integration, start with Hosted Checkout. It requires minimal code and lets you verify the complete payment flow quickly. After your first successful Sandbox payment, continue with the flow you need, then review result handling, failure recovery, and security requirements. ### Important: handling the payment result The SDK returns one of four outcomes: succeeded, failed, cancelled, or unresolved. An unresolved outcome does not necessarily mean that the payment failed. For example, the payment may still be processing, or the app may have lost connectivity. If the payment status cannot be determined on the device, ask your backend for the current status. In every case, make the final decision about order fulfilment on the server. Start with [Distribution](/integration/mobile-sdk/distribution.md), then open the page for your platform and complete [Quickstart](/integration/mobile-sdk/ios-sdk/quickstart.md) for iOS SDK and Quickstart for Android SDK. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/integration/mobile-sdk.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.