Skip to main content

Client SDKs

Stitch client SDKs run in your app or browser. They collect card details and digital wallet tokens in PCI-safe controls, attach a device fingerprint where required, and return payloads your backend forwards to the Stitch GraphQL API.

This section is organised by product. Each page shares one client sequence diagram for that product, then documents every supported platform in tabs.

SDK capabilities​

CapabilityPage
Secure FieldsSecure Fields for card payments
Digital walletsDigital wallets
FingerprintingFingerprinting with Stitch SDKs

Install via Cloudsmith​

All Stitch client-side packages (Web, iOS, Android, Flutter, React Native, and related fingerprint dependencies) are distributed through Cloudsmith. Clients use one entitlement token across repositories; registry configuration depends on the package manager.

During onboarding, Stitch provisions:

  1. Registry access for your organisation (Cloudsmith entitlement / read credentials).
  2. Package coordinates and versions to install (npm, Swift Package, Maven, pub, and any transitive fingerprint packages).
  3. Install instructions for your package managers: how to add the Cloudsmith registry, authenticate, and pull the pinned versions.

Use those Cloudsmith instructions as the source of truth for registry URLs, tokens, and version pins. After packages resolve, follow the product page tabs for configuration and usage.

For native fingerprint dependencies on Android and iOS, follow Fingerprinting setup. The guide covers local development, CI authentication, and migration from GitHub.

How SDKs work with your backend​

Client SDKs own the in-app / in-browser part of a payment. The Stitch GraphQL API owns the trusted server part. Typical handoff:

  1. Your app renders Secure Fields or a wallet button from the Client SDK.
  2. The customer enters card details or authorises a wallet sheet inside the SDK surface.
  3. The SDK returns a client payload (encrypted card fields or a wallet token, plus a device fingerprint when available). Your app never sees raw PAN/CVC.
  4. Your app POSTs that payload to your backend.
  5. Your backend maps the payload into initiateTransaction (or a related mutation) and calls the Stitch GraphQL API with a server credential.
  6. Stitch returns a transaction id, status, and optionally an interactionUrl (for example 3DS). Your backend drives status, webhooks, and any follow-up.

In short: the Client SDK supplies the customer interaction and the payloads your server must pass into the Stitch API. Product-specific server guides: Card once-off · Card tokenization · Web Transactions · Mobile Transactions.