> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gnosispay.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Type of Integrations 

> Choose how your product connects to Gnosis Pay.

Gnosis Pay offers two ways to integrate. Both run on the same platform and give you the same card issuing, accounts, KYC, and money movement. The difference is **who owns the user-facing layer**: how users sign in, where user data lives, and who runs onboarding.

> [card] [Platform Integration](https://docs.gnosispay.com/platform-integration/configuring-environment.md)
>
> **You own the experience.** Your backend calls Gnosis Pay server-to-server. You keep your own authentication, user data, and onboarding flow.

> [card] [Embedded Integration](https://docs.gnosispay.com/embedded-integration/configuring-environment.md)
>
> **Gnosis Pay runs the backend.** Users sign in with their wallet, and Gnosis Pay handles sessions, identity, and onboarding. You ship the frontend.

## Which one fits your product

One question decides it: **Does your product already have a backend with its own user accounts?**

* **Yes**: use **Platform Integration**. You already have identity, sessions, and onboarding, so you add Gnosis Pay calls to the systems you have.
* **No**: if your product runs on wallets, private keys, or passkeys with no user database of its own, use **Embedded Integration**. Gnosis Pay provides the backend layer you don't have.

> [!NOTE]
>
> The choice depends on your architecture, not your industry. A crypto company that runs its own backend and user accounts should use Platform Integration.

## Comparison

| | Platform Integration | Embedded Integration |
| - | - | - |
| **User experience** | Fully yours, no constraints | Your frontend, Gnosis Pay's flow |
| **End-user sign-in** | Your own auth (OAuth, passkeys, SSO, magic link, etc.) | Sign-In with Ethereum (wallet signature) |
| **User identity and data** | Lives in your systems | Managed by Gnosis Pay, keyed to the wallet address |
| **Onboarding** | Your backend advances each step from your existing flow | A single onboarding status tells your app the next action |
| **Resource model** | Explicit IDs for each KYC profile, account, cardholder, and card | Resources are resolved from the signed-in user |
| **Control** | Direct control of lifecycle, limits, funding, and transactions | User-focused operations with fewer decisions to make |
| **How you connect** | Server-to-server, with partner credentials | Your frontend calls the API with the user's session |
| **What you build** | Backend integration: ID mapping, ownership checks, webhook handling | Frontend only |
| **Best for** | Fintechs, neobanks, payment companies, and any product with its own backend | Wallet-native products with no backend of their own |
| **API** | Partner API | User API |

## What's the same in both

Whichever path you choose, your users get the same underlying capabilities: KYC, accounts with on-chain balances, virtual and physical cards, card controls and limits, 3D Secure, secure card data and PIN flows, deposits, withdrawals, and statements. See [Accounts](https://docs.gnosispay.com/concepts/accounts/account.md) and [Cards](https://docs.gnosispay.com/concepts/card/overview.md) for how these work.

## Start building

> [card] [Platform Integration guide](https://docs.gnosispay.com/platform-integration/configuring-environment.md)
>
> Authenticate your backend, onboard users, and issue cards through the Partner API.

> [card] [Embedded Integration guide](https://docs.gnosispay.com/embedded-integration/configuring-environment.md)
>
> Add wallet sign-in and the ready-made onboarding flow through the User API.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.