# Pay systems

Select a payment system or a delivery service. Create your own records using a registered REST handler. Scope: `pay_system`.

Built-in services are readable. Bitrix24 permits updates and deletion only for REST-handler records; OAuth applications are also checked against handler ownership. The sale scope alone is insufficient.

## Operations

- [List](./pay-systems/list.md) — `GET /v1/pay-systems`
- [Get](./pay-systems/get.md) — `GET /v1/pay-systems/:id`
- [Create](./pay-systems/create.md) — `POST /v1/pay-systems`
- [Update](./pay-systems/update.md) — `PATCH /v1/pay-systems/:id`
- [Delete](./pay-systems/delete.md) — `DELETE /v1/pay-systems/:id`
- [Handlers](./pay-systems/handlers.md) — `GET /v1/pay-systems/handlers`

## Key fields

Pass id as the payment paySystemId. Read bxRestHandler codes from handlers. The payment list does not return a logo.

[All fields](./pay-systems/fields.md).

## Before you start

Handlers are registered separately: these routes only read their definitions. active and newWindow use Y/N strings, not booleans.

Without active a new pay system is inactive (N). When CRM is installed, Bitrix24 defaults entityRegistryType to CRM_INVOICE: for orders, send ORDER and a payer type from that registry.

## Typical workflow

Read handlers, select a code, create an inactive VIBE-PROBE record, read it, update name, then delete only your own record. Readback can fail after a successful write: do not blindly retry creation.

## Limits

Lists are complete, without limit/offset; meta.total equals data length. No search, aggregate or generic batch. Logo: logo [filename, base64], up to 2 MiB decoded, JSON body up to 3 MiB. SETTINGS/CONFIG are accepted only on creation.

## Write restrictions

| Record | GET | PATCH / DELETE |
|---|---|---|
| Built-in | Yes | 403 |
| REST | Yes | Subject to Bitrix24 rights and OAuth ownership |

## Related entities

- [Payments](/docs/entities/payments)
- [CRM payments](/docs/entities/crm-payments)