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

# Money Movement

> Rails and their standing, funding an account, pricing a payment, sending transfers and payouts, and reading the transaction list.

Money movement has three parts: getting money in, sending it out, and knowing what it cost. Pricing comes first in every outbound flow — you never submit a payment without a quote in hand.

## Rails and their standing

A **rail** is a route money travels. Two are offered today:

| Rail   | Typical use                                 |
| ------ | ------------------------------------------- |
| `ach`  | Domestic US bank transfers                  |
| `wire` | High-value and international bank transfers |

Further rails are enabled progressively. Which ones are open to you is shown in the app, and that list — not this page — is the authoritative answer for your space.

A rail being offered does not mean it is open to you. Two separate gates decide that, and the difference matters:

<AccordionGroup>
  <Accordion title="The deployment switch" icon="toggle-on">
    Whether the rail is switched on for the environment you are using at all. A rail that is off is off for everyone.
  </Accordion>

  <Accordion title="The provider endorsement" icon="stamp">
    Whether the payment provider has endorsed your space for that family of rails. Endorsements are issued per family, and a payout over a rail you hold no endorsement for is refused by the provider. A space registered before a rail was switched on holds no endorsement for it and has to ask for one.
  </Accordion>
</AccordionGroup>

Listing your rails returns every rail this environment offers, each with its standing and, where it is closed, the reason. One state deserves attention: when an endorsement has not been read back from the provider yet, the rail is reported as available, because an unread endorsement never refuses a payout — but nothing should promise the rail works until it is confirmed. Where a rail needs documents or approval, you can request it and attach what it asks for.

## Funding

Getting money in is a two-step flow, then a wait.

<Steps>
  <Step title="Choose a funding method">
    Pick the wallet and the method — a fiat rail, or crypto.
  </Step>

  <Step title="Fetch the instructions">
    For a fiat rail you receive the account details to pay into. For crypto you receive a deposit address together with its chain and asset. Send only the named asset, on the named chain.
  </Step>

  <Step title="Send from your side">
    Initiate the payment at your bank or wallet. Inbound funds land in your transaction list on their own once they clear — there is no deposit to confirm on the platform.
  </Step>
</Steps>

## Pricing: the fee quote

Every outbound payment is priced before it exists.

<Steps>
  <Step title="Request a preview">
    Ask for a fee preview for the amount and route you intend. You receive a quote carrying a `fee_quote_id`, the net amount, the fee, and the total that will be debited.
  </Step>

  <Step title="Submit against the quote">
    Create the payment citing that `fee_quote_id`. The price you were shown is the price you are charged.
  </Step>
</Steps>

Three properties of a quote are worth committing to memory:

* **Fee on top.** The recipient receives exactly the amount you entered. Your wallet is debited that amount **plus** the fee. Net and fee always sum to the total debited.
* **Single use.** A quote is consumed by one payment. A second payment needs a second quote.
* **Ten minutes.** A quote expires ten minutes after it is issued. Submitting against a lapsed quote is refused, and the fix is to price again.

<Note>
  The fee is set per payment from the destination and the risk of the route, so it is not a single published percentage. The preview is the authoritative price for your payment, and it is the number to show your own users.
</Note>

## Transfers

A transfer moves money between wallets. Price it, submit it against the quote, then follow its status in the transaction list.

## Payouts

A payout sends money to someone outside the platform.

<Steps>
  <Step title="Create a recipient">
    Record who is being paid, once. Recipients are reusable, and you can update or delete them later.
  </Step>

  <Step title="Price the payout">
    Request a withdrawal fee preview for the amount and rail.
  </Step>

  <Step title="Send and track">
    Submit against the quote and follow the payout in your transaction list.
  </Step>
</Steps>

### Recipients and beneficiaries

These are two layers of the same idea, and the split matters when something needs repairing:

* A **recipient** is your record of a payee — the one you create, edit, and reuse.
* A **beneficiary** is the link between that record and the provider's own account reference. When a provider changes a reference, the beneficiary can be unlinked and relinked without you rebuilding the recipient.

## Transactions

Every money event lands in one list: funding, transfers, payouts, and fees alike. Each carries a **kind** and a **status**, and you can filter by account, wallet, kind, or status. A payment and its fee are separate entries, so the ledger reconciles against your own books without inference.

## Rates

Current exchange rates are shown in the app, so you can see what a conversion will produce before you commit to it.


## Related topics

- [Accounts and Wallets](/accounts-wallets.md)
- [Introduction](/introduction.md)
- [Legal and Regulatory](/legal.md)
- [Quickstart](/quickstart.md)
- [Onboarding and Security](/onboarding-and-security.md)