---
id: docs.activation
title: "Going live"
canonical: https://docs.secureprocessing.app/activation
---

# Going live

What we need before your account can take real money, and what happens after you send it.

## Test mode works immediately. Live mode does not.

Every account starts in test mode with a `sk_test_` key, and everything in these docs works against it from the moment you sign up — payments, refunds, webhooks, invoices, the lot. What test mode will not do is move real money.

Live keys are refused until your account is activated. That is not a setting you can turn on: we must verify every business before it takes real money.

## What we ask for

You fill this in from the dashboard, under **Settings → Activation**. Nothing here is asked twice and you can save half of it and come back.

|   | What it is |
|---|---|
| The business | Registered legal name, what kind of business it is, the registered address, a phone number and a support email your customers can reach. |
| What you expect to process | Roughly how much a month, and a typical transaction size. An estimate is fine; it tells us what normal looks like for you so that unusual is visible. |
| The people behind it | At least one owner or director, with a date of birth and an identity document. If someone owns 25% or more of the business, name them. |
| Your bank account | Where payouts go — the bank, the name on the account, the account number, and a recent statement for it. |
| Business registration | Your certificate of incorporation or trade licence. A tax certificate too, if you have one. |

> **Warning:** Identity documents and bank account numbers are encrypted before they are stored, and only the last four digits of an account or ID number appear anywhere in the product — including to us, unless someone on our side deliberately reveals one, which is recorded.

**How long we keep your documents.** The law decides this, not us. Belize's anti-money-laundering and payment-system rules, and the card networks' own rules, require us to keep the documents that identify a business for years after the relationship ends. While your account is active we keep them; after it is closed we keep them for seven years. If an application is declined, its documents are kept for five years after the decision. If you start an application and never submit it, its documents are deleted after 90 days without activity. Documents involved in an open dispute, or that we are legally required to preserve, are kept until that is resolved.

## Checking from the API

`GET /v1/account` tells you where you stand. It is the endpoint to branch on before attempting anything with a live key.

```json
{
  "id": "acct_1aB2cD3eF4gH5iJ6kL7mN8oP",
  "object": "account",
  "name": "Blue Hole Diving",
  "live_enabled": false,
  "capabilities": {
    "card_payments": "inactive",
    "payouts": "inactive"
  },
  "application_status": "draft",
  "requirements": {
    "currently_due": [
      "business.address",
      "bank.bank_account_number",
      "persons.owner_or_director"
    ]
  }
}
```

`requirements.currently_due` is what is still missing, as keys. An empty list means the application can be submitted. It is computed by the same function that decides whether a submission is accepted, so the two cannot disagree — if the list is empty the submit will go through.

| Key | Means |
|---|---|
| business.legal_name | The registered legal name of the business. |
| business.business_type | Sole proprietor, company, partnership or NGO. |
| business.address | The registered address. |
| business.phone | A contact phone number. |
| business.support_email | A support address your customers can reach. |
| business.expected_monthly_volume | Roughly how much you expect to process each month, in minor units. |
| bank.bank_name | The bank your payouts should go to. |
| bank.bank_account_name | The name on that account. |
| bank.bank_account_number | The account number. |
| documents.bank_statement | A recent statement for that account. |
| documents.business_registration | Your registration document. |
| persons.owner_or_director | At least one owner or director. |
| persons.id_document | An identity document for one of them. |

## What happens after you submit

A person reads it, and checks what you told us — the business registry, the sanctions lists, and the identity of each person you named. We deliberately do not promise a turnaround here, because we would rather not give you a number we might miss — if it is taking longer than you expected, ask us.

There are three outcomes and you get an email for each:

| Outcome | What it means |
|---|---|
| Approved | Your account is active. live_enabled becomes true, card_payments becomes active, and your live keys start working. The bank account on your application becomes your payout account. Payouts start once we have checked that account against your statement: until then capabilities.payouts is pending and your balance is held for you, not lost. |
| More information needed | We list exactly what we need, one information request per item, on your application. It reopens for editing and you submit it again — nothing you already filled in is lost. Resubmitting answers the requests to correct a field or replace a document; a question that needs an answer in words is answered on its own, with POST /v1/account/application/information_requests/{id}/respond. |
| Declined | We tell you as much as we are able to. Get in touch if the circumstances change and we will look at it again. |

## The events

If you are building onboarding on top of us, subscribe to these rather than polling — an account’s status changes once or twice in its lifetime, which is the worst possible thing to poll for.

| Event | When |
|---|---|
| application.submitted | The application was sent for review. |
| application.updated | We decided. The payload carries status — approved, rejected or more_info — and the reason we gave. |
| account.updated | The account's standing changed. On an approval this fires alongside application.updated, and it is the one carrying live_enabled and capabilities. |

> **Note:** Every one of these is delivered in both test and live mode. A merchant whose only webhook endpoint is a test-mode one is exactly the merchant who needs to hear that they have just been switched live.
