While many payment processors provide their own 3rd party portal, developing our own enables us to deepen our payments integration with the management console, and give the merchant a more seamless experience end to end.

The MVP was to create a merchant portal where a customer can access payment information, manage account information, dispute/concede chargebacks, and generate statements.

The design criteria for this project was to create an experience that was able to both easily show detailed financial data as well as be visually consistent with our Material UI Library we had created.

Since we are an Agile/Scrum shop, Adam Cohen here started talking to our payment team as well as a handful of our clients to find out what they’d like to see in a merchant portal. With this, we had the Acceptance Criteria for this project.

Once we had an idea of what the end user was looking for, we started sketching out ideas on the whiteboard, which later turned into our lo-fi prototype.

We then took this prototype back out to the same stakeholders we originally started with to gather feedback. We also brought WePay’s developers to get their insight.

This was iterated multiple times internally with our product team who provided feedback. Doing this, we started to find additional opportunities for integration with our management console and overall user flow.

Once we had gone through the feedback and a few rounds of iterations on the designs, we took our lo-fi prototype and converted it into a more detailed hi-res designs, ready to be tested again.

Now with a detailed prototype to work with, we took it back on tour to get feedback.

For our devs, they now had a good idea of what were trying to build, more importantly, the functionality requirements of the various components that were going to be needed.

After a few more rounds of iterating, we didn’t have anything else to add. WePay said it was the most robust merchant portal they had seen yet.

In the end, before going to development, some designs simply weren’t feasible based on what the developers found in the API. That, or they were too much of a lift to do because they weren’t readily accessible in the design library.

Unfortunately, at this point of the project, we had to start walking that line of “designing the best product we could” with “business requirements, time and budget”.

As the devs dug deeper into the API that we’d be using, we had to make a few final adjustments based on what was going to be available to us. A few new design components had to be scrapped and instead, utilize what we had in our current Library to save time and money.

So this project is actively in development, so no new updates beyond this right now. As the projects evolve, I hope to add to this case study.