PaymentsIntegration
An international hotel aggregator in a single-supplier design
Hotel booking platform, 1M+ users a month
Otello (2GIS)
2025 to 2026 · Cross-team project; I owned the conversion side
~10%
of all bookings now go through it
The problem
To sell international hotels, the platform connected an aggregator whose model was unlike the domestic providers.
Our data model expected exactly one provider per booking. The aggregator was a whole set of suppliers behind one API, and the booking, payment and receipt rules were new.
What I did
- Owned everything after the search: booking creation, cancellation, the payment worker, receipts and the accounting reports for the new provider.
- Designed and implemented the nested supplier model (provider, then supplier), so the rest of the system kept working with a single provider ID.
- Dug out the missing pieces myself: tax identifiers, provider constants, undocumented API behaviour.
- Handed over a working conversion block when I moved to other work, and came back for a week later to close the remaining edges.
Decisions
- Extend the model with a supplier level under the provider instead of faking each supplier as a separate provider. Nothing else in the system had to learn about the aggregator.
- Ship under uncertainty with a few explicit temporary solutions, marked for rework, rather than block the launch on a perfect design.
What changed
- In production. About 10% of all bookings now go through the aggregator.
- When the search side was connected, the conversion side worked without changes.
- The team continued the integration without me after the handover.
Stack
GoPostgreSQLPayment workerReceiptsAccounting export