> **Key takeaway:**  ☞   The renaming of "Ledger Live" to "Ledger Wallet" and\
>      "wallet" (in the hardware sense) to "signer" is still in progress.\
>      This page may contain legacy references that will be updated.

# Overview

The integration process ensures a seamless flow of data between , Ledger Backend, and the provider's systems. Providers are expected to implement specific endpoints and adhere to the following workflow to support the Sell feature in .

## Workflow Diagram

```mermaid
sequenceDiagram
    participant User
    participant LedgerLive as Ledger Wallet
    participant LedgerBackend as Ledger Backend
    participant ProviderBackend as Provider Backend
    participant ProviderWidget as Provider Widget App
    participant ExchangeSDK as Exchange SDK

    %% Step 1: Open Sell App
    User->>LedgerLive: Open Sell App
    LedgerLive->>LedgerBackend: [GET] /providers
    LedgerBackend->>ProviderBackend: [GET] /capabilities (Cached)
    ProviderBackend-->>LedgerBackend: Return capabilities data
    LedgerBackend->>ProviderBackend: [GET] /crypto-currencies (Cached)
    ProviderBackend-->>LedgerBackend: Return supported crypto assets
    LedgerBackend-->>LedgerLive: Return providers list and capabilities

    %% Step 2: User Input and Validation
    User->>LedgerLive: Select crypto, fiat, amount
    LedgerLive-->>User: Validate input using cached /capabilities
    User->>LedgerLive: Proceed with valid input
    LedgerLive-->>User: Display countries and payment methods based on /capabilities
    User->>LedgerLive: Select country and payment method
    
    %% Step 3: Select Provider and Get Quotes
    LedgerLive->>LedgerBackend: [GET] /offRamp Find eligible providers
    LedgerBackend->>ProviderBackend: [GET] /quotes
    ProviderBackend-->>LedgerBackend: Return quotes
    LedgerBackend-->>LedgerLive: Return providers and quotes
    User->>LedgerLive: Choose provider

    %% Step 4: Redirect to Provider Widget
    LedgerLive->>ProviderWidget: Redirect with parameters (LiveApp URL)
    User->>ProviderWidget: KYC process, if required, and landing in step transaction in provider widget.
    ProviderWidget->>ExchangeSDK: Initiate exchangeSdk
    ProviderWidget->>ExchangeSDK: Call exchangeSdk.sell

    %% Step 5: Initiate Transaction
    ExchangeSDK->>LedgerLive: Initiate transaction
    LedgerLive-->>ExchangeSDK: Return nonce
    ExchangeSDK->>LedgerBackend: [POST] /remit
    LedgerBackend->>ProviderBackend: [POST] /sell (Request signed payload)
    ProviderBackend-->>LedgerBackend: Return signed payload
    LedgerBackend-->>ExchangeSDK: Return signed payload
    ExchangeSDK-->>LedgerLive: Device transaction approval
    User->>LedgerLive: Approve transaction on device (approve/reject)

    %% Step 6: Finalizing the Transaction
    LedgerLive->>ExchangeSDK: Inform transaction rejected or approved. Provides transactionId if approved
    ExchangeSDK->>ProviderWidget: Transmit transaction info
    ProviderWidget->>ProviderBackend: Transmit transaction status and init webhooks
    ProviderBackend->>LedgerBackend: [POST] /webhook - Update transaction status

```

### Step 1: Open Sell App

Action: The user opens the Sell App in .

Ledger Wallet:

- Fetches capabilities data from the Ledger Backend, which caches responses from the provider's [/capabilities](./redoc-api#operation/getCapabilities) endpoint.

- Fetches supported cryptocurrencies from the Ledger Backend, which caches responses from the provider's [/crypto-currencies](./redoc-api#operation/getCryptoCurrencies) endpoint.

### Step 2: User Input and Validation

User Interaction: The user selects the cryptocurrency, fiat currency, and the amount they wish to sell.

User Interaction: The user selects their country and preferred payment method (e.g., PayPal, bank transfer).

Validation Process:  validates user input.
Validation is performed using cached data from [/capabilities](./redoc-api#operation/getCapabilities), ensuring the user's input aligns with provider-supported limitations (e.g., minimum/maximum amounts, supported countries).

If the input is invalid,  displays an error message to the user.

### Step 3: Get Quotes and Select Provider

User Interaction: User request quote.

Backend Process: Ledger Backend identifies eligible providers based on the user's input.

For each eligible provider, the Ledger Backend sends a \[GET] [/quotes](./redoc-api#operation/getQuote) request to the provider backend to retrieve pricing details (e.g., the amount of fiat currency the user will receive after fees).

The provider backend returns quotes, which are aggregated by the Ledger Backend and displayed in .

User Decision: The user selects a provider from the list of quotes.

### Step 4: Redirect to Provider Widget

Action: Once a provider is selected,  redirects the user to the provider's widget.

Redirection Details: The redirection includes required parameters as specified in the [LiveApp URL documentation](../sell/providers-liveapp), such as the selected cryptocurrency, fiat currency, amount, and user-specific details.

The user lands on the provider widget to complete the transaction details.

### Step 5: Initiate Transaction

Provider Widget Interaction: The provider widget initializes the transaction by calling the `exchangeSdk.sell` method.

This triggers the Ledger Backend to initiate the transaction.

Backend Process:

Ledger Backend sends a \[POST] [/sell](./redoc-api#operation/postSell) request to the provider backend, requesting a signed payload for the transaction.

The provider backend processes the request and returns the signed payload.

Ledger Backend passes the signed payload to the Exchange SDK.

Device Approval:

The Exchange SDK prompts the Ledger device to approve or reject the transaction.

The user approves or rejects the transaction on their Ledger device.

### Step 6: Finalizing the Transaction

Post-Approval: After the transaction is approved, the exchangeSDK.sell promise notifies the provider widget about the transaction's result, including a transactionId if approved. It is the responsibility of the provider widget to inform the provider's backend of the final transaction status to initiate webhooks if the user has approved the transaction.

If the event the transaction is rejected, the provider is similarly notified.

### Real-Time Updates:

The provider backend sends real-time transaction status updates to the Ledger Backend via a `[POST] /webhook/status` endpoint.

Ledger Backend updates the transaction status in , ensuring the user is notified of the transaction's progress and completion.