# Getting Started

peltier is an EIP-7702 deposit sweeper that accepts any token on any supported chain and settles the equivalent value in USDC at your destination address. Drop the widget into your app with three lines of code.

> **Accepting payments as a merchant?** Start with the [**5-minute quickstart**](#merchant-quickstart) — four curl calls from zero to your first signed webhook: create merchant → pin destination → create session → embed checkout → `payment.succeeded`.

peltier exposes **four flows** over two engines: **A — Merchant checkout** (fixed, server-pinned destination), **B — P2P request / receive** (recipient shares a link/QR; payer sends any token), **C — P2P push / send** (sender pushes any token → USDC from their own connected wallet), plus **Cash on-ramp** as a deposit method. A and B run on the hosted burner + signed-Intent engine; C is fully client-side (sender signs from their own wallet). Every deposit flow settles in **USDC** — only the destination chain + address (and amount, for checkout) vary. On top of checkout, merchant mode adds three surfaces: [**Subscriptions**](#subscriptions) — a second on-chain rail of recurring bounded pulls, run by a dedicated per-chain worker and settling in the payer-chosen ERC-20 rather than USDC — hosted [**Payment Links**](#payment-links) (reusable `/l/{slug}` pages that mint ordinary checkout sessions), and an SDK-side [**HTTP 402 gate**](#http-402) for agent payments.

## Installation

```bash
npm install @peltier/react
```

The SDK is split by tier — install only what your code runs: `@peltier/react` (web widgets + hooks, shown here), [`@peltier/react-native`](#react-native) (RN widgets + the same hooks), [`@peltier/node`](#http-402) (backend: 402 gate, webhooks, subscriptions), and `@peltier/core` (the React-free primitives underneath all of them, for scripts and shared code).

## Quick Start

```typescript
// App.tsx
import { PeltierProvider, DepositWidget } from '@peltier/react'

export default function App() {
  return (
    <PeltierProvider
      apiUrl="https://api.peltier.xyz"
      publishableKey="pk_live_…"
    >
      <DepositWidget
        destinationAddress="0x123...abc"
        destinationChainId={8453}
      />
    </PeltierProvider>
  )
}
```

That is the complete integration. The widget handles wallet generation, EIP-7702 authorization signing, session registration, deposit detection, and real-time status updates via SSE. The user sends any token on any supported chain, and USDC arrives at the destination.

## Choose your flow

`DepositWidget` above powers the anonymous "send any token → my USDC" case. For the three named flows the SDK ships thin, intention-revealing wrappers — all rendered inside `PeltierProvider`:

```typescript
// A — Merchant checkout: payer UI bound to a server-created payment session
//     (your backend mints { sessionId, client_secret } via createPaymentSession)
<PeltierCheckout sessionId clientSecret publishableKey destinationAddress destinationChainId={8453} />

// B — Request / receive: recipient shares a link/QR; anyone pays any token, settles to them
<PeltierRequest destinationAddress destinationChainId={8453} />

// C — Push / send: sender pushes any token → USDC from their OWN connected wallet
<PeltierSend provider={walletProvider} recipient="0x…" allowedRouters={[…]} />
```

A & B run on the hosted burner + signed-Intent engine (the platform pays gas and submits, but the contract physically refuses to move funds anywhere except the user-signed destination). C is fully client-side — the sender signs and submits from their own wallet, with mandatory recipient/`minOut` calldata verification before signing.

## How It Works (30 seconds)

1. The SDK generates a fresh **burner wallet** in the browser and signs an **EIP-7702 authorization** for it. The `chainId=0` authorization reuses the same burner address on every chain, but on its own it authorizes **no fund movement** -- that comes only from the per-chain EIP-712 Intent in step 4, whose domain binds `block.chainid`.
2. A **session** is registered with the backend, which begins watching every supported chain for a deposit to that burner address.
3. The user sends any token (or native ETH) to the burner address on any supported chain. peltier detects the deposit in real time.
4. **Detect-then-sign.** On the `detected` SSE event, the SDK (holding the burner key in memory) fetches a slippage floor via `GET /sessions/:id/quote`, builds an EIP-712 `Intent` bound to the *actually-deposited* token/amount, signs it **once**, and `POST /sessions/:id/commit`s it. This Intent is the only thing that can move the funds -- and only ever to your destination.
5. peltier settles the deposit to **USDC** at your destination address, swapping and bridging as needed. The platform pays gas and submits the transactions but is a non-custodial executor -- the on-chain contract refuses to send funds anywhere except the destination you signed.
6. USDC settles at the destination address on the destination chain. The SDK receives the final status via SSE and fires the `onComplete` callback.

## Test mode

Every merchant account ships with two key sets: **live** (`sk_live_`/`pk_live_` -- mainnet, real money) and **test** (`sk_test_`/`pk_test_` -- testnets, no real money). The mode is encoded in the key prefix, so swapping in a `pk_test_` key runs the exact same flow on testnets. See [Test mode](#test-mode) to build and try the full checkout with faucet-funded testnet USDC before you ever touch a live key.