Bitcoin in your pocket, one tap at any shop, and what we solved to get there

Crypto wallet app development turns hard where the app meets the phone, the moving price and the licence a card needs in every country. Oobit's 5 years with our team show the plan that gets a payment app built natively through all three, module by module, and why the code should be yours at the end.

the short version:

• 1 goal, 3 objectives: in 2021 Oobit wanted crypto holders to pay at any Visa terminal with one tap, in every market it could open, with payment volume that grows; no app existed.

• 4 challenges to solve: the tap works at a real terminal, the shop gets what the receipt says, a new market doesn't mean a new app, customers trust it.

• Solutions per problem: native code for the chip, a rate lock for the price, a licensed partner, a financial institution that holds the licence, per market, identity first and keys split between holders.

• What it delivered: $700K in January 2026, 13 times September's volume, failed payments down from about 45% to about 25%, and native modules, self-contained parts of the app, that went into Oobit's own app as widgets in early February 2026, with their code.

From 2021 to April 2026 our dedicated iOS, Android and QA team, with a project manager, built Oobit's app natively in Swift and Kotlin, 12 modules and 15+ integrations, and handed the code over with no vendor lock-in, that is, nothing that needs us to run it.

2021: what Oobit wanted, and what didn't exist yet

In 2021 Crypto.com and Binance were scaling their own crypto cards, while a person holding Bitcoin or a stablecoin, a coin pegged to the dollar, still couldn't pay for groceries with it. The only path ran through an exchange and a bank, slow and costly at every step. Oobit wanted it to feel like having Bitcoin in your pocket: take the phone out, tap, done.

Oobit, an Israel-based fintech, set 3 objectives: a card that pays at any Visa or Mastercard terminal with one tap, every market it could open, and payment volume that grows. The card would earn in OOB, the Oobit token: up to 10% cashback, points on every tap with a multiplier from 1X to 5X, and small leftover balances swept into OOB in one action. The shop would be paid in money, never in crypto.

What existed was the goal, a product owner who'd decide every feature, and a backend in PHP, the server side that holds accounts. No mature native app for offline crypto payments, paying with crypto at a real shop terminal, existed anywhere, so the app was built from scratch while payment rails for crypto were still being tested.

The plan: 4 criteria, in the order we held them

We came in through a referral in Oobit's Israeli network and signed within 2 weeks: 1 iOS engineer, 1 Android engineer, a QA specialist and a project manager.

Read against the 3 objectives, the build followed 4 criteria, in this order, for 5 years:

1. A payment works at a real terminal, through the phone's own hardware.

2. The shop receives exactly what the receipt says, though the price moves.

3. A new market doesn't mean a new app.

4. Customers trust it with their money and their identity.

A rate lock is worth nothing if the tap fails. A new market is worth nothing if payments don't clear there. Trust is worth nothing if the market can't be opened. You aren't just ranking criteria; you're choosing which failure you can't afford first.

Problem one: a tap that works at any terminal

Native first: Swift and Kotlin was the better option in 2021

It all came down to language. A mobile wallet has to talk to three separate layers of a phone: the NFC radio that chats with the checkout terminal, the secure hardware vault holding the digital keys, and the phone’s built-in wallet app.

Back in 2021, if you wanted these parts to talk to each other properly, you went native. For Android, that meant Kotlin; for iPhone, Swift.

Cross-platform tools promised an easier path with one codebase, but they forced every command across a digital bridge that slowed down when calls piled up. In the real world, a tap that hangs at the terminal fails, leaves a line of impatient people behind you and loses the customer.

Choosing native wasn’t a tech debate; it was making sure the app worked when a user was at the counter.

Oobit chose native. They skipped the easy route of buying a pre-made, white-label app because their custom cashback engine and shifting partnerships needed total freedom.

We backed them on that.

Oobit chose a modular cut instead of one giant codebase, and we built the app as clean, independent modules, each with its own screens, logic and tests. When it launched in 2021, it didn’t just work; it became a true pioneer, proving you could tap to pay with crypto at any regular store down the street.

Every module exists to make one moment work:

1. The customer proves who they are once: a document scan and a selfie.

2. A virtual Visa appears in Apple Pay or Google Wallet in under 20 seconds.

3. They choose what pays: the balance inside Oobit or a wallet they own, ranking assets if they hold several.

4. They double-click, pass Face ID and hold the phone near the reader; the price is fixed in that instant.

5. The shop is paid in its own currency at that price, and the same amount leaves the balance.

6. Points accrue, and the multiplier climbs from 1X to 5X with use.

