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

# White-label overview

> Run Stableyard accounts for your own customers from your backend, inside your own product.

<img className="sy-hero block dark:hidden" src="https://mintcdn.com/stableyard/KNLdOufdyK0ENvTU/images/heroes/white-label-light.png?fit=max&auto=format&n=KNLdOufdyK0ENvTU&q=85&s=ae15180fcbb5de980bb4bdb94483a5c7" alt="A customer account with its on-ramp bank details, shown with the request that issues them" width="2400" height="1080" data-path="images/heroes/white-label-light.png" />

<img className="sy-hero hidden dark:block" src="https://mintcdn.com/stableyard/KNLdOufdyK0ENvTU/images/heroes/white-label-dark.png?fit=max&auto=format&n=KNLdOufdyK0ENvTU&q=85&s=c5270de7546d090264f3727e132d886d" alt="A customer account with its on-ramp bank details, shown with the request that issues them" width="2400" height="1080" data-path="images/heroes/white-label-dark.png" />

Give each of your customers their own account, with US bank details to fund it and a linked bank to cash out to, and run all of it from your backend, inside your product.

Stableyard is the orchestrator behind the API. It keeps the account records, runs identity checks through a verification provider, issues bank details and pays out through banking partners, and verifies every movement before it records it. Routes and partners change behind the API; your integration does not.

```mermaid theme={null}
flowchart LR
  B["Your backend<br/>app ID and secret"] -->|"POST /v2/accounts"| A["Customer account<br/>one per customer"]
  A --> V["Verification<br/>email, identity, capability"]
  A --> W["Wallets<br/>where stablecoin rests"]
  A --> O["On-ramp account<br/>US bank details"]
  A --> D["Deposit addresses<br/>stablecoin in"]
  A --> L["Linked bank accounts<br/>where payouts land"]
```

## One account per customer carries everything

You create one account per customer with `POST /v2/accounts`, keyed by your own `externalUserId`. Stableyard calls it a [Universal Payment Account](/universal-payment-account), or UPA. Everything else attaches to it.

| Attached to the account | What it does | Read more |
| - | - | - |
| Verification | Email, then identity, then a regulated capability, in that order | [Email verification](/concepts/email-verification), [Individual KYC](/concepts/individual-kyc), [Capability activation](/concepts/capability-activation) |
| Wallets | Where stablecoin lands, and where payouts are funded from | [Universal Payment Account](/universal-payment-account) |
| On-ramp account | US bank details; transfers in arrive as USDC or USDT in a wallet | [On-ramp accounts](/concepts/on-ramp-accounts) |
| Linked bank accounts | The customer's own bank, saved as a payout destination | [Bank accounts](/concepts/bank-accounts) |
| Deposit addresses | Reusable stablecoin addresses with no amount and no expiry | [Depositing funds](/payments/depositing-funds) |
| Payments | Every movement out, each with one id and one result | [Sending payments](/payments/sending-payments) |

## Value rests in the customer's wallet

Stableyard moves value, verifies it and records it. It does not hold a spendable balance for the account.

```mermaid theme={null}
flowchart TB
  P["Customer's bank"] -->|"ACH, Fedwire or FedNow"| O["On-ramp account"]
  O -->|"converted by a banking partner"| W["Customer's wallet<br/>USDC or USDT"]
  D["Deposit address"] -->|"settles"| W
  W -->|"exact deposit, signed by the wallet's controller"| E["Payment escrow"]
  E -->|"verified, then paid out by a banking partner"| L["Customer's linked bank"]
```

* **Fiat in arrives as stablecoin.** Every transfer to an on-ramp account is converted and delivered to the wallet fixed when the account was issued. There is no settlement step to call.
* **Fiat out is a payment funded from a wallet.** The wallet sends the exact quoted amount to the payment's escrow; Stableyard verifies it, takes the fees and forwards the rest to a banking partner.
* **Stableyard never signs for a connected wallet.** Whoever controls it signs: your customer, or your platform if you provide the wallet.
* **Balances are reporting.** `GET /v2/accounts/{accountId}/balances` returns `custodyScope: "not_a_custody_balance"`. Never authorize a payout against it. See [Transactions](/payments/transactions).

## What you build and what Stableyard provides

| You build | Stableyard provides |
| - | - |
| Your product, your screens, your login and the customer relationship | The account records, the payment ledger and the routing behind every rail |
| The mapping from your user to `externalUserId` | Idempotent account creation, and lookup by your id |
| The screens that start verification and show where it stands | Email codes, the hosted identity and compliance pages, and the decision |
| The screen that shows a customer their bank details | US bank details issued through a banking partner, and conversion on arrival |
| The decision to pay out, and the approval behind it | The quote, the escrow, the payout through a banking partner and the verified result |
| The wallet the stablecoin rests in, and whoever signs from it | Verification of every receipt before it is recorded |
| A spendable balance ledger, if your product shows one | Recorded activity and a transaction history per account |

## Stableyard switches some things on for you

Stablecoin movement needs only your app's product access, and no verification. Fiat needs more, and none of it is self-serve:

* **Your organization's KYB.** Until it is approved, no fiat product works for you or any of your accounts. Read it from `compliance.partnerKyb.status` in `GET /v2/partners/config`.
* **The products and rails.** Identity & KYC, the on-ramp and the bank rails are enabled per app, per environment, per country and per rail.
* **Policies.** Business verification, and whether you may assert an email you already verified.

[Going live](/white-label/going-live) lists each one and how to confirm it.

## What your customers see

Your product, mostly. A few steps run on pages and emails you do not control.

| Moment | What the customer sees |
| - | - |
| Screens you build on the API | Your product only |
| Email verification | A code emailed by Stableyard that names your app, unless you assert the email yourself |
| Identity verification | A page hosted by the verification provider |
| Bank access form | A Stableyard-hosted page, "Requested by" your app, with a code emailed by Stableyard |
| Hosted checkout, if you use it | Your branding or the recipient's in the header, "Secured by Stableyard" in the footer |

Every surface, and what you can change on each, is on [Branding and your frontend](/white-label/branding-and-frontend).

## Where to start

<CardGroup cols={2}>
  <Card title="Choose your pattern" icon="signs-post" href="/white-label/patterns">
    Embedded ramps, business customers or crypto-only, with the gates for each.
  </Card>

  <Card title="Quickstart" icon="rocket" href="/white-label/quickstart">
    Eight steps on staging, from a new account to a payout to the customer's own bank.
  </Card>

  <Card title="Branding and your frontend" icon="palette" href="/white-label/branding-and-frontend">
    What carries your brand, what carries Stableyard's, and what runs in your browser.
  </Card>

  <Card title="Going live" icon="flag-checkered" href="/white-label/going-live">
    What Stableyard enables, and what changes between staging and production.
  </Card>
</CardGroup>


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