The Payment Link That Closes the Invoice: Monobank Acquiring in the CRM
An invoice is sent, the client replies 'how do I pay?', and the chase begins: bank details, a screenshot, a manager checking the account, a note in the CRM. In Firmspace the invoice window can create a payment link from the firm's own acquiring account, and the bank closes the invoice when the money actually arrives. The interesting part is not the button; it is the chain of checks between the click and the paid status.
The link is built on the invoice, not in a separate payment module. Finance → Invoices → Payment link offers only the providers the firm has connected. In the Ukrainian market that is monobank, LiqPay, WayForPay or crypto acquiring; in Uzbekistan the list is Payme and Click. If no provider is connected, the window says so instead of producing a dead link. The money goes to the firm's own merchant account; Firmspace does not hold or route it.
The amount is the outstanding balance, not necessarily the invoice total. If a client has already paid an advance, the link is created for gross minus paidAmount; an invoice that is already covered is refused. The invoice currency travels with the link. For monobank, the CRM converts the amount to kopecks and maps UAH, EUR and USD to the provider's currency codes; an invoice in another currency is worth checking before the link is sent.
The link can be copied, or sent straight into an existing conversation with the client in Telegram, Viber or WhatsApp. The window lists only conversations that already exist, because messengers do not let a business write first to someone who never wrote to it. That is a constraint of the channels, not of the invoice. The client receives a normal message with the URL and pays on the provider's page; no card data passes through the CRM.
The redirect back to the CRM is not the proof of payment. The proof is the webhook the provider sends to a URL bound to the firm's integration token. For monobank the request is signed with the merchant's private key; the CRM fetches the matching public key from monobank and verifies the ECDSA signature over the raw body. A request with a wrong or missing signature is rejected with 403. Without that check, anyone could POST a JSON that says 'paid'.
Statuses are read literally. Only success becomes a payment. A failure or reversal is read as a failed status; processing and hold are neither: the CRM acknowledges them and changes nothing. This is the difference between a hold on a card and money that has arrived, and a CRM that treats a hold as revenue is worse than one that waits. The webhook answers quickly and does not depend on the browser tab that created the link.
Providers repeat deliveries, so the route is idempotent. It hashes the raw notification body and stores that fingerprint together with the provider and the firm; a second delivery of the same bytes hits the unique key and is confirmed without adding the amount again. Partial payments accumulate in paidAmount, and the invoice becomes paid only when the accumulated sum reaches the total. A payment is a fact with a date, so it cannot be booked into a closed accounting period: the route answers 423 and the month stays locked.
A full payment triggers the ordinary consequences, each in its own step so that a failure in one does not undo the money: an audit entry, a payment in the customer's activity feed, an automation event invoice_paid (or invoice_partial_paid), an in-app notification. If the invoice belongs to an order, the order moves to paid. If it belongs to a deal and no other invoice of that deal is open, the deal can be won automatically, unless the firm switched that rule off. If Checkbox is connected and auto-fiscalisation is on, a card payment also produces the fiscal receipt.
The AI assistant is on both sides of this chain, but not on every step. It can create a draft invoice, send it by mail, change a due date, mark an invoice paid, and answer whether an invoice is still open. It has no tool for creating a payment link: that stays a deliberate action in the invoice window, because the link is a commercial decision about how the client will pay. And when the acquiring webhook has already closed the invoice, marking it paid again is refused: the invoice is no longer open.
The honest limits are worth naming. The link needs a connected acquiring account with working merchant credentials; a rejected token stops the creation before a link exists. The checkout is built around hryvnia, euro and US dollar, so an invoice in another currency needs a check rather than an assumption. The payment proves itself through the provider's signature, not through the client's screenshot. A refund or a reversal is a separate event: this route reads the provider's status and does not rewrite the invoice; the money side is handled where the refund is actually made.
What changes is the queue of small manual steps. The manager no longer watches the bank app to mark an invoice; the client pays on a page that already knows the amount and the reference. The assistant can still answer the questions around the payment, and the audit trail shows who did what. The link is not a promise that every client will pay, and this article does not pretend otherwise; it removes one place where money and records usually drift apart.