Problem two: a price that moves while you pay

The second criterion is the price: a coin's price moves 3 or 4 times a minute while the payment runs. Without a fix, the shop's receipt and the customer's balance would disagree.

Our answer was a converter with a rate lock: the moment the customer holds the phone near the reader, one price is fixed, the shop receives exactly what the receipt says, and the balance moves by exactly that. It took about 3 months of engineering.

Problem three: every market Oobit could open

One licensed partner instead of a licence per country

The third criterion ran into the licence: each country wants its own crypto licence, a regulator's permission to hold and convert digital assets. Acquiring one per market would have put a licence process before every launch.

Oobit chose a licensed financial-institution partner that already holds the licences. Our part was integrating the card issuers, Rain and Pomelo, and PIX, the instant bank-transfer rail Brazilians use, behind the same screens; feature switches and translations enabled fast rollout across new markets. When your plan says "global" on page one, you aren't just adding countries; you're deciding whether each costs a partner or a rebuild.

Rails that could fail

A coin lives on a blockchain, a shared record kept as identical copies on many computers; a payment adds an entry to a new block that carries the fingerprint of the one before, so no earlier entry can be quietly changed.

The partner rails that turn that coin into money a shop accepts were young, and any could fail on a given day. We tuned each integration for stability and watched every one through Coralogix, a monitoring service that collects logs and crash reports.

A backend we didn't own

The backend was Oobit's throughout, so every feature had to be agreed with its team as an interface, the contract between app and server. With production the only environment and that link unstable, Firebase test builds and GitHub Actions, an automated pipeline, the checks every change passes before it reaches a customer, kept each release safe.

Problem four: trust before volume

Identity first, keys split between holders

The foundation is trust, so identity is verified before a single dollar moves. We built the identity check into the app with Sumsub's SDK, a ready verification kit: it checks the document scan and a selfie together and screens the name against global sanctions lists.

Money kept inside the app sits with Fireblocks under multi-party computation (MPC). The signing key is split into pieces between holders, so no single holder can move funds alone. To test that perimeter, a third party runs a penetration test, a paid attack on the app to find holes, every quarter.

Customers can also keep their money in their own wallet. We built the wallet connection on the Reown SDK, so MetaMask, Trust Wallet and 987+ other wallets connect across 12 blockchain networks. Payments from them run on DePay, Oobit's own payment layer, which we integrated into the app: it pulls the money from the connected wallet only once the payment is approved, with no pre-funded balance.

What the plan delivered

Monthly volume grew from $54K in September 2025 to $700K in January 2026, 13 times in 4 months. Failed payments fell from about 45% to about 25% in under 90 days, and more than 70% of attempts complete. Conversion rose 10 percentage points once one purchase could draw on several assets.

Active users pay about 12 times a month each, up 80% from the early months. USDT, the dollar-pegged coin, carries more than half the volume; the UAE pays in larger tickets, above $85, and Brazil pays most often.

How we worked, for 5 years

Oobit's product owner ranked the backlog and approved every feature. Work ran in 2-week sprints with a daily scrum, a review and a retrospective, and the team grew from 4 people to 7: 2 engineers per platform, 2 QA specialists and a project manager.

Every change went through review, automated checks and a written test plan, the list of checks a tester runs before a release. When you hire a build team, you aren't just buying its hours; you're buying the discipline that decides what you can take over later.

The handover: the code, and no vendor lock-in

In 2025 Oobit decided to bring development in-house on React Native, a framework that serves both phones from one codebase. We re-integrated the app when Oobit rewrote its backend in late 2025, and in early February 2026 our native modules went into its new app as widgets, screens it shows as its own, with their code.

No vendor lock-in is a property of the code, not an event at the end: self-contained modules handed over whole, with nothing rebuilt. When you sign with a build partner, you aren't just buying code; you're deciding whether you can take it over.

Frequently asked questions

What did Oobit get at the end of the engagement?

The code of every native module we built, running as widgets inside the React Native app Oobit's team built, in early February 2026.

Who holds the customer's money?

Money kept inside Oobit is held with Fireblocks under multi-party computation, the key split between holders, and Oobit approves transfers under its own rules. Money in a connected wallet stays there until your customer approves a payment.

What were the hardest parts, and how were they answered?

• A moving price → a rate lock that fixes one price at the tap.

• A licence per country → a licensed partner that holds the licences, with the card issuers integrated behind the same screens.

• Young partner rails → tuning and live monitoring on our side.

• A backend we didn't own → every feature agreed with Oobit's team, test builds and an automated pipeline.