Crypto Deposit Widget SDK

Embed a deposit flow that feels native to your product instead of sending users through a patchwork of wallet prompts, exchange instructions, and disconnected funding screens. depositOS gives integrators one widget surface for configuring destination chain, token, address, theming, and available funding paths.

Whether you are adding deposits to a consumer crypto app, a DeFi product, or an onboarding flow, the goal is the same: reduce implementation overhead while keeping the funding experience inside your own product environment.

Open playground · Documentation

What the SDK is for

The crypto deposit widget SDK is built for teams that want to add a deposit step without building every funding path and destination rule from scratch.

Use it when you need to:

  • embed a deposit experience directly into your app or checkout flow
  • route funds to a defined destination chain, token, and recipient address
  • offer more than one funding path from a single integration surface
  • keep control over theme, layout, and product context
  • move from product evaluation into implementation with concrete configuration inputs

The current depositOS demo exposes both a React widget path and an iframe embed path, which makes it relevant for teams that want either a tighter component integration or a lighter-weight embed model.

Why teams look for a crypto deposit widget SDK

Deposit flows often break down at the exact moment a user is ready to fund.

A typical in-house implementation means stitching together chain selection, token selection, destination handling, wallet funding, fallback paths for users who do not arrive with the right assets, and a UI layer that still needs to match the rest of the product. Even when the core transfer logic works, the user experience can still feel fragmented.

An embedded deposit widget changes that evaluation. Instead of building a custom flow for every funding case, teams can evaluate whether one integration surface covers the operational pieces that matter most:

  • destination configuration
  • embeddable UI
  • wallet-based funding
  • privacy-sensitive flow options
  • implementation control for frontend teams
  • a testable path from sandbox exploration to production review

For teams focused on fewer dead ends during funding, that is a more useful starting point than a generic crypto payments page.

What depositOS exposes in the current integration model

The current repo and playground implementation expose a concrete configuration surface rather than a vague overview.

The live demo configuration includes:

  • apiBaseUrl for the backend endpoint
  • destChain for destination chain selection
  • destToken and optional token metadata for destination asset selection
  • destAddress for the receiving address
  • gizmoFeeBps for fee configuration
  • enableWallet for wallet funding availability
  • enablePrivateMode for privacy-oriented flow availability
  • depositOSTheme for visual customization
  • termsUrl and supportUrl for integrator-controlled links

That matters because an implementation-minded buyer is not only asking whether the widget can render. They are asking whether it can fit the product, point to the right destination, and stay manageable for engineering without a long UI rewrite.

Integration options

React component path

For product teams already building in React, the current demo shows a direct component pattern using DepositOSWidget with a typed DepositOSConfig object. That gives frontend teams a clear place to manage destination settings, feature toggles, theme overrides, and success or close handlers.

import type { DepositOSConfig } from "@gizmolab/depositos";

const config: DepositOSConfig = {
  apiBaseUrl: "https://YOUR_API_BASE_URL",
  destChain: 42161,
  destToken: "0xYOUR_DEST_TOKEN",
  destAddress: "0xYOUR_DESTINATION_ADDRESS",
  gizmoFeeBps: 30,
  enableWallet: true,
  enablePrivateMode: true,
  termsUrl: "/terms",
  supportUrl: "/support",
  depositOSTheme: {
    mode: "dark",
    fontFamily: "Inter, system-ui, sans-serif",
  },
};

<DepositOSWidget config={config} onClose={handleClose} onSuccess={handleSuccess} />;

This path is a fit when the deposit experience needs to feel tightly integrated with the rest of the application UI.

Iframe embed path

The current codebase also exposes an iframe export flow for teams that want a lighter integration surface. The demo generates an iframe source using a base64-encoded config payload and supports both inline and button-triggered embed patterns.

That is useful for teams that want to test embedded deposits quickly, isolate the funding UI, or reduce custom frontend work during early evaluation.

<iframe
  src="https://embed.deposit-os.com?type=inline&config=BASE64_ENCODED_CONFIG"
  style="width: 420px; height: 600px; border: none;"
  allow="clipboard-write"
></iframe>

If your team is comparing a crypto deposit API against a crypto deposit widget SDK, this distinction matters. A widget-first approach can shorten the time between technical review and a working in-product funding flow.

What an implementation review should cover

A serious SDK evaluation usually comes down to a short set of practical questions.

1. Can we control the destination precisely?

The current playground shows explicit destination controls for chain, token, and recipient address. That makes depositOS relevant for products that need to receive funds into a defined asset and endpoint rather than a generic deposit flow.

2. Can we support different user starting points?

The product messaging and current site architecture point toward multiple funding paths within one integration surface. That is especially important when some users arrive ready with a wallet and others do not.

For related context, see Reduce deposit drop-off.

3. Can the flow match our product?

The demo exposes theme controls for mode, colors, typography, radius, border width, and button styles. That makes the SDK more implementation-friendly for teams that care about preserving visual consistency in onboarding or checkout.

4. Can our team test it before deeper integration?

Yes. The strongest current evaluation path is to configure the widget in the playground, review the generated React or iframe output, and then decide whether the integration model fits your stack.

Practical setup path

A straightforward implementation review can follow this sequence:

  1. Open the playground.
  2. Set the destination chain, token, and receiving address.
  3. Toggle the funding modes your product wants to expose.
  4. Apply basic theme settings so the widget reflects your product environment.
  5. Export either the React configuration or iframe embed snippet.
  6. Wire the config into your app and connect success or close handling in your product shell.
  7. Review your supported assets, environment URLs, compliance requirements, and operational support workflow before launch.

This keeps the evaluation anchored in a real integration surface instead of turning the process into a high-level architecture debate too early.

Related depositOS routes

If you want hands-on setup detail, start with the implementation surface here and use the related routes below for adjacent questions:

FAQ

Is this a widget SDK or a lower-level crypto deposit API?

The current implementation surface is widget-led, with configurable inputs and embed options. Teams that want a faster path to an in-product deposit flow can evaluate it as a widget SDK first while still reviewing the backend and environment requirements that support it.

Can we embed it without building a custom React flow?

Yes. The current codebase supports an iframe export path in addition to a React component path.

Can we control chain, token, and destination address?

Yes. The current playground exposes destination chain, destination token, and recipient address configuration directly.

Does the current demo support more than one funding mode?

Yes. The current config surface includes separate toggles for wallet funding and private mode.

What should we verify before production rollout?

Confirm the destination assets you want to support, the environments and endpoints you plan to use, event handling requirements, destination rules, brand styling choices, support URLs, and any compliance review your deployment needs.

Start with a real configuration

If you are evaluating an embedded deposit widget, the best next step is to test the actual configuration surface rather than reading a generic overview.

Open the playground, generate a config that matches your destination setup, and use that output to decide whether depositOS fits your product's deposit flow.

If you want broader context first, start in the docs index.

Previous← OverviewNextQuickstart →