SDK Lifecycle and Deinitialization

deinit() ends the SDK's current setup so your app can initialize it again without restarting. Use it when replacing the API key, changing environments, resetting the merchant session, or testing initialization and sign-in again. It is available in iOS SDK 1.0.21 and later in UAT and Production.

This is an explicit Koard SDK method. Calling KoardMerchantSDK.shared.deinit() does not destroy the Swift singleton or require your app to release it.

Choose the right cleanup operation

Operation	What it does	What remains
`deinitializeCardReader()`	Drops the reader session, resets status to `.notReady`, and recreates the reader	SDK configuration and merchant authentication
`logout()`	Clears merchant authentication, saved location/session data, the reader session, and its cached token	SDK initialization and its API key
`deinit()`	Performs logout, clears the API-key provider and in-memory key, and sets initialization to `false`	The shared SDK object and device enrollment

Use logout() for an ordinary sign-out. Use deinit() when the next session must start with a fresh SDK configuration. Neither operation deletes Koard transaction records or revokes the API key on the server.

What deinit does

The SDK calls logout() first. Logout clears the merchant token and SDK-owned session/location storage, drops the reader session, resets reader status to .notReady, and invalidates the cached card-reader token. Deinit then clears the API key and marks the SDK uninitialized.

The method is synchronous and does not throw. It resets SDK state; it is not a payment cancellation or refund operation. Call it after any active payment and reader preparation have finished.

Unlike Android deinit, iOS deinit does not unenroll the device or remove its enrollment key/certificate. It also does not unlink the merchant's Apple Tap to Pay account. Check account linking and reader readiness again after signing in; preserved enrollment does not mean a new merchant is linked or ready.

Check initialization state

import KoardSDK

let sdkInitialized = KoardMerchantSDK.shared.isInitialized

isInitialized is a Boolean property, not a function. It returns false before initialize(options:apiKey:) and after deinit(). Read it to show the SDK's configuration state on a login or settings screen.

Check isAuthenticated for merchant sign-in and status for reader readiness separately. Initializing the SDK does not authenticate a merchant or prepare the card reader.

Deinitialize and initialize again

import KoardSDK

@MainActor
func deinitializeSdk() {
    KoardMerchantSDK.shared.deinit()
    assert(!KoardMerchantSDK.shared.isInitialized)
}

@MainActor
func initializeSdk(apiKey: String, options: KoardOptions) {
    let sdk = KoardMerchantSDK.shared
    if !sdk.isInitialized {
        sdk.initialize(options: options, apiKey: apiKey)
    }
}

Pass KoardOptions(environment: .uat, loggingLevel: .error) for UAT or .production for Production, together with the matching API key. Your app must supply the key again from its existing configuration or credential mechanism. Deinit clears the SDK's copy, not the app's configuration.

Calling initialize() while already initialized leaves the current configuration in place. To replace it, complete deinit first and then initialize. Keep lifecycle actions sequential and prevent new payment/preparation work during the transition.

After reinitialization, log in and select an active location, check account linking, and prepare the reader before accepting payments. There is no automatic restoration of the old merchant login after deinit.

Verify the flow in the demo

In the internal iOS demo with lifecycle controls:

Open Settings → Deinitialize SDK after completing any payment.
The app returns to Login and displays SDK Deinitialized.
Tap Initialize SDK. The demo uses the API key retained in its own service configuration and enables the credential fields.
Sign in, select the location, and check linking and reader readiness before the next payment.

Build the demo with the UAT or Production scheme and its matching Config.plist entry. The demo's retained test key lets you repeat the flow without rebuilding; it does not mean deinit kept the SDK's credentials.