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

# Core Concepts

<Frame>
  <img alt="186" title="186" lightAlt="186" darkAlt="186" src="https://mintcdn.com/bleepay/QXMa__wDe-WJOq9n/images/introduction1-1.png?fit=max&auto=format&n=QXMa__wDe-WJOq9n&q=85&s=4af2d4a43c33527e964a4666818eafb3" className="dark:hidden" width="1500" height="844" data-path="images/introduction1-1.png" />

  <img alt="186" title="186" lightAlt="186" darkAlt="186" src="https://mintcdn.com/bleepay/QXMa__wDe-WJOq9n/images/dsad.png?fit=max&auto=format&n=QXMa__wDe-WJOq9n&q=85&s=aaca8310cded780c0b8db02e94be1bbb" className="hidden dark:block" width="1500" height="844" data-path="images/dsad.png" />
</Frame>

> Vouchers, sessions, settlement, and the Bleepay execution flow.

<Info>
  Understanding these concepts will help you integrate and operate Bleepay correctly.
</Info>

## Voucher (6-digit code)

<Frame>
  <img alt="124" title="124" lightAlt="124" darkAlt="124" src="https://mintcdn.com/bleepay/BqwU20PkIpYIQdEX/images/124.png?fit=max&auto=format&n=BqwU20PkIpYIQdEX&q=85&s=a8b00035c4fd6908d32b921de697b06d" className="dark:hidden" width="1920" height="398" data-path="images/124.png" />

  <img alt="124" title="124" lightAlt="124" darkAlt="124" src="https://mintcdn.com/bleepay/BqwU20PkIpYIQdEX/images/196.png?fit=max&auto=format&n=BqwU20PkIpYIQdEX&q=85&s=fb3ba4d73d572e61f5e20d19c36cc47a" className="hidden dark:block" width="1920" height="398" data-path="images/196.png" />
</Frame>

A **voucher** is a short-lived, human-readable code generated by the payer's wallet and bound to an authorization context. It acts as an **ephemeral proxy** for payment authorization.

/

* **Format**: Typically 6 digits (numeric) or 6 alphanumeric characters, depending on mode.
* **Transmission**: Can be passed by any channel: typed, spoken, QR, NFC, or messaging.
* **Lifecycle**: Reserved at generation, unreserved when the session is completed or expired.
* **Security**: Does not expose public or private keys; only the payer's wallet can sign the resulting transaction.

## Session

<Frame>
  <img alt="198" title="198" lightAlt="198" darkAlt="198" src="https://mintcdn.com/bleepay/OYSSlB5NwPuuC8vG/images/197-1.png?fit=max&auto=format&n=OYSSlB5NwPuuC8vG&q=85&s=9b86eff0cde297a2d6ac1f6ccf4ba747" className="dark:hidden" width="1920" height="398" data-path="images/197-1.png" />

  <img alt="198" title="198" lightAlt="198" darkAlt="198" src="https://mintcdn.com/bleepay/BqwU20PkIpYIQdEX/images/198.png?fit=max&auto=format&n=BqwU20PkIpYIQdEX&q=85&s=bfc05618a7c27dc1c572c24791e8d40a" className="hidden dark:block" width="1920" height="398" data-path="images/198.png" />
</Frame>

A **voucher session** is the short-lived state on Bleepay's side that links:

* One or more voucher codes
* The payer's identity (bound cryptographically)
* Transaction parameters (amount, currency, destination, etc.)

A session can contain **multiple transactions** — not just a single payment. Each voucher within a session is treated independently, with its own lifecycle, but all share the same session context for grouping and tracking. The session exists from voucher generation until all transaction objects are retrieved and authorized by the payer. After that, the session is finalized and voucher codes are returned to the pool.

## Payment flow (high level)

<Steps>
  <Step title="Payer ">
    logs in and opens a context → receives a context code that links their identity to the payment session.
  </Step>

  <Step title="Payer ">
    shares the context code with the payee (typed, spoken, QR, etc.).
  </Step>

  <Step title="Payee">
    authenticates with the context code, reserves a voucher (receives a 6-digit code), and redeems it by specifying what they expect to receive (`expectedPayment`) — currency, amount, and destination address.
  </Step>

  <Step title="Bleepay">
    validates the voucher, syncs transaction metadata, and builds the transaction (swap/bridge/transfer) for the appropriate chain and token.
  </Step>

  <Step title="Payer">
    reviews, signs in their wallet, and submits the receipt via `resolve-voucher`; the wallet broadcasts to the network.
  </Step>

  <Step title="Settlement">
    funds arrive at the payee's address (or via liquidation partner for fiat).
  </Step>
</Steps>

## Non-custodial model

* **Client-side signing**: Private keys stay in the user's wallet. Bleepay provides transaction payloads; all signatures happen locally.
* **No custody**: Bleepay never holds user funds. Settlement is on-chain or via regulated off-ramp partners.
* **Session integrity**: Codes are ephemeral and bound to a specific payment intent, reducing replay and misuse.

## Chain-agnostic merchant experience

Merchants integrate using **financial metadata only**: amount, currency, wallet address. They do not:

* Choose chains or tokens (the system determines the network from the currency)
* Manage gas or RPC
* Write or deploy smart contracts

Bleepay's backend handles routing, gas, cross-chain, and DEX logic so the merchant stays chain-agnostic.

## Next steps

* [Terminology](/home/reference/terminology) — full glossary of protocol terms.
* [Protocol flow](/home/reference/protocol-flow) — voucher generation, redemption, and settlement steps.
* [Voucher modes](/home/reference/voucher-modes) — numeric vs alphanumeric codes.