Limits, receipts and reconciliation
The questions that depend not on the API but on the contract, the acquirer or accounting: how much you may charge, who issues the fiscal receipt, where reconciliation data comes from, and how to restrict access at the network level.
What limits apply?
Limits on single-operation amounts and on daily turnover are set by the acquiring bank or the mobile operator — not by the platform. They can be changed for your project on request through your personal manager.
The order of magnitude to design against:
| Limit | Typical value |
|---|---|
| Single operation | up to 100,000 ₽ |
| Card operations per day | up to 100,000 ₽ |
| Daily turnover | up to 500,000 ₽ |
The values above are a reference point, not a guarantee: actual limits depend on the acquirer, the operator and your contract. If you expect amounts of the same order, confirm them with your manager before launch.
Exceeding a limit arrives as an ordinary payment decline. You can exercise that outcome without hitting a real limit in the sandbox — one of the test cards returns LimitExceeded, see Quick start.
Who issues the fiscal receipt?
It depends on whether the I-Free cash register module is connected.
I-Free cash registers. The receipt is sent automatically through the cash registers and the fiscal data operator. One thing is required from you — pass a correct customer email in the request: that is where the receipt goes. The field is optional in the API, but without it there is nowhere to deliver the receipt.
Your own cash register. If the cash register is yours, fiscalisation is entirely on your side: wait for the successful payment notification and issue the receipt yourself.
A link to a receipt issued by the I-Free cash registers arrives as a separate SendPaymentReceipt notification — a PaymentReceiptInfo block with a single ReceiptUrl field, see Webhooks.
What is in the reconciliation report?
The report is exported from the merchant account as an .xlsx file. Columns:
InvoiceId · MerchantOrderId · DateCreate · DateProcessed · ServiceNumber · Subscriber · EupCurrency · Eup · EupWithVat · Operator · PartnerProfit · PartnerProfitWithVat · InvoiceStatus · RefundStatus
Some columns repeat values you have already seen in the API: MerchantOrderId is the order identifier you passed when creating the invoice, and it is what the report is reconciled against on your side; InvoiceId, InvoiceStatus and PartnerProfit match the fields of the same name in the GET /invoices/{invoice_id} response and in the payment notification.
Out-of-band bank refunds and chargebacks do not go through the API. They are recorded by the bank and never appear in calls or webhooks — the reconciliation statements are the only place you will see them. Reconciling turnover from API data alone is therefore not enough.
Do I need to restrict access by IP?
Filtering on the platform side concerns inbound requests to the API: it is not mandatory and is enabled for a project on request, see Authentication.
The other direction: if your security policy requires accepting webhooks only from platform addresses, your personal manager will provide the list of I-Free IP addresses for your allowlist.