Choose an SDK
Frame ships SDKs in two layers: a client SDK for the platform your users touch (a browser, an iOS app, an Android app, a React Native app) and backend SDKs for your server. Most integrations use one of each. This page maps your platform to the right SDK and shows how the two halves fit together.
If you're already working inside one SDK, you want its reference, not this page — the cards below link straight there.
Two layers, two jobs
Frame's SDKs fall into two layers:
- Client SDKs run inside your app, where your users are. They render the UI — card input, wallet buttons, the onboarding flow — and encrypt sensitive data on the device or in the browser so your code never handles raw card numbers. There's one per platform: Frame.js, frame-ios, frame-android, frame-react-native.
- Backend SDKs run on your server. They hold your secret key (
sk_*) and own everything it authorizes — creating accounts, minting sessions, creating transfers, verifying webhook signatures. They wrap the REST API: frame-node, frame-ruby, frame-php.
How the two layers connect differs by platform, and the difference matters. Frame.js enforces a strict split: the browser holds only your publishable key (pk_*), your server holds the secret key, and the two never mix — see the Frame.js architecture page. The mobile SDKs work differently — frame-react-native, for example, runs the Frame API on-device through the frame-node SDK and is initialized with your keys directly rather than splitting frontend from backend. Check each SDK's reference for its exact setup and credential model.
Pick by where your code runs
| Your platform | Client SDK | Reference |
|---|---|---|
| Browser / web frontend | Frame.js | web-sdks/frame-js |
| Native iOS app | frame-ios | frame-payments.github.io/frame-ios |
| Native Android app | frame-android | frame-payments.github.io/frame-android |
| React Native app | frame-react-native | github.com/Frame-Payments/frame-react-native |
| Server-side backend | frame-node, frame-ruby, frame-php | backend-sdks |
You'll generally pick one client SDK (the platform your app ships on) plus one backend SDK (the language your server runs). A React Native app that talks to a Node backend uses frame-react-native and frame-node together.
Browser SDK loaded via CDN. Works with any framework or none. Reference is generated from TypeScript source.
Swift and SwiftUI networking and UI components. Ships and documents in its own repo.
Kotlin networking and UI components. Ships and documents in its own repo.
Native React Native UI for checkout, onboarding, and wallets. Networking runs through the frame-node SDK on-device.
frame-node, frame-ruby, and frame-php wrap the REST API for server-side calls. Until per-language deep docs ship, each links out to its repo; the API reference is the contract.
How the layers fit together
On the web, most flows pair both layers. A card charge is the canonical shape: Frame.js collects and tokenizes the card, your backend SDK (or a direct REST call) runs the Account + PaymentMethod + Transfer sequence with the secret key, and the browser only steps back in to clear a 3D Secure challenge with a client_secret your backend hands it. The charge confirms server-side; the browser never sees sk_*. The full sequence — including who holds which credential at each step — is on the Frame.js architecture page; the Accept a payment guide walks it end to end.
Mobile is different. The native SDKs present checkout and onboarding as native flows, and frame-react-native runs the Frame API on-device, so they don't necessarily pair with a separate backend the way the web flow does. Pick your client SDK from the table above, then follow that SDK's reference for its integration shape.
Worked example: onboarding and KYC
The original gap this page closes was a specific one — the KYC docs explained generating an onboarding session but never said which SDK does what, or when to reach for the web SDK versus the React Native one. Onboarding is presented differently per platform.
On the web, onboarding is a backend-minted session your frontend renders. Your server calls POST/v1/onboarding_sessions (after creating the Account with the capabilities the relationship needs), then Frame.js renders it with the <frame-onboarding> embedded component, or you redirect the user to the session's hosted url. See Embed onboarding for the server-side prep and the Embedded Onboarding component reference.
On React Native, the SDK drives onboarding natively: presentOnboarding({ accountId, capabilities }) renders the verification steps in-app from the requested capabilities — there's no hosted session URL to render. For native iOS and Android, consult each SDK's reference (linked from the table above) for how it presents onboarding.
Capability state is the source of truth, not the client. However onboarding is presented, the user finishing the flow is not a success signal — verifications resolve asynchronously after the client is done. Reconcile from the capability.activated / capability.disabled webhooks server-side, not the client return or callback. The Onboarding concept covers the model; Run onboarding and Run KYC cover the full step-by-step and the re-verification branch.
Next
- End-to-end walkthrough — onboard, verify, charge, and pay out one account across both SDK layers
- Frame.js architecture — the frontend / backend / Frame API split in full
- Web SDKs, Mobile SDKs, Backend SDKs — each SDK family's landing page