Bókun × Bank of Georgia Checkout

Views Georgia Tours needed a Bank of Georgia payment journey connected to its existing Bókun reservation system and Duda website. The integration had to retrieve availability, respect participant and pricing rules, collect product-specific booking details, hold inventory during payment, and confirm a reservation only after payment verification. It also needed to preserve Bókun’s original totals while presenting the corresponding GEL amount.

I translated the booking and payment requirements into the application architecture and implemented the connection across the website, Bókun, and Bank of Georgia. My work covered the embedded selector, hosted checkout, exchange-rate handling, provider APIs, persistent booking states, and deployment configuration. The supplied project notes describe a client-specific integration for one vendor, website, and merchant account.

I built a standalone application with three parts: an embedded booking selector for Duda tour pages, a branded hosted checkout, and server-side payment-to-booking orchestration. The selector resolves the tour from the dynamic page, while the server validates it against Bókun. Checkout follows the current product’s required contact, passenger, pickup, extra, and booking questions instead of using a fixed form.

Bókun remains authoritative for product data, availability, pricing, questions, reservations, and final bookings. Signed, expiring checkout sessions carry validated selections into the hosted flow. The customer’s return from the bank is never used as proof of payment: the server verifies the transaction, amount, and currency with Bank of Georgia before attempting booking confirmation.

A shared vanilla JavaScript selector works through Duda’s HTML controls. It resolves the activity identifier from published page data, and the server validates that identifier. Participant categories, group-size tiers, participant limits, and available departure times are part of the selection logic.

The checkout retrieves the questions and options associated with the selected booking. Answers are validated and mapped to Bókun’s booking structure; changes refresh the relevant questions while preserving answers that still apply.

The application retains the original product total, GEL amount, exchange rate, and rate date. Bókun keeps its original-currency amounts; the bank receives the GEL total. Missing exchange-rate data stops checkout rather than allowing an unverified charge.

PostgreSQL stores order state, payment references, provider events, transitions, and operation attempts. A verified payment with an incomplete booking remains confirmation-pending, giving recovery a clear state rather than asking the customer to pay again.

The supplied implementation notes describe server-side credentials, encrypted stored provider credentials, signed checkout sessions, and bank-hosted card entry. Card details are entered on the bank’s page rather than stored by the application. These design choices are not presented as an independent security certification.

The integration is running for Views Georgia Tours, and the client has received payments through it. It connects the existing Bókun booking setup with a branded checkout and Bank of Georgia payment collection in GEL. The delivered application includes inventory-aware selection, product-driven booking forms, temporary reservations, server-side payment verification, and explicit recovery states. No transaction volume, conversion uplift, revenue total, or time-saving metric is claimed.

This is a client-specific integration, not a public Bókun marketplace payment gateway. Automated refunds, multi-vendor support, and a customer portal are outside the documented V1 scope. Additional vendors or payment providers would require further development and validation.

The booking and payment system is active and running for Views Georgia Tours. The client has received payments through the integration, as confirmed by Luka. The screenshots were captured during testing and may show earlier test-environment labels; they do not represent the current operational status.