Payment page

The payment page is the only part of Invoicebox the buyer sees. The merchant creates an order and redirects the buyer there; they pick a payment method, pay and return to the merchant's site.

What the buyer sees

The set of methods depends on who is paying. The type comes from customer.type in the order, or the buyer picks it on the page if the merchant allows the choice.

Payment method	Individual	Company or sole trader	What it produces
Bank card	yes	yes	Fiscal receipt, online cash register
SBP by QR code	yes	yes	Fiscal receipt
SBP B2B	no	yes	Invoice and closing documents
Invoice payment	no	yes	Invoice, then act, invoice and UPD after payment
Deferred payment	no	yes	Same documents; the seller gets the money right away (timing)
Promised payment	no	yes	Card confirmation, transfer within 5 days
Guarantee fund	no	yes	Charge against the company balance, confirmed by code

An individual gets a receipt, a company gets a document set. Hence a simple rule: if closing documents matter in your scenario, pass customer.type: legal together with the company details.

What the merchant configures

Where the buyer returns. itransfer_url_return and itransfer_url_returnsuccess in the widget, or the matching order fields in the API.
Invoice lifetime. The expirationDate field: once it passes, an unpaid order can be cancelled.
Page language. RU or EN, set when the order is created.
Extra services. If the merchant is connected to the marketplace, partner offers appear on the payment page.

How to learn about the payment

The buyer landing on your thank-you page proves nothing: that address opens in a browser and can be typed by hand. The only reliable signal is the order status notification. Trigger shipping, service delivery and everything else from it. For reconciliation use order retrieval.

What next

B2B payment instruments — how the methods for companies differ.
Document flow schemes — which documents each scheme produces.
Ready-made CMS modules — if you would rather not wire the redirect yourself.