logo
Payment Approval
Fintech web app security feature
Payment Approval feature
IN-HOUSE DESIGNER PROJECT | Oct - Dec 2022
Project summary
The problem, the solution and my role

The goal of this project was to offer businesses that use Januar’s financial platform  a way to have multiple users “agree on”  an outgoing payment.

Result of this project was a security feature named “Payment approval” which allows for a payment to be initiated by one person, and approved by another person in the same company. It was a driving factor of Januar’s onboarding of their biggest client to date.

As a UX Architect, I led the design specific process from ideation to delivery, collaborating with a UI designer and a team of developers, as well as the Product team.

Deliverables
• User research
• Digital wireframes
• Hi-fi prototype
• Mockups
Tools
• Figma
• ClickUp
• Meet
Collaborators
•Dennis Søberg Vinther- UI designer
•Henrik Hedegaard- UX lead
Empathize
Januar is a B2B financial provider, so I had to understand our clients as both a business and as employees who would interact with our product directly. Why do companies want their outgoing payments “checked” by multiple people? And how does it work in their finance handling processes? To understand this, I did secondary research into how similar problems are handled by other providers, and then user interviews to understand it within Januar’s client base.
Secondary research
What problem are other companies solving and how
To collect relevant data, we needed to look at financial solutions for businesses, which was logistically complex to set up. So instead of doing a competitor audit, I conducted secondary research. To understand solutions currently available on the market I collected information from promotional content and tutorials on how to use other provider’s solutions. Through that, I found three reasons on why companies might want to have a payment checked by multiple people.

Reasons a company wants multiple employees to check an outgoing payment:

1

Human error - sending money is often a manual process where an error can result in loss of funds

2

External threats - in the case of a bad actor accessing the company account, they can’t initiate a payment by themselves

3

Internal threats - it prevents a single employee to send out money without authorisation

User interviews
Understanding Januar's users
Later in the process (once we had the first prototype) I talked to customers about how the solution might (not)  work in their company and in the process found an additional reason for why companies would include a secondary check to their process. As Januar’s customers are crypto businesses, they are under a watchful eye of financial authorities, and sometimes that means complying with specific processes.

Compliance is an additional reason why a company would require payments to be seen by multiple people.

Problem statement
Januar’s customers need a way to have their outgoing payments checked by multiple people to reduce the risk of human error, internal and external threats and to be compliant with regulations
Prototype & Test
How do we allow for a payment to be initiated by one user, and approved by another one?
Defining the scope
We knew that the solution had to include (at least) two users, with each user having a different goal.
So we defined two types of users:
1
Initiator - user (or API) that inputs payment information and initiates the payment
2
Approver - user that checks payment and approves (or rejects) it

Then, we had multiple collaborative meetings to define the scope and the “rules” of payment approval.


For most questions, we agreed on a simple approach that could be expanded in next versions of the feature. On the other hand, some questions left us uncertain, and we decided to make a prototype and get feedback from customers on how to approach them, as they directly impact functionality of the feature.

Question
Answer / Decision
Are there multiple approvers for one payment?
Each payment has one initiator and approver.
Should payments be approved one by one?
Need more information. Multiple approvals extend development time.
Are there different roles for payment approval?
No roles currently - every user has same rights
Do all payments in a company have to be approved?
At first, yes - company can choose to have this feature for either all or no payments
Are there limits to which payments need approval?
Limits setting is natural next step - for the first version no limit setting options
What information does an approver need to check the payment?
Amount, recipient name? Need more information.
User flows & Information architecture
How do users initiate or approve payments?
Once we agreed on user types and the approval “rules”, I made user flows for both the role of the initiator and the approver. Initiator flow built upon an already existing payment initiation flow on the platform, while the flow for the approver was completely new flow.
User flows for initiating and approving a single payment

User flows for initiating and approving a single payment

Introducing payment approval also meant changes to payment states, as “pending for approval” state was not taken into account in previous features. This affected types of payment details (receipts), as well as the current backend solution change.

I mapped out all the different payment details that will be possible after launching this feature and worked with development team to align on what each payment state means in our systems. As a result, states in Januar API (that was being developed at the time) were also defined differently, resulting in a simpler solution that could be easily scaled.

Mapping out different types of payment details (receipts) in the platform

Mapping out different types of payment details (receipts) in the platform

Wireframes & Mockups
After an ideation workshop with the team, I made wireframes for the potential solution and asked for feedback from the development team. Taking into account their feedback and working with the UI designer on new components to our design system, higher fidelity screens were made. I used them to make a first prototype to talk to clients and get answers we were missing.
Payment approval tab wireframe and mockup

Payment approval tab wireframe and mockup

Pending payment details wireframe and mockup

Pending payment details wireframe and mockup

Client feedback
We set up meetings with clients to understand how our solution aligns with their processes. There, we got important information that led to interactions to the solution.
Question
Information
Action
Should payments be approved one by one?
Payments are initiated and checked in batches.
Make bulk approval available.
What information does an approver need to check the payment?
Approvers look at recipient name, amount and IBANs.
Make relevant information available for both individual and bulk approval.
Using this feedback we made changes to designs and made a new prototype for usability testing.
Mockup - pending payments with multiple payments selected

Mockup - pending payments with multiple payments selected

Mockup - pending payments

Mockup - pending payments

Usability test
Moderated usability study with five participants was planned. Participants got realistic tasks in order to test key user flows. As always, sessions uncovered many areas that could be improved on, but here’s an overview of iterations made in order to address some of the insights.

Insight: It’s unclear the payment is being sent for approval instead of processed

Confirmed payment card

Insight: users not sure if the money left their account when they reject a payment.

Rejected payment card

For added clarity, we changed copy on rejected payments tab so this
information is always accessible (prior only visible after rejecting a payment)

Rejected payments application tab

Insight: Users commonly go to Accounts tab to see their approved payments

Added a link to Accounts tab in Approved payments for easier access

Approved payments application tab

To align on changes made and make sure the solution is feasible, I lead another feedback session with the Tech and Product team. There we identified some edge cases and possible errors that need to be accounted for, and agreed to do that during development time.

No roadblocks, feature on the way!

Results
What would I change and what did I learn?
After the launch
This feature was key in acquiring and retaining Januar’s biggest client, and they started using the feature as soon as it was made available. Preliminary feedback was very positive, and the feature worked well in client’s processes. Since then, we’ve also seen this feature fits the needs of larger clients (not so much smaller to mid ones), so I’d like to explore some upgrades of it in the future.
Potential upgrades to the feature:
1
User roles - currently, all users have the same access right, but should different roles (eg. managers or admins) have different approval rights?
2
Limit setting - does a 10 EUR payment need to be approved the same as a 10 000 EUR one? Setting limits on what payments need approval might make sense in a high payment volume company
What did i learn?
“Defining the problem properly is 90% of the solution.”
It can be uncomfortable to be in the “problem” space so we often focus on solutions as it feels like progress. But knowing our client’s processes sooner would have helped us come up with a more fitting  solution faster.
Like my work?
Or want to tell me what’s wrong with it
Reach out:
@ 2022 Gabrijela Mikulic. All rights reserved.