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

# Going live

> Verification, live keys, limits and a checklist before real money.

## 1. Get verified

Like every payment company, One Pay checks who it works with before live
payments open. In the dashboard, an account owner fills in **Verification**:

* **A registered business**: its registration (RCCM in Cameroon, CAC in
  Nigeria), tax number, address, and the people who run and own it, with
  their ID documents.
* **An individual**: identity (and BVN and NIN in Nigeria), address and
  what you sell.

One Pay reviews it, usually within a working day, and may ask for a
change. Test mode works the whole time.

## 2. Create live keys and endpoints

Once approved, create a **live** API key (`sk_live_…`) and a live webhook
endpoint (https, public address) in the dashboard. Live and test keys,
payments, balances and webhooks never mix.

## 3. Add where your money goes

Under **Settlement**, an owner adds the business's own mobile money wallet
or bank account. One Pay checks it is in your business's name; then owners
and finance can withdraw to it.

## Limits

Each account may move a set amount in live mode, per payment and per day,
for payins and payouts in each currency. Your limits are on the dashboard's
**Payouts** page. A payment above a limit is refused with
`422 limit_exceeded` and nothing is created: the message says which limit
and, for the daily one, how much is left today. Days follow West Africa
Time (UTC+1); failed payments give their amount back to the day. Ask One
Pay to raise a limit as your volume grows.

## Checklist

**1. Keys are on your server only**

In environment variables or a secrets manager, never in a mobile app,
web page or repository.

**2. Every payin and payout has an idempotency key**

Your own order or transfer id, reused on every retry.

**3. Webhooks are verified**

Signature checked on the raw body, old timestamps refused, repeats
skipped by event id.

**4. Orders are delivered on payin.succeeded**

Not when the customer comes back to your site.

**5. Failures are handled**

`failed` payments tell the customer what to do next; `5xx` and `429`
answers are retried with the same idempotency key.

**6. You reconcile**

Compare your orders with `GET /v1/payins` and `GET /v1/payouts` each
day, and your balance with `GET /v1/balances`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.