> ## 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.

# Capabilities

> The six things Stableyard does, the API behind each one, and what must be enabled first.

Every integration is a combination of six capabilities. Each is expressed through the same two resources, `Account` and `Payment`, so learning one makes the next cheaper.

**A capability is available to you only when `GET /v2/partners/config` says so.** Entitlement, credential permissions and provider readiness are three separate gates, and a capability must clear all three.

Crypto capabilities need no verification. Fiat ones add compliance on top: your organization completes KYB once, then each account that uses a fiat product is verified in its own right. The config response reports both under `compliance`, without exposing provider data.

| Field | What it tells you |
| - | - |
| `compliance.partnerKyb.status` | Your organization's KYB: `not_started`, `pending`, `approved` or `action_required`. Fiat stays closed until it is `approved` |
| `compliance.requirements` | What each party must pass for fiat: `kyb` for you, `kyc` for an `individual` account, `kyb` for a `business` account |

## Collect

Receive funds into an account.

| Route | How | Resource |
| - | - | - |
| Hosted checkout or payment link | Create a payment, redirect the payer | `Payment`, `intent: receive` |
| Reusable deposit address | Issue once, reuse forever, no amount or expiry | `DepositAddress` |
| Bank account in your customer's name | Fiat paid in arrives as stablecoin | `OnrampBankAccount` |
| Fiat at checkout | The payer pays with a card or a local method | A payment method on a receive `Payment` |

Collected funds are held in a per-payment escrow and credited only when the expected receipt is verified. A provider reporting success is not the same as collection.

```bash theme={null}
curl -X POST https://staging-api-v2.stableyard.fi/v2/payments \
  -u "$APP_ID:$APP_SECRET" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "intent": "receive",
    "recipient": { "accountId": "acct_123" },
    "amountMode": "collect_exact",
    "paymentAmount": {
      "amount": "25.00",
      "assetType": "crypto",
      "assetCode": "USDC",
      "chainId": 42161
    }
  }'
```

## Hold

An account does not hold a spendable balance.

`GET /v2/accounts/{accountId}/balances` returns a reporting projection with `custodyScope: "not_a_custody_balance"`. It is a reconciliation and statement feed. It can be negative, and it does not decrease when value settles out to a customer's own wallet.

Value rests in the customer's own wallet, their `Vault`, or their bank account. If your product needs a spendable balance, that ledger is yours to keep.

## Convert

Conversion is not a standalone resource. There is no `Conversion` object and no convert endpoint.

Where a payer pays in one chain or asset and the recipient is owed another, the conversion is selected as part of the payment option during routing, and it settles inside the same `Payment`. The payer sees what they pay; the recipient receives the exact amount they asked for.

Use `POST /v2/payments/preview` to resolve amounts and funding options before creating a send payment. Preview is send-only; a receive payment returns its options once created.

## Pay

Send funds out of an account.

| Destination | Resource |
| - | - |
| A crypto wallet | `Payment`, `intent: send`, wallet destination |
| Another account, by handle | `Payment`, `intent: send`, `payment_handle` destination |
| A bank account | `Payment`, `intent: send`, bank destination |
| A local merchant | `Payment`, `intent: send`, scanned code or typed rail identifier |

## Settle

Settlement is where collected value lands. It is a property of the receiving account, not a decision made per payment.

`SettlementProfile` names the destination; `SettlementDestination` is the typed target: a connected wallet, a verified bank account, or a payment rail identifier. A payer chooses how to pay. Your backend chooses where the recipient settles. Checkout cannot change it.

## Reconcile

Reconciliation is not an endpoint you call. It is the guarantee the rest of the API is built to give you.

* Every movement is recorded as a `Transaction` against an account.
* Webhook events fire when state changes, signed, and are a prompt to read the resource rather than a statement of truth.
* Crediting happens on verified receipt, so what is recorded matches what arrived.
* Idempotency keys make retries safe, so a duplicate request cannot become a duplicate movement.

## Next

<CardGroup cols={2}>
  <Card title="Supported regions and currencies" icon="globe" href="/supported-regions-and-currencies">
    Where each capability is available.
  </Card>

  <Card title="Objects" icon="book-open" href="/api-reference#objects">
    Every object, its ID prefix and the rule to know.
  </Card>
</CardGroup>


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