# 

This section is for platforms and resellers — anyone boarding merchants rather than taking their own payments. If you are integrating a single merchant account that already exists, you can skip it and start at [Accept a card payment](/docs/payments/accept-a-card-payment).

## Clients

A **client** is an account that can process payments. Every transaction belongs to exactly one, and there are two kinds.

| `type` | What it is |
|  --- | --- |
| `merchant` | Processes payments. Has no children |
| `reseller` | Resells to merchants. Owns the clients beneath it |


Both values are **lowercase**, exactly as written. `MERCHANT` is rejected.

## The hierarchy

Clients form a tree. `parent_id` on a client names the reseller or ISO above it. It is set when the client is created, and every update has to send it too. An update that sends a different parent moves the client, so send the current one unless that is what you mean.

```text
reseller  CLIENT-…A
├── merchant  CLIENT-…B     parent_id: CLIENT-…A
├── merchant  CLIENT-…C     parent_id: CLIENT-…A
└── reseller  CLIENT-…D     parent_id: CLIENT-…A
    └── merchant  CLIENT-…E parent_id: CLIENT-…D
```

A reseller sees its own subtree. A merchant sees only itself.

## Each client has its own credentials

Creating a client issues an API key for it. That key and the client's ID are what [authenticate](/docs/get-started/authentication) its requests.

**The key is returned once**, on the create response, and no later call returns it again. Store it then or reissue the client.

## A parent can act for a child

A reseller does not need its merchants' keys. It authenticates as itself and names the merchant in the `X-Acting-As-Client-Id` header.

That is how a platform runs a transaction, reads a report, or boards an integration on a merchant's behalf. See [Act on behalf of a client](/docs/platforms/act-on-behalf-of-a-client).

## Integrations attach to a client

A client cannot process anything until it has an **integration** — the processor credentials that connect it to TSYS for cards or VeriCheck for ACH.

One client can hold both. The payment method in a transaction decides which one handles it. See [Connect a processor](/docs/platforms/connect-a-processor).

## What the API does not model

Worth knowing before you design around them:

* **No users.** There is no public user, role, or permission resource. A client is the unit of access, and its API key is the credential.
* **No delete.** Clients and integrations cannot be removed through the API. Deactivate an integration with `is_active: false`.
* **No customers.** The gateway stores no customer records. Your application owns the relationship between a person and a [saved payment method](/docs/payments/save-and-reuse-a-payment-method).


## Next steps

* [Create and update a client](/docs/platforms/create-and-update-a-client)
* [Connect a processor](/docs/platforms/connect-a-processor)
* [Act on behalf of a client](/docs/platforms/act-on-behalf-of-a-client)