Skip to content
Case study · GlobalTips

BLIK for the bill, and staff who set themselves up

GlobalTips called us in for one feature in their guest app. After 14 monthly cycles, we now build across their guest app, staff app and web products, and BLIK carries about 15% of their payments in Poland.

Client
GlobalTips
Industry
Payments, Hospitality, FinTech
Tech stack
Swift, SwiftUI, Swift 6 concurrency, AVFoundation, Xcode String Catalogs, Vue, Vite, REST
Timeline
Since July 2025, ongoing
OutcomeWhat the work delivered
~15%
of payments in Poland now go through BLIK, with Pay by Account at a similar share in Lithuania
+30%
onboarding efficiency for restaurant staff after the flow was rebuilt
14
monthly cycles in a row, each closed with a signed acceptance protocol and a release
In their words

We've been working with WislaCode since July 2025. What started as enhancing the loyalty program in our GlobalTips guest app grew into a broader partnership where they now handle significant frontend development across our guest app, staff app, and web products.

Dzmitry Khabibullin, founder and CEO of GlobalTips
Dzmitry KhabibullinFounder and CEO, GlobalTips
Read the review
The challengeThe brief, and what was at stake

GlobalTips lets a guest pay the bill and leave a tip from their phone, and lets the waiter collect what they earn and split it with the team. Both halves move money, so both halves have to work first time, in a room where somebody is standing and waiting. By the client's own count, more than 1,600 venues run on the platform.

The platform worked, and it took cards and wallets. That is a narrow way to get paid in this part of Europe. A guest in Warsaw reaches for BLIK, a guest in Vilnius pays straight from their bank account, and neither of them is going to learn a new habit at the end of dinner. The staff side had the same gap in a different place: a waiter could not get themselves registered, and could not move their own money, without going through support.

The interface was older than the design system the client had since built in Figma, so every new screen drifted a little further from the one the designers had drawn.

None of it could arrive as one big release. Restaurants run the product during service, which means every change had to go into a live system and leave everything already in it working.

Payments in hospitalityBuilding payments people use during service?

We add local payment methods, loyalty and staff tools to a live product in monthly cycles, each one ending in a release.

How we built itWhat WislaCode designed and shipped
01One month at a time

We work in monthly cycles. Each has a written scope with a start and an end date, and closes with a signed acceptance protocol and a build published to the App Store, joined by a web deployment once the web work came to us. Since July 2025, 14 have run back to back without a month skipped.

That rhythm is most of the story. It is what let a client who hired us for one feature keep handing over the next thing, and the next, until the guest app, the staff app and the web products were all being built in the same place.

02Paying the way people already pay

BLIK went in twice over, because Poland uses it two ways: the six-digit code typed straight into the app, and a redirect to eBLIK where the backend says the user belongs there. The app asks the backend which of the two to open, so the routing stays a server decision. MB WAY followed for Portugal, with the guest entering a phone number and confirming the payment in the MB WAY app.

Then Pay by Account, the harder one: open banking payments taken straight from the guest's bank account, with a bank picker grouped by country, a hop into the guest's own banking app, and status polling until the payment resolves. In Poland, BLIK now carries about 15% of the platform's payments, and Pay by Account a similar share in Lithuania.

GlobalTips guest app tip screen with BLIK, Apple Pay and card
03A reason to open the app again

Loyalty was built in three passes, each on top of the last. Points first, earned on in-app payments, with a balance and a history a guest can check. Then membership tiers, with a discount attached to each. Then a rewards catalogue to spend the points on. GlobalTips says the programme raised how often guests come back.

Next to it, an Inbox, so a restaurant can send an offer to the guests who have already paid there: formatted messages with images and links, grouped by sender, push notifications, and a mute switch per sender for the guest who has had enough.

04A menu a guest can search

A digital menu is a long scroll, and a guest with a waiter at the table does not scroll. So the menu got an index screen built from the restaurant's real category structure, and full text search across names, descriptions and categories with relevance ranking. Results carry the price and the picture and add to the order with a quantity, which turns finding and ordering into one movement.

GlobalTips guest app menu with dishes added to the order in one tap
05One design system, two platforms

We took the client's Figma design system and rebuilt the Restaurant and Digital Menu screens on iOS and on the web, replaced SF Symbols with a platform-independent icon set, and left behind a reusable component library, so the next screen does not need a designer to draw it from scratch. iOS 26 requirements including Liquid Glass are supported while iOS 17 still works.

Around the same time we put in event tracking with batching, session tracking across background and foreground, and offline persistence that sends the deferred events once the network comes back. A/B testing sits on top of it: experiment configuration comes from the backend, variants apply to behaviour as well as to interface, and a user's assignment persists so their experience stays the same between sessions. After that, an argument about which version is better has somewhere to go.

06Staff who handle their own money

The onboarding rebuild is the piece the client measured. The flow is driven by the server: the API returns what the profile is still missing and the app routes to that step, so the sequence can change without shipping a new build. Document and selfie capture run on an actor-based camera session under Swift 6 strict concurrency. PESEL, IBAN and postal code are checked on the device before anything is submitted, which is the difference between a waiter finishing registration in the staff room and a waiter giving up. GlobalTips measured onboarding around 30% more efficient after the rebuild.

Then the money itself. A Home tab covering the personal balance, the tip pool accounts and the savings account, with payouts to a bank account and tip pool distribution in three modes: by amount, by percentage, by shares. After it, a Statistics tab whose layout comes from the server, so a new module type can appear for a team without waiting on an App Store review.

GlobalTips staff app home screen with the waiter's balance and withdrawal
GlobalTips staff app savings account fed from tips
07The floor under all of it

Between features we replaced the legacy Combine networking layer with async/await, added retry with exponential backoff, and built a per-endpoint mocking layer so previews and tests stop depending on a live backend. Localisation moved to Xcode String Catalogs with a code generator that turns keys into compile-time-checked symbols, under a naming convention shared across iOS, Android and web, so a missing translation key now stops the build before it can reach a screen. Both changes were our own proposals.

On the web side: payment page work including 3DS and custom domains, the admin, business, sales and staff panels, German and Ukrainian localisation, and a Vite-based build.

Every cycle ends the same way: unit and integration testing on what was built, then a pass over the screens and flows that were already there, before the release goes out.

Have a similar challenge?Let's map the fastest safe path to live

Book an integration review. Bring one stuck or upcoming integration - we'll diagnose it with you and scope the work, no obligation.