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.
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.
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.
We add local payment methods, loyalty and staff tools to a live product in monthly cycles, each one ending in a release.
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.
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.

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.
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.

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.
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.


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.
iOS apps for regulated products - design, build, testing and App Store release discipline.
See the service Web frontend developmentWeb Frontend Development - IT services for financial and banking. Web and Mobile App Development by WislaCode Solutions
See the service Payment solutions developmentPayment solutions across the transaction flow - acceptance at POS, online and in wallets, PSP and acquirer integration, PCI DSS, settlement and reconciliation.
See the service
payabl., an EU-regulated merchant acquirer, had a payment SDK gap holding up merchant onboarding. We designed and shipped it inside a single sprint cycle.
View case
PushMaster is an enterprise-grade push notification server for reliable, multi-channel message delivery across web and mobile.
View case
A consumer banking super app in a regulated market had to launch at scale inside a fixed regulatory and competitive window. We owned the integration architecture and mobile delivery.
View caseBook an integration review. Bring one stuck or upcoming integration - we'll diagnose it with you and scope the work, no obligation.