Explore

Ontop Cards

Background

Ontop is a an uprising startup helping businesses to go remote by automating international hiring and payments. They’ve products assisting their clients with contracts, paperwork, compliance or cross border payments

Following is an experiment to understand what kind of products that ontop can provide to its customers to give them additional benefits like flexibility, transparency and more control on their payments. Also give additional benefits and better FX rates that these customers already enjoy. Here I’m trying to devise a minimum viable product (mvp) for the

❓ Problem Space

There are many more sorts of regular & one time payments that the employees have to do on day-to-day basis. This is pretty hard to keep track of for the finance team and also harder for employees to recuperate the money that they might have paid vendors. Thus, there is for sure a need for a product that can better facilitate the easiness of making payments while also perfectly attribute each of the payment so that recuperation of money could be done properly. Let us deep down more into problem space to understand it better

👨‍👩‍👦 User Personas

Finance Team Member

Makes payment of employees but has real problem of attribution for personal payment done by employees

Vendor facing Teams

Interact with third parties and thus have to make lot of payments from their personal accounts

🚲 Current Solution

This is to focus whether our users already have a solution for the problems we’re stating. Well to consider our product ontop only provides services for payroll completions thus there is a big section of business still misses out which is the payments made to vendor as stated in our problem statement. Now this is an assumption made via the product info available on the main website. Currently when a team member makes a payment he relays the info to his fin team counterpart while sending the proof of payment. At the end of the month the fin team consolidates all the data and then make the requires payment. As you can see that there are lot of problems that can easily come up from both the personas. Let’s look into user stories from our personas to better understand the problem

🗣️User stories

🗣️User stories

Persona

User Story

Problem Essence

Vendor facing teams

As an operation team member I often have to make payments to vendors but there is a great friction as the payment has to be centralized and passed through the finance team that probably have other payments on their plate thus, it will be great to have some the power of payments in our hand to make the whole process much faster

Payment power distribution

Vendor facing teams

As an operation team member in case I make payment from my account to vendor it is tough to recuperate my payment from finance team as it is tough to prove the attribution of a payment in my passbook to that of the company so, it will be great to have an attribution system that lets the finance team know the payments that are personal and the ones that are private

Payment attribution

Finance Team Memeber

As a finance team member we can see there is a risk in divulging the ability to pay on behalf of company to other parties thus, it will be necessary to set up payment limits for other team

Payment limits

Finance Team Memeber

As a finance team member it is very difficult to keep track of all the payments being done by individuals and have them all be copied on to our accounting software thus, it’ll be great if we could channel each of these transactions into our accounting software

Transaction API / View

There are no rows in this table

⁠

🚗 Solution Space (Ontop cards)

So here is the solution to resolve the problem - Ontop corporate cards. Let’s look at different modules that I’m proposing and better understand the solution being produced

Setup 🏗️

To setup the architecture we can partner with one of the big card issuer like Mastercard, American Express & Visa and build our payment structure over it. Most of this architecture would be to add our existing service of getting the most from FX transactions

Goals 🥅

The features/module of solution space in the task focuses as functionalities that end up solving the problems that arose in the problem space for our user personas -

Payment Power Distribution

The obvious solution here arises from the ability to add cards and issue them to respective team members to be used. This would include single point of contact for mobile number that’ll control the card i.e. receive OTPs for transactions. So here are the features to solve the problem -

Adding new cards

Issuing cards

Payment Attribution

After every payment a notification is sent to payee to either mark the transaction as personal or for company. This option to tag can also be given in the passbook to have a better control over payments being made

Payment Limits

To set up limits for each of the task. Also have the option to showcase spending of the previous few months to better understand spending patterns of a team

Transaction View / API

This is a passbook type view for the finance team member to view all the transactions done how much of the limits have been completed and money saved overall in transactions

Product Design 📱

Following are a mockup of the product screens (designed on figma) that I’ve been thinking . With each of these I’m also explaining how I’m able to solve the problems that we’ve identified above

Wallets Screen

⁠

As you can see the following is a view for the admin (fin team member) to actually see all the cards given to a particular team

Screen can be broken down into following sections -

Teams - Distinction among teams to view the cards that’ve been assigned to them

Card Type - We’ll have both virtual & physical card. Usage of each will depend on type of payment being done

Cards - Each of the card has a unique card number & cvv with name of the issuer

Add Button - To add new cards

Transaction - At the end of the screen there will be transaction list . The list is not designed here but will be very similar to

this⁠

⁠

Add Card Screen

⁠

This screen acts more as a form then anything else and appears on pressing the “+” sign on previous screen. This screen is thus unique for each of the team. Following are the info that have to be put in -

Card holder name (One of the team member)

Card Limit

Card balance (must be <= card limit)

Card Type (Virtual Cards / Physical Cards)

Remarks (for additional comments)

Add Card

After adding card a pop up comes up notifying that it will take a few days initiating the card from our side

Single Card Screen

⁠

This is a card view for a single card of a team. Let’s break down the screen now

Teams - Tapping on one of the tab will take you back to the

wallets screen⁠

of the respective team

Card image - Both front & back of cards available. Imp numbers are blurred depending on who is viewing the screen

Card Limits - These cards showcase balance, limit & amount on the card

Control Modes - These are used by fin teams to have a control on the card & its limits

Transaction history - These showcase payments done via the card with filters for sorting the list. Each transaction tile consists of following -

Vendor Name

Payment date

Payment value

Payment Tag (personal / company) - tagged while making the payment

Three dots to change an attribute of payment

Tagging Notification

⁠

This is a notification whenever a payment is made to notify our end users to tag the given payment as personal or for company based on other attributes

Dashboard Screen

⁠

This acts as a backscreen to our wallets screen. It includes-

some metrics like amount saved, in the currency chosen by our admin user, by using ontop products

list of total transactions

options to explore a detailed list of our product (one of them being our cards)

This here is a screenshot of the dashboard screen present right now on your website. My aim is to pretty much be on the same track for all 4 layers of the design architecture

Feedback Loop 🔁

Now for every problem that we end up solving there is a need to define the metrics that can act as our feebdack to the release and these will end up measuring the release and give us areas to improve at

Metrics

Metrics

Metric

Metric Change Goal

Remarks

Vendor payment time/payment

Decreases

Lifting away the routing of payments through finance department helps in reducing time

Number of repeated vendors in consecutive payment cycle / user

Increases

As the payment time improves there is a high probability of vendors continuing in giving service

Payment bounce rate

should be kept low

A basic metric for any payment product

Accounting time/financial session

Decreases

As the payments are getting tracked and being linked while the payments are being done on one system it makes easier for accounting team as they don’t need to manage multiple receipts and make sure accounting is right

There are no rows in this table

⁠

Final Notes 📄

All in all this was a fun exploration to do the reason especially being that we had 2 different personas to deal with one that was in need for service and the other that had the purchase power for that given service. I could we create an anology with a lot of Indian startups that are trying to solve the problem for teenagers who are really active on internet and are core buyers to a lot of stuff & the parents who end up paying for them. A big shoutout to volopay, I came across them and the problem they were solving during the research for this doc and it is wrong to say if they hadn’t given me some ideas. I know I could have been more in-depth with my approach but I pray that you guys would actually love this and I might end up getting a call 🙂

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.