> ## Documentation Index
> Fetch the complete documentation index at: https://oblodai.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Счёт и чек на почту
Шлюз умеет сам писать покупателю письма — и вам для этого не нужен ни SMTP‑сервер, ни шаблоны, ни
очередь рассылки. Есть два сценария, и они решают разные задачи.
| Сценарий | Что делает | Кто инициирует |
| -------------------- | -------------------------------------------------------- | --------------------------------------------------------------------------- |
| **Чек после оплаты** | Покупатель заплатил → ему автоматически уходит чек. | Шлюз, сам. Достаточно задать `payer_email` при создании платежа. |
| **Счёт до оплаты** | Покупателю уходит письмо со счётом и кнопкой «Оплатить». | Вы, вызовом [`POST /v1/payment/send-email`](/reference/payment-send-email). |
***
## Автоматический чек после оплаты
Это самое дешёвое улучшение вашей интеграции: **одно поле**.
```python Python theme={null}
call("/v1/payment", {
"amount": "10", "currency": "USD", "order_id": "order-1",
"to_currency": "USDT", "network": "tron",
"payer_email": "buyer@example.com", # ← этого достаточно
})
```
```js Node.js theme={null}
await call("/v1/payment", {
amount: "10", currency: "USD", order_id: "order-1",
to_currency: "USDT", network: "tron",
payer_email: "buyer@example.com", // ← этого достаточно
});
```
Когда платёж перейдёт в оплаченный статус, на этот адрес **автоматически** уйдёт чек. Ничего больше
вызывать не нужно.
**`payer_email` — это не просто справочное поле.** Раньше его описывали как «email плательщика», и
многие передавали его «на всякий случай», не зная, что он включает отправку чека. Если вы **не**
хотите, чтобы покупателю уходило письмо, — не заполняйте `payer_email`.
Почему это стоит включить: криптоплатёж выглядит для покупателя тревожно (деньги ушли «в никуда», в
блокчейн, отменить нельзя). Письмо‑чек с подтверждением снимает основную часть обращений в поддержку
вида «я заплатил, вы получили?».
***
## Отправить счёт письмом
Если вы хотите **выставить счёт** — то есть попросить оплатить, а не подтвердить оплату — используйте
[`POST /v1/payment/send-email`](/reference/payment-send-email). Покупателю придёт письмо со счётом
и кнопкой «Оплатить», ведущей на страницу оплаты.
Платёж при этом должен уже существовать: письмо отправляется **по** платежу, а не вместо него.
```python Python theme={null}
# 1. Создаём счёт как обычно
inv = call("/v1/payment", {
"amount": "250", "currency": "USD", "order_id": "invoice-42",
"payer_email": "client@example.com",
})["result"]
# 2. Отправляем его клиенту письмом
call("/v1/payment/send-email", {"order_id": "invoice-42"})
```
```js Node.js theme={null}
// 1. Создаём счёт как обычно
const inv = (await call("/v1/payment", {
amount: "250", currency: "USD", order_id: "invoice-42",
payer_email: "client@example.com",
})).result;
// 2. Отправляем его клиенту письмом
await call("/v1/payment/send-email", { order_id: "invoice-42" });
```
Идентифицировать платёж можно двумя способами — что удобнее:
```python Python theme={null}
call("/v1/payment/send-email", {"uuid": inv["uuid"]}) # по uuid платежа
call("/v1/payment/send-email", {"order_id": "invoice-42"}) # по вашему order_id
```
```js Node.js theme={null}
await call("/v1/payment/send-email", { uuid: inv.uuid }); // по uuid платежа
await call("/v1/payment/send-email", { order_id: "invoice-42" }); // по вашему order_id
```
### Отправить на другой адрес
По умолчанию письмо уходит на `payer_email`, записанный в платеже. Чтобы отправить на другой адрес —
передайте `email` явно:
```python Python theme={null}
call("/v1/payment/send-email", {
"order_id": "invoice-42",
"email": "accounting@client.example", # например, в бухгалтерию клиента
})
```
```js Node.js theme={null}
await call("/v1/payment/send-email", {
order_id: "invoice-42",
email: "accounting@client.example", // например, в бухгалтерию клиента
});
```
Это же — способ **переслать счёт повторно**, если клиент говорит «письмо не пришло»: просто вызовите
метод ещё раз.
***
## Типичный поток «выставил счёт → получил оплату»
```
1. POST /v1/payment → создали счёт (payer_email = клиент)
2. POST /v1/payment/send-email → клиенту ушло письмо со счётом и кнопкой «Оплатить»
3. Клиент открывает письмо, жмёт кнопку, попадает на страницу оплаты, платит
4. Вам приходит вебхук invoice.paid
5. Клиенту АВТОМАТИЧЕСКИ уходит чек (потому что payer_email задан)
```
Шаг 5 — бесплатный бонус за то, что вы заполнили `payer_email` на шаге 1.
**Счёт без своего сайта.** Если бэкенда нет вообще, тот же результат даёт
[платёжная ссылка](/guides/payment-links): создали, отправили клиенту любым способом. А на странице оплаты
покупатель может сам указать свой email — и чек ему уйдёт так же автоматически.
***
## Ошибки
| Код | Значение | Что делать |
| ------------------------ | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| `400 email.no_recipient` | Некому отправлять: в платеже нет `payer_email`, и `email` в запросе не передан. | Передайте `email` явно или задавайте `payer_email` при создании платежа. |
| `503 email.disabled` | Отправка почты временно недоступна. | Временная ошибка — повторите с backoff. Платёж при этом жив, письмо можно отправить позже. |
| `404 payment.not_found` | Платёж по `uuid`/`order_id` не найден. | Сверьте идентификатор. |
***
## Практические правила
* **Валидируйте email на своей стороне.** Шлюз отправит письмо туда, что вы передали; опечатка в
адресе = чек ушёл в никуда.
* **Не считайте письмо доказательством оплаты.** Источник правды о статусе — вебхук `invoice.paid` и
[`POST /v1/payment/info`](/reference/payment-info), а не факт отправки письма.
* **`503 email.disabled` — не повод откатывать заказ.** Почта — вспомогательный канал; платёж от него
не зависит.
***
## Связанные страницы
поле `payer_email`.
как узнать об оплате достоверно.