---
title: "We've updated payment forms on Docturist"
url: 'https://graker.ru/en/news/2026/11/09/weve-updated-payment-forms-docturist'
language: en
type: post
author: 'Roman Grachev'
published: '2026-11-09T17:18:27+03:00'
updated: '2026-11-09T17:21:27+03:00'
categories:
  - 'Software Development'
translations:
  ru: 'https://graker.ru/news/2026/11/09/obnovili-formy-platezhey-na-dokturiste.md'
---

# We've updated payment forms on Docturist

![Форма введения платежа в Доктуристе](https://graker.ru/sites/default/files/styles/max_1300x1300/public/images/2026-11/1-payment-form.png.webp?itok=1F458PTI)

Astrologers proclaim Week of Usability. Number of UX updates on Docturist doubles.

Today we shipped another update to [Docturist](https://docturist.ru), this time going through the payment entry form.

Here’s the problem:
— tourists pay travel agents in rubles;
— agents pay tour operators in rubles too;
— but the total price of a foreign tour is set in dollars or euros at the operator’s exchange rate. So that nobody suffers from currency volatility.

The first implementation in Docturist was somewhat simplified. Payments in a booking card could only be recorded in the booking’s currency. So if we wanted to keep the books in euros, we had to mentally convert payments from tourists and to the operator (which are always in rubles) into the currency and only then save them. To make that possible, we added the option to use the Central Bank rate, use the operator’s rate (if we already import rates for that operator), or enter the rate manually. That way you can make the entered currency amount match the rubles actually received, but:
a) it’s inconvenient;
b) tiny penny-sized rounding errors can creep in;
c) especially when the rubles come from the bank and have to be automatically converted into the booking currency;
d) and, strictly speaking, it’s the rubles that need to be tracked, because profits and taxes are calculated in rubles.

As a result, the currency booking mode was barely used, simply because it was inconvenient. Most bookings were kept in rubles, and the currency balance with the tour operator was kept somewhere in the back of the head. And we always want everything to be convenient.

User stories came to the rescue. Not the kind where a business analyst describes a design mockup in words for the visually impaired, but stories from real, live users. Users told us how they use the form and how they would like to. We thought that experience over, and came up with a more progressive solution.

Now the payment creation window asks the user to enter not only the amount in currency and the rate, but also the rubles. And these three fields work on the “2 out of 3” principle. That is, the Vue.js component remembers which 2 values were edited last and calculates the third on the fly. So you can enter:
— (as before) the amount in currency and the rate, and get the amount in rubles;
— the amount in rubles and the rate, and get the amount in currency;
— the amounts in rubles and in currency, and the rate will adjust accordingly.

While we were at it, we inflicted some improvements on bank-imported payments too: for those, changing the ruble amount is now forbidden (it’s a bank fact, after all), so all that’s left is to enter either the currency amount or the rate.

Back to work!