> 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/ios-sdk/overview.md).

# Overview

Learn what the iOS SDK does, what your backend must do, and what the SDK requires to run.

The **iOS SDK (EGWPay)** is a native Swift library for collecting payment from a shopper inside your own app.

It covers the part of a payment that has to happen on the device: showing the checkout page or the card form, following the shopper through EMV® 3-D Secure, noticing when the payment run is over, resolving the payment status, and handing your app one result.

***

## What the SDK does

* Presents the hosted checkout page in a [`WKWebView`](https://developer.apple.com/documentation/webkit/wkwebview) and watches for your return URL.
* Hands non-web navigations to the system, so an open-banking flow can hand off to a bank's own app and come back.
* Encrypts card data on the device and drives the card session when you use your own card form.
* Presents an EMV® 3-D Secure challenge and captures its result.
* Resolves the final payment status and delivers exactly one result to your app.

## What the SDK does not do

**The SDK does not initiate payments.** Initiating a payment authenticates with OAuth 2.0 client credentials using your shop client secret, and that secret must never ship inside an app: anyone holding it can create payments against your shop. Payment initiation belongs on your backend.

{% hint style="info" %}
The SDK is a client-side library. Your backend creates the payment and remains the authority on whether it completed. See [Backend integration](/integration/mobile-sdk/ios-sdk/guides/backend-integration.md).
{% endhint %}

***

## Your responsibilities

The SDK handles the on-device part of a payment. Your application remains responsible for:

* Initiating the payment from your backend and passing the resulting values to the app.
* Protecting your client credentials.
* Registering the return URL your app is reached at.
* Managing your order lifecycle, and fulfilling orders from your backend rather than from the app.

{% hint style="danger" %}
**Treat the SDK's result as a UX signal, never as authorisation to fulfil an order.** A device can lose connectivity between the payment completing and your app hearing about it, so a shopper who paid may still see a failure on screen. Hang fulfilment off the notifications the platform sends your backend.
{% endhint %}

## Entry points

| Entry point      | Method                                      | Use when                                                                          |
| ---------------- | ------------------------------------------- | --------------------------------------------------------------------------------- |
| Hosted checkout  | `startPayment(_:from:completion:)`          | You want every payment method the platform offers, with no card data in your app. |
| Native card form | `startCardPayment(_:card:from:completion:)` | You want card details collected in your own UI, styled by your own design system. |

Both entry points run against the same payment. There is no separate card initiation, so an app that offers both makes one backend call and lets the shopper choose.

***

## Requirements

| Requirement       | Value                                          |
| ----------------- | ---------------------------------------------- |
| Platform          | iOS 15.0 or later                              |
| Language          | Swift, callable from Objective-C               |
| UI framework      | UIKit, with a bridge for SwiftUI               |
| Toolchain         | Xcode 15 or later                              |
| Dependencies      | None                                           |
| Bundled resources | None. All SDK user interface is built in code. |

The public API is Objective-C compatible throughout, so Objective-C applications are supported without a bridging layer. See [Objective-C and SwiftUI](/integration/mobile-sdk/ios-sdk/using-the-sdk/objective-c-and-swiftui.md).

***

## Environments

The SDK supports both Sandbox and Production.

| Environment | Purpose                                          |
| ----------- | ------------------------------------------------ |
| Sandbox     | Development, testing, and integration validation |
| Production  | Live payment processing                          |

Environment selection is performed by configuring the appropriate base URLs. The `environment` property on `Configuration` is informational: it changes no URL, and exists so your own code and logs can tell one environment from the other.

***

## Versioning and support

The SDK follows **MAJOR.MINOR.PATCH** versioning and is currently pre-1.0, which means a **minor** release may change the API.

Pin an exact version, or allow up to the next minor. Do not allow up to the next major.

***

## Distribution

The SDK is delivered as a checksum-verified ZIP archive, not a package-registry release. Verify the archive, unpack it, and reference it from your project with Swift Package Manager, CocoaPods, or the prebuilt XCFramework. See [Installation](/integration/mobile-sdk/ios-sdk/installation.md).


---

# 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/ios-sdk/overview.md?ask=<question>&goal=<user_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.