Dinner with a friend
You pay the whole bill, then request your friend’s half.
← Back to selected work
Banking · Payments
Request to Pay.
Making it easier to ask for money back, and clear what happens when someone asks you to pay.
- Company
- Capitec Bank
- Project kickoff
- February 2024
- Design tools
- Figma
The context
A new way to ask for payment.
Request to Pay kicked off in February 2024, with a deadline set across the South African banking industry. It runs on PayShap rails. My part was designing the Capitec app experience.
Think “please pay me”, but through your banking app. The person receiving the request decides whether to pay or decline. If they approve it, the money moves in real time.
People and needs
For the everyday “I’ll pay you back”.
This was for you and me. Dinner with a friend, tickets for the group, or the office coffee run. The everyday “I’ll pay you back later”.
Movie night
Daniel buys discounted tickets for the group, then requests each friend’s share.
The office coffee run
Janice buys a coffee for Mark while he is stuck in meetings. He can pay her back when he has a moment.
My job was to make those moments easy, without any confusion about whether you were asking for money or agreeing to pay.
App MVP scope
Two sides of the same request.
- Send a request
- Capitec clients request payment using the payer’s cellphone-based ShapID, including requests to other Capitec clients and clients at other banks.
- Receive a request
- Clients are notified in the app and can review, accept or reject a request sent to their cellphone-based ShapID.
- Manage requests
- View sent and received requests, their status, details, categorisation and expiry, with notifications and expiry reminders.
- Industry scope versus app focus
- The wider initiative included business-to-retail requests too. Using an account number and bank was planned for a later phase. My focus here is the app.
The challenge
An unfamiliar interaction, with real money at stake.
There were very few local examples to learn from. I looked at international apps, including Tikkie in the Netherlands, then worked out what would make sense for our clients and banking requirements.
Behind the scenes, there was a lot to untangle. On screen, people needed four things: who is asking, how much, when it expires and what happens if they agree.
Research and process
The questions before the screens.
Before drawing screens, I mapped both sides of the request and worked through the questions with the team. Who can receive one? What happens if details are wrong? What does each person need to know?
- Who am I dealing with?
- What identity details would help someone recognise the requester before agreeing to pay?
- Reference or personal note?
- The bank reference and the personal note did different jobs. The project allowed 35 characters for the reference and 145 for the note, so the interface needed to explain both.
- Can I change the amount?
- The answer we worked with was that someone could pay the requested amount or more, but not less. Partial payment was still an open question in the early flow.
- What if it never arrives?
- Wrong cellphone or proxy details could stop a request reaching someone. I needed to account for that failure and the manual follow-up, rather than leave people wondering where it went.
A design decision
Know who you’re paying.
A familiar nickname might be enough in a conversation with a friend. In a banking app, I needed to give people more to go on before they agreed to pay.
My research established that registered identity details mattered alongside the bank and recipient information. I carried that into the request and review screens, giving people the details they needed to check who they were dealing with before confirming.
The aim was to make that decision clearer, especially when a name looked unfamiliar, and give people a chance to check the details before money moved.
Design considerations
Clarity beyond the happy flow.
Control and recovery
Review details before sending, correct mistakes, understand rejection or cancellation, and distinguish an expired request from a paid one.
Progress and visibility
Make sent and received requests easy to find, identify important notifications and communicate what happens next.
Trust and boundaries
I also worked through unfamiliar requesters, reporting, reminders and bank differences. These were design considerations. Not every option shown in the early work was confirmed for delivery.
Early journey mapping
Sending and receiving need different decisions.
Sending a request meant more than entering an amount. I worked through recipient checks, confirmation and tracking, as well as reminders, duplicates and cancellation.
Receiving one needed its own flow: notification, review, payment, decline and reporting. Scheduling, partial payment and reopening were early questions, not confirmed features.
Explore sender and receiver maps ↗My contribution
Turning requirements into an app journey.
I was the sole designer on Request to Pay, working closely with Riefad Davids, the payments product manager at the time. He made sure I had the information I needed, and we built a strong working relationship as we worked through the project.
I owned the UX flow and app screens for sending and responding to requests, including the decisions, statuses and exceptions between the happy paths.
Behind the work
From questions to app designs.
Here is the work behind the screens, from the first questions to the detailed designs. Open a collection to explore it at your own pace.
Original project artefacts may refer to me by my maiden name, René du Plooy.
Handover and outcome
From design to a live feature.
The project was handed to another designer shortly before completion. The flows and screens shown here document my design work before that handover. PayShap Request has since launched, with further changes made after my involvement.
As of October 2026, Capitec’s public product page confirms the service is available in the app. It lists a R100 limit per transaction and up to two transactions every 24 hours, with a combined value of R200. These are the live product limits, rather than the scope of my original designs.
Reflection
Proud of the work. A difficult handover.
I worked hard on this project, and I was incredibly proud of what I produced. At a team townhall, the head of app asked me to stand up and thanked me for the work. That recognition meant a lot.
The following day, the project was reassigned with my design work close to completion. Losing ownership at that point was difficult. I cared about the experience and wanted to see it through to production. The released product evolved after my handover, so this case study shows the flows, decisions and designs I owned.
It reinforced the importance of documenting the reasoning behind a design, alongside the screens themselves. A handover needs to explain why a question is asked, what an extra step costs someone, and which decisions keep the journey straightforward. Those details matter when another designer takes the work forward.