---
title: "Quick Start"
description: "Go from Telegram sign-in to your first hosted checkout and verified deposit."
canonical_url: "https://checkout.verify.et/docs/quick-start"
markdown_url: "https://checkout.verify.et/docs/quick-start.md"
last_updated: "2026-10-06"
x_farming_labs_generated_preamble: true
---

# Quick Start
URL: /docs/quick-start
LLM index: /llms.txt
Description: Go from Telegram sign-in to your first hosted checkout and verified deposit.
Related: /docs/dashboard-setup, /docs/integration, /docs/webhooks

# Make your first deposit

This guide follows the same order as the dashboard. You will need a receiving
account that your business controls and a backend where secrets can be stored.

<AgentSkillCard />

<QuickStartSteps>
  <QuickStartStep number={1} badge="Monthly Starter credits">
    ## Sign in with Telegram

    Continue with Telegram. A new workspace receives monthly Starter
    verification credits; creating a checkout does not consume a credit.
    <DashboardActionCard href="/login" title="Open Verify Checkout" description="Sign in or create your merchant workspace." action="Continue with Telegram" />
  </QuickStartStep>

  <QuickStartStep number={2} badge="Required">
    ## Complete Business Details

    Add your business name and upload the logo shown on checkout. PNG, JPEG, and
    WebP images up to 7 MB are accepted. Phone, website, and support URL are useful
    to customers, but do not block setup.
    <DashboardActionCard href="/dashboard/workspace" title="Business Details" description="Set the name and checkout logo customers will trust." action="Configure workspace" />
  </QuickStartStep>

  <QuickStartStep number={3} badge="Available immediately">
    ## Add a receiving account

    Choose a supported provider and enter an account owned by your business. New
    receiving accounts are active as soon as they are created.
    <DashboardActionCard href="/dashboard/accounts/new" title="Receiving account" description="Add the destination where customers will send money." action="Add account" />
  </QuickStartStep>

  <QuickStartStep number={4} badge="Copy once">
    ## Create an API key

    Create a key with the deposit permissions you need. Copy the `vchk_…` secret
    immediately—the dashboard cannot reveal it again.
    ```bash
    VERIFY_CHECKOUT_API_KEY=vchk_replace_with_your_secret
    ```
    <DashboardActionCard href="/dashboard/developers" title="API keys" description="Create, scope, rotate, and revoke server credentials." action="Create key" />
  </QuickStartStep>

  <QuickStartStep number={5} badge="Required">
    ## Register the return domain

    Add and activate the exact origin that will receive the customer after
    checkout, such as `https://shop.example.com`. The scheme, host, and port of
    every `return_url` must match. HTTP is accepted only for loopback development.
  </QuickStartStep>

  <QuickStartStep number={6} badge="Server-side">
    ## Create a deposit

    Use a fresh idempotency key for this logical deposit. Omit `amount` to let the
    customer enter it, or send an ETB amount for a fixed checkout.

    <CodeGroup>
        ```bash title="cURL"
        curl --request POST 'https://checkoutapi.verify.et/v1/deposits' \
          --header "Authorization: Bearer $VERIFY_CHECKOUT_API_KEY" \
          --header 'Content-Type: application/json' \
          --header 'VerifyCheckout-Version: 2026-06-01' \
          --header 'Idempotency-Key: order_1042_deposit' \
          --data '{
            "merchant_customer_id": "customer_42",
            "amount": "250.00",
            "currency": "ETB",
            "return_url": "https://shop.example.com/payments/return"
          }'
        ```
        ```ts title="TypeScript"
        const response = await fetch("https://checkoutapi.verify.et/v1/deposits", {
          method: "POST",
          headers: {
            Authorization: `Bearer ${process.env.VERIFY_CHECKOUT_API_KEY}`,
            "Content-Type": "application/json",
            "VerifyCheckout-Version": "2026-06-01",
            "Idempotency-Key": "order_1042_deposit",
          },
          body: JSON.stringify({
            merchant_customer_id: "customer_42",
            amount: "250.00",
            currency: "ETB",
            return_url: "https://shop.example.com/payments/return",
          }),
        });

        if (!response.ok) throw new Error(`Deposit creation failed: ${response.status}`);
        const result = await response.json();
        ```
    </CodeGroup>
  </QuickStartStep>

  <QuickStartStep number={7} badge="60-minute link">
    ## Send the customer to checkout

    Read `data.checkout_url` from the `201` response and redirect the customer's
    browser to it. Store `data.id` in your system before redirecting.
    ```ts
    window.location.assign(result.data.checkout_url);
    ```
  </QuickStartStep>

  <QuickStartStep number={8} badge="Webhook recommended">
    ## Reconcile the result

    Poll `GET /v1/deposits/{depositId}` until the deposit reaches a terminal state.
    For production automation, add a signed webhook and keep polling as a recovery
    path. A webhook tells your backend that the deposit changed; the deposits API
    returns its authoritative current state. Credit your customer exactly once,
    keyed by the Verify Checkout deposit ID, and only when that state is `succeeded`.
    <DashboardActionCard href="/dashboard/developers/webhooks" title="Webhook endpoints" description="Receive signed outcome events automatically." action="Add optional webhook" />
  </QuickStartStep>
</QuickStartSteps>

<Callout type="warning" title="Keep the secret behind your backend">
  Browser and mobile code must call your backend, not the Verify Checkout API
  directly. Never paste a real API key into documentation, source control, or chat.
</Callout>

Next, read [Create a deposit](/docs/integration) for every request shape and
[Reconciliation](/docs/reconciliation) before crediting customer balances.

## Sitemap

Sitemap discovery is not enabled for this deployment.