Architecture Overview

A high-level picture of how a partner integration fits together. Useful for technical evaluators scoping their first integration call.

The big picture

A typical partner integration involves three layers:


┌──────────────────────────────────────────────────────────────────┐
│  Partner surfaces                                                │
│  (your existing app — web, iOS, Android, server backend)         │
└──────────────────┬────────────────────────────┬──────────────────┘
                   │                            │
                   │ Embedded SDK calls         │ Server-to-server
                   │ (web, iOS, Android)        │ API key
                   ▼                            ▼
┌──────────────────────────────────────────────────────────────────┐
│  KryptoGO platform                                               │
│                                                                  │
│   Studio control panel ────────┬────► Studio API (REST)          │
│      (web)                     │                                 │
│                                │                                 │
│   Mobile Wallet SDK ──────┬────┤                                 │
│   Payment SDK ────────────┤    │                                 │
│   Authentication SDK ─────┘    │                                 │
│                                │                                 │
│   Asset Pro custody backend ◄──┤                                 │
│      (key vault, multi-sig)    │                                 │
│                                │                                 │
│   On-chain Data API                                              │
│      (read-only analytics)                                       │
│                                                                  │
│   Compliance services                                            │
│      (KYC, KYB, AML, sanctions, audit log)                       │
└──────────────────┬───────────────────────────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────────────────────────┐
│  Public blockchains                                              │
│  Ethereum · Arbitrum · Optimism · Base · Polygon · BNB Smart     │
│  Chain · Solana · Tron · Bitcoin (read-only)                     │
└──────────────────────────────────────────────────────────────────┘

The integration surfaces, by partner type

A partner usually picks one or two of these surfaces; a complex deployment uses several.

Partner surface	Used by	What it talks to
Studio (web control panel)	Operations, finance, compliance teams inside the partner organisation	The Studio API, plus the on-chain Data API for analytics views
Studio API (server-to-server REST)	A partner backend that wants to create payments, trigger custodial transfers, or run AML risk checks programmatically	The Studio API
Payment SDK (`@kryptogo/kryptogokit-sdk-react`)	Web-based merchant checkout pages	The Studio API for payment-intent creation; the user’s chosen wallet for signing
Mobile Wallet SDK	Native iOS or Android partner apps that want to embed a per-user crypto wallet	The Studio API for auth and account state; the on-chain Data API for balances; public RPC endpoints for signing
Authentication SDK (`@kryptogo/auth`)	Partner web apps offering “Sign in with KryptoGO”	The Studio API auth endpoints

How a single payment moves through the system

Worked example: a merchant accepts a stablecoin payment through their checkout.

The merchant backend calls Studio API with an API key: “create a payment intent for $42.00 USDC, callback to https://merchant.example/webhooks/kg”.
Studio API returns a payment-intent identifier and a hosted checkout URL (or a payload for the Payment SDK to render an in-page modal).
The end user pays from their wallet of choice. The transaction lands on the chain they paid on (Arbitrum, Base, Optimism, Solana, or Tron).
KryptoGO’s chain watchers detect the transaction. The payment-intent state machine advances through the appropriate states (waiting for user, waiting for confirmation, settled — or refunded, expired, failed).
On every state change, KryptoGO POSTs a signed callback to the merchant’s webhook URL. The callback payload is signed with HMAC-SHA256; the merchant verifies the signature before acting on it.
Settled funds land in the merchant’s KryptoGO-managed receive address. The merchant can sweep them to a self-custodied wallet, leave them in custody, or trigger an off-ramp to fiat through a partnered settlement provider.

How a custodial transfer moves through the system

Worked example: a partner backend wants to send a stablecoin payout to a customer.

Partner backend calls Studio API with an API key: “transfer 10 USDC on Arbitrum from our treasury to wallet 0x…”.
The transfer enters the Asset Pro workflow with an initial state of “awaiting approval”.
A designated Approver inside the partner organisation reviews and approves it in the Studio UI (or via API). The transfer moves to “awaiting release”.
A designated Signer authorises the on-chain release. KryptoGO’s signing service decrypts the relevant key inside the managed key vault, signs the on-chain transaction, and broadcasts it.
The transfer state machine advances through “broadcasting” to “confirmed”.
The partner can poll the transfer-history endpoint or subscribe to status updates.

The Maker / Approver / Signer separation is not optional for treasury-grade transfers. It is the principal control that makes the custodial model viable for regulated partners.

How an embedded wallet provisions a user

Worked example: an end user opens the partner app for the first time and taps a crypto-related feature.

The partner app already has the user signed in with whatever auth the partner uses.
The partner backend signs a JSON Web Token identifying the user and passes it to the partner app.
The partner app initialises the Mobile Wallet SDK with the partner’s client ID and the user’s signed token.
The SDK exchanges the token with KryptoGO’s auth backend, which verifies the signature against the partner’s published public key.
KryptoGO’s backend issues a session token. The SDK provisions a fresh wallet, splits the seed into three Shamir shares, and distributes them: device secure-storage, partner cloud, KryptoGO cloud.
The user is now in a wallet view inside the partner app — branded with the partner’s theme — showing balance, receive address, send and swap controls. None of this required the user to know what a private key is.

What we operate on your behalf

KryptoGO operates	Partner operates
The signing service and managed key vault	The auth system that signs end-user JWTs (for embedded self-custody)
Chain watchers across all supported chains	The webhook receiver for callbacks
The Studio API and its rate limiting	An API key and its lifecycle (rotation, scoping)
KYC and KYB workflows, including third-party IDV vendor integrations	The compliance reviewer assignments inside Studio
The compliance audit log and retention	The decision-routing rules for cases that need human review
The on-chain Data API and its caching	Any product UI sitting on top of analytics endpoints

What sits where, geographically

Production infrastructure runs on Google Cloud in the asia-east1 region with a private VPC. The signing service runs in an isolated private subnet behind a key vault that has been audited under our ISO 27001 program. We can supply detailed DPIA and infrastructure diagrams under NDA on request.

Where to go next

See Custody Options for how the signing service is structured.
See Compliance & Certifications for the controls that wrap the architecture.
See Integration Timeline Framework for how to scope a project against this architecture.
See Reference: API surface for the endpoint inventory.