> 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/guides/security.md).

# Security

Protect credentials, card data, and transport in an iOS integration, and log safely.

Use this guide if you are reviewing an iOS integration, or building one that has to pass a review.

The rules below are requirements, not recommendations.

***

## Credentials

**Always keep the shop client secret and the OAuth 2.0 client-credentials exchange on your backend.** Never ship either inside an app. Anyone holding the shop client secret can create payments against your shop, and anything shipped in an app binary is recoverable.

The app receives only per-payment values: a `paymentId`, a `verificationKey`, and a checkout link.

**Never log or persist the verification key.** It is a client-side credential scoped to one payment and authorises the payment-scoped calls the SDK makes. It should not outlive the payment.

The SDK stores no credential, caches none, and logs none. Its status session is ephemeral.

***

## Order fulfilment

{% hint style="warning" %}
**Never treat the SDK's result as authorisation to fulfil an order.** Hang fulfilment off the notifications the platform sends your backend, and confirm state through the API before acting.
{% endhint %}

An app result is a UX signal produced on a device that can lose connectivity, be suspended, or be stopped at any moment. It tells you what to show the shopper.

***

## Card data

In hosted checkout, your app never sees card data. The hosted page collects it.

In the native card form, card data is encrypted on the device before the first network call that carries it, using RSA-OAEP-256 key encryption and AES-256-GCM content encryption in JWE compact serialization. The encryption key is fetched from the checkout host per session and is never cached across payments.

The raw card number and security code exist only in `CardInput`'s properties and in the plaintext the SDK builds immediately before encrypting. Neither is written to disk and neither is logged.

{% hint style="warning" %}
**Never put raw card fields anywhere else.** Not in your logs, not in analytics events, not in crash reports, not in your own storage, and not in any request of your own. The encrypted value is the only card-data artefact that should leave the device.
{% endhint %}

Keep the card form out of screenshots and screen recordings if your threat model calls for it, and do not re-use a `CardInput` across payments.

***

## Transport

**Certificate validation is never overridden.** The SDK does not implement any certificate-challenge handler, on any web view it creates, including the 3-D Secure challenge view. App Transport Security applies normally, and every host the SDK talks to is expected to be HTTPS.

Do not add `NSAllowsArbitraryLoads` to your app's `Info.plist`. It switches App Transport Security off for every domain in the app, including the ones carrying payment traffic.

***

## Logging

Logging is off by default. With `loggingEnabled` set to `true`, the SDK writes flow milestones through `os_log` and:

* logs URLs as `scheme://host/…` only, because checkout URLs carry the payment id and verification key in their path;
* never logs a request or response body;
* never logs card data, the encryption plaintext, credentials, or the verification key.

Apply the same discipline to your own logging around the SDK. The values you hold, `paymentId` and `orderNumber`, are payment metadata: route them the way your organisation routes payment metadata, and keep `verificationKey` and card fields out of logs entirely.

***

## Checklist

* Client credentials live on the backend only.
* The verification key is passed to the app, used, and not stored.
* Fulfilment is driven from the backend, not from the app's result.
* Raw card fields never leave `CardInput`.
* No App Transport Security exceptions in the shipped build.
* No payment values in analytics, crash reports, or third-party logging.


---

# 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/guides/security.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.