---
id: docs.team-roles
title: "Team roles and permissions"
canonical: https://docs.secureprocessing.app/team-roles
last_verified: 2026-11-06
---

# Team roles and permissions

Who on your team can do what, and why each line is drawn where it is.

Everyone on your team has one role. A role is a set of permissions, and every request — from the dashboard or straight to the API with a member’s own sign-in — is checked against it before anything happens. The dashboard hides what your role cannot do; the API refuses it either way.

The roles are Stripe’s, so if you have used Stripe you already know roughly what an analyst or a support account is for. Where we are stricter, it says so below.

## The roles

| Permission | Owner | Administrator | Developer | Analyst | Support | Viewer |
|---|---|---|---|---|---|---|
| View payments, refunds, disputes and reviews (`payments:read`) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Refund payments (`payments:refund`) | ✓ | ✓ | — | — | ✓ | — |
| Capture authorised payments (`payments:capture`) | ✓ | ✓ | — | — | ✓ | — |
| View customers (`customers:read`) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Create and edit customers and saved cards (`customers:write`) | ✓ | ✓ | ✓ | — | ✓ | — |
| Create and edit products and prices (`products:write`) | ✓ | ✓ | ✓ | — | — | — |
| Create and edit payment links (`payment_links:write`) | ✓ | ✓ | ✓ | — | — | — |
| Change the payout schedule and request payouts (`payouts:manage`) | ✓ | ✓ | — | — | — | — |
| Create, send and void invoices; manage tax rates (`invoices:write`) | ✓ | ✓ | ✓ | — | ✓ | — |
| Write risk rules and lists; approve flagged payments (`risk:manage`) | ✓ | ✓ | — | — | — | — |
| Create, roll and revoke test API keys (`keys:test`) | ✓ | ✓ | ✓ | — | — | — |
| Create, roll and revoke live API keys (`keys:live`) | ✓ | ✓ | ✓ | — | — | — |
| View and manage webhook endpoints (`webhooks:manage`) | ✓ | ✓ | ✓ | — | — | — |
| View events (`events:read`) | ✓ | ✓ | ✓ | ✓ | — | ✓ |
| Download reports and exports (`exports:read`) | ✓ | ✓ | ✓ | ✓ | — | — |
| View the team (`team:read`) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Invite people (`team:invite`) | ✓ | ✓ | — | — | — | — |
| Change roles and remove people (`team:manage`) | ✓ | ✓ | — | — | — | — |
| Edit business settings (`settings:business`) | ✓ | ✓ | — | — | — | — |
| Edit security settings (`settings:security`) | ✓ | ✓ | — | — | — | — |
| Fill in the activation application and its documents (`activation:manage`) | ✓ | ✓ | — | — | — | — |
| Transfer ownership (`account:transfer`) | ✓ | — | — | — | — | — |
| Close the business (`account:close`) | ✓ | — | — | — | — | — |
| Answer and accept disputes (`disputes:manage`) | ✓ | ✓ | — | — | ✓ | — |
| Create and cancel payments and checkout sessions (`payments:write`) | ✓ | ✓ | ✓ | — | ✓ | — |
| View the balance, payouts and balance reports (`balance:read`) | ✓ | ✓ | ✓ | ✓ | — | ✓ |
| View connected accounts (in live mode, platforms only) (`connect:read`) | ✓ | ✓ | ✓ | ✓ | — | — |
| Create connected accounts and send onboarding links (in live mode, platforms only) (`connect:write`) | ✓ | ✓ | ✓ | — | — | — |
| Give an application fee back to a connected account (in live mode, platforms only) (`application_fees:refund`) | ✓ | ✓ | — | — | ✓ | — |
| Create Sandboxes (`sandboxes:create`) | ✓ | ✓ | ✓ | — | — | — |
| Use test helpers, such as making a test payout fail (test mode only) (`test_helpers:write`) | ✓ | ✓ | ✓ | — | — | — |
| Change and delete any Sandbox (`sandboxes:manage`) | ✓ | ✓ | — | — | — | — |
| Choose your own notifications and read your inbox (`notifications:self`) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |

## Where we are stricter than Stripe

**An analyst changes nothing.** They read payments, customers, the balance and events, and they can download reports. They cannot refund, capture, create a payment or a customer, or edit the catalogue.

**Support does not see the books.** A support account answers one customer at a time: it can refund, capture, take a payment, edit a customer, raise an invoice and answer a dispute. It cannot see the balance, payouts or reports, cannot publish a price or a payment link, and never sees an API key or a webhook.

**Only an owner or an admin** may write risk rules, change payouts, fill in the activation application (it holds your directors’ identity documents) or manage the team. Only the owner may transfer or close the business.

## Actions that ask for your authenticator again

Some actions need a code from your authenticator app from the last ten minutes, not just one from when you signed in. A stolen session would want these first:

`keys:live`, `team:invite`, `team:manage`, `payouts:manage`, `settings:security`, `risk:manage`, `account:transfer`, `account:close`, rotating a webhook signing secret, and making a person's declarations on the activation application. Refunds do not: support refunds all day, and a challenge on every one teaches people to approve challenges without reading them.

## Two-step verification for live businesses

Once your business is approved for live payments, everyone on the team signs in with an authenticator app as well as their password or passkey. It cannot be turned off while live payments are on. A teammate who has not set one up is asked to when they next sign in.

Changing your password, your email address or your authenticator signs you out on every other device, and so does signing out other devices from your security page — at once, not when the session would have expired.

## API keys and permissions

A secret key can do everything the API offers a key — take and refund payments, manage customers, the catalogue, invoices, risk rules, disputes and webhooks, and read the balance, events and reports. It can never create another key, read identity documents or change the team: those are dashboard-only, for a signed-in person.

Nobody can create a key that can do more than they can. A full secret key can refund, so a **live** one can be created only by an owner or an admin. A developer can create test keys, which move no money. Live keys need a fresh code from your authenticator.

## When a request is refused

A request your role or key does not permit is answered with `403`, and `required_capability` names the permission that was missing:

```json
{
  "error": {
    "type": "permission_error",
    "code": "insufficient_permissions",
    "message": "Your role (analyst) does not have the payments:refund permission.",
    "required_capability": "payments:refund"
  }
}
```

> **Note:** Every operation in the API reference lists the permission it needs, as `x-required-capabilities` in the OpenAPI document.