Terminal

The SCPTerminal singleton object exposes an interface for discovering readers, connecting to a reader, creating payments, and saving card information for later use.

Before accessing the singleton object using the shared property, you must initialize the SDK by calling initWithTokenProvider: with an object that implements the SCPConnectionTokenProvider protocol. This object should authenticate with your backend, then fetch the secret from a freshly minted ConnectionToken.

The SCPTerminal singleton can only be connected to one reader at a time, and can only perform one operation at a time. As a general rule, make sure the completion handler of one operation has been called before calling another operation from within your app.

The Stripe Terminal SDK sends updates to your app by using the delegate pattern. You may want multiple views in your app to respond to these delegate calls. We recommend creating a central delegate announcer which broadcasts all delegate calls to views and ViewControllers that register themselves with that announcer. We have an example implementation of a TerminalDelegateAnnouncer as part of our example application.

Before integrating the SDK, you should create an endpoint on your backend server that creates a new connection token via the Stripe Terminal API. The connection token is used by the SDK to connect to a reader.

An overview of the lifecycle of a connection token:

• When Stripe Terminal is initialized, the SDK attempts to proactively request an connection token from your backend server.
• The SDK uses the connection to connect to a reader.
• Subsequent calls to connect require a new connection token. If you disconnect from a reader, and then call connect again, the SDK will need a new connection token from your backend server.

We suggest making your application’s API client conform to this protocol.

Implement this protocol to handle connection and payment updates from the Stripe Terminal iOS SDK.

Possible reasons for Bluetooth reader disconnects.

Implement this protocol to handle callbacks when the SDK is performing actions related to offline mode.

Provides offline status details for the connected reader and the SDK.

The various log levels for the SDK.

An object representing an action that can be canceled.

The current version of this library.

The possible network connection statuses for the SDK.

Base class for all builders. Defines the build method that all builders must implement.

Contains configuration information relevant to collecting non-payment data.

The CollectDataConfigurationBuilder is used to create a CollectDataConfiguration object.

The type of data to collect.

Represents non-payment data collected using collectData.

Represents non-payment data collected using collectData with the magstripe interface.

Represents non-payment data collected using collectData with the NFC interface.

Configures localization of API error messages returned through SCPApiError.message.

API errors surfaced through NSError‘s SCPErrorKeyStripeAPIError will have their SCPApiError.message translated to the resolved locale.

For smart readers, reader software version 2.43 or later is required for localization.

Note: The scope of localization may expand in future SDK releases. For example, NSError.localizedDescription and other SDK-originated strings may also be localized. Integrations should avoid relying on error message content for application logic. Use error codes such as SCPError and SCPApiError.code instead.

Localizes API error messages to a fixed locale tag.

The locale tag must conform to the format language[-script][-region] where:

• language is a 2-3 letter ISO 639 code (e.g., “en”, “fil”)
• script (optional) is only “Hans” or “Hant”
• region (optional) is a 2-letter ISO 3166-1 alpha-2 code (e.g., “US”) or a 3-digit UN M.49 code (e.g., “419”)

If the locale is not supported by Stripe’s localization infrastructure, error messages will fall back to English (en-US).

A builder class for SCPHardcodedLocaleConfig. The locale tag is validated by build:.

Reports the outcome of localizing an SCPApiError.message.

• requestedLocale reflects the locale the SDK sent in the Accept-Language request header.
• resolvedLocale reflects the locale the message was localized to, taken from the Content-Language response header (defaults to en-US if the header is absent).

The two may differ when the requested locale is not supported — in that case, the server falls back to en-US.