What the buyer pays in

With the Buhgalter API the payment itself is always in rubles. Amounts go from 1 to 100,000,000 RUB. The buyer chooses a familiar method: SBP, an NSPK QR code, or a transfer by card number. For crypto native audiences there is also invoicing in USDT, BTC, ETH or TON, where the coin and network are pinned to the invoice on the payment page.

From the buyer's side this is the right default. People pay in the currency they already hold, in the banking app they already trust.

What you get paid in

Your merchant balance defaults to USDT. You can switch it to rubles. The rate is locked at the moment the payment is created, not when it settles. That single rule removes a whole category of reconciliation bugs.

How to pick:

• your costs are mostly abroad (servers, domains, contractors paid in stablecoins): keep USDT;
• your costs are mostly local (salaries, local suppliers, taxes): keep RUB;
• mixed: run separate storefronts, each with its own balance logic, and keep revenue apart in reports.

Modeling it in your database

Store three numbers per payment, not one:

CREATE TABLE payments (
  id            text PRIMARY KEY,
  amount_rub    numeric(14,2) NOT NULL,
  credited      numeric(18,6),
  credited_ccy  text,
  created_at    timestamptz NOT NULL
);

amount_rub is what the buyer paid. credited is what landed on your balance, in credited_ccy. Never recompute credited from today's rate; take it from the payment data.

For display only, GET /api/fx returns the current USDT/RUB rate. Use it to show an estimated amount on a pricing page, not for bookkeeping.

Payouts

Withdrawals to yourself go to a bank account, a card, or a USDT TRC-20 wallet, manually or as an auto payout. Payouts to your users go through POST /api/payouts to a card, phone number or account. Keep these two flows in separate services with separate permissions.

Time zones

Daily reports use Moscow time. If your servers run on UTC, your daily totals will drift by three hours at the day boundary. Either convert when you compare or store a report_day column computed in Moscow time.

Reports

For month end, the dashboard exports Excel and CSV for 1C, plus a printable reconciliation statement with opening and closing balances and turnover. The payments report shows created, paid, conversion, turnover, fee, credited and refunds. Fees apply only to successful payments, so expired and cancelled invoices show up in counts but cost nothing.

Summary

Let buyers pay in rubles with methods they know. Decide your settlement currency from where your costs are. Store both amounts, lock to the rate at creation, and reconcile in Moscow time. More details and API docs at https://buhgalter.app.

Alena Kotenkova, Buhgalter team