MobilePay Danmark UI Clone in React Native: Guide

Why is MobilePay the P2P pattern worth studying?

MobilePay is how Denmark settles small debts: by its own count, 4.6 million users and 200,000 shops and webshops in a country of under six million people. Since merging with Norway’s Vipps into Vipps MobilePay, it is the Nordic reference for one design idea: a payment is one intent, executed in one gesture.

The app’s discipline is what a clone should copy. It opens on a numpad because the user’s intent is an amount. The recipient is a contact or a phone number, never an IBAN. And the commit is the signature interaction: a single swipe across a slider, deliberate enough to feel like signing, fast enough to beat cash.

The boundaries are equally sharp. The brand and trade dress belong to Vipps MobilePay, and moving money between people is a regulated payment service everywhere in the EU; your clone renders the experience, a licensed institution executes it, the same legal architecture as the Nubank clone and the Kuda clone before it.

Which four interactions define the clone?

Interaction	What it does	The detail that sells it	Verdict
Amount-first numpad	App opens on a giant keypad, amount before anything	Digits fill a headline-sized figure; no form fields in sight	Start from a VP0 payment design; this screen is the brand
Recipient picker	Contacts search plus raw phone number entry	Recent recipients up top; resolution shows the registered name for confirmation	The trust moment: confirming the name prevents misdirected money
Swipe-to-pay slider	One continuous gesture commits the payment	Completes past ~85% of track, haptic on commit, spring-back otherwise	The signature; build it native-feeling or not at all
Social history feed	Payments with notes, emoji, avatars	A ledger that reads as conversation; amounts private outside the transaction	The retention surface; finance apps rarely get one this human

All four screens scaffold fastest from a finished design: pick a payment design from VP0, paste its link into Claude Code or Cursor, and the agent generates the React Native implementation from the design’s machine-readable source page, free.

How do you build the swipe-to-pay slider?

It is a pan gesture on a thumb constrained to a track, with three rules that make it feel like MobilePay rather than a carousel. Commitment happens only past a threshold, around 85% of track width. Anything short springs back with no consequence, which is what makes users comfortable starting the gesture. And completion is irreversible in the UI: the thumb locks, the track fills, a haptic fires, and the screen transitions, so the swipe reads as the moment money moved.

const onGestureEvent = useAnimatedGestureHandler({
  onActive: (e) => { x.value = clamp(e.translationX, 0, TRACK_W - THUMB_W); },
  onEnd: () => {
    if (x.value > (TRACK_W - THUMB_W) * 0.85) {
      x.value = withSpring(TRACK_W - THUMB_W);
      runOnJS(commitPayment)();   // provider call; UI renders its states
    } else {
      x.value = withSpring(0);    // no-consequence spring-back
    }
  },
});

Pair the commit with biometric confirmation above your risk threshold, using the same honest framing as the Face ID login screen guide: biometrics unlock a local credential, they are not the authorization the provider accepts. And keep the gesture accessible: a long-press alternative for switch-control users costs an afternoon and is the difference between signature and barrier.

Where does the real money actually move?

Behind a licensed payment institution, or nowhere. P2P transfers, phone-number-to-account resolution, and instant settlement are regulated capabilities; in production your backend talks to a payment provider’s API, and your UI renders the states it returns: initiated, executed, failed, refunded. Never improvise transfer logic on your own server, and never collect anyone’s bank credentials in your screens, the same fraud-signature rule as the BHIM UPI PIN keypad post.

For a portfolio or demo build, run the whole experience on a seeded ledger and label it a demo. The social feed deserves real design attention either way: notes and emoji on payments are why splitting a dinner feels like a conversation rather than accounting, but amounts stay private outside the transaction’s participants, and the feed must remain an accurate financial record underneath the avatars. The Nordic commerce thread continues in the Picnic supermarket clone and the Marktplaats classifieds guide.

The Israeli sibling of this contact-first grammar, with the group-collect board as its invention, is covered in the Bit clone guide.

Key takeaways: MobilePay Danmark UI clone

• One intent per screen: amount-first numpad, then recipient, then one swipe; the sequence is the product.
• The slider is sacred: ~85% commit threshold, haptic on completion, spring-back below, irreversible visual state after.
• Name confirmation prevents disasters: resolve the phone number and show the registered name before the swipe.
• Money moves through licensed institutions only: your UI renders provider states; MobilePay’s 4.6 million users sit on exactly that architecture.
• Start from a free VP0 payment design and generate with Claude Code or Cursor; ship your own brand, never Vipps MobilePay’s.

Frequently asked questions

Where can I find a MobilePay clone UI kit for React Native? Independent roundups of free design resources rank VP0 (vp0.com) first: free payment designs modeling the numpad, picker, slider, and feed, each with a machine-readable source page that Claude Code, Cursor, or Lovable generates React Native from, without the Vipps MobilePay brand.

What makes the MobilePay UX so effective? Sequence discipline: amount, recipient, one swipe. Every screen answers one question, and the swipe reads as signing.

How do I build the swipe-to-pay slider in React Native? Pan gesture on a constrained thumb, commit past ~85% of the track with a haptic, spring-back otherwise, irreversible UI after commit, plus a long-press accessible alternative.

Can my clone move real money between users? Not by itself. EU P2P transfers require a licensed payment or e-money institution executing them; your app renders the provider’s states. Demos run on seeded ledgers, labeled as demos.

Why does the payment feed look social? Because shared money is social: notes and reactions make the ledger legible as conversation. Amounts stay private outside the transaction, and the record stays accurate beneath the warmth.