Payment History


The Goal

Payment History is the most visited section of Groupon’s Merchant Center. It houses the entire payment relationship between Groupon and Merchants. The system has not been updated since Groupon’s early days as a deal-a-day company. Payment questions—everything ranging from when a Merchant might be able to expect their next payment, to explanations of payment terms—accounted for more than 50% of Account Manager’s call volume. A total restructuring of the payment system was necessary to create a holistic system that transparently communicated a Merchant's entire financial relationship with Groupon.


The Problem

The original payments system relied on a single invoice view that is generated bi-weekly when a payment transfer is triggered. Groupon’s rapid growth had created a fragmented financial system with no centralized viewing capabilities. Groupon had outgrown their deal-centric structure and the original invoice view had proven unable to adequately communicate credits, refunds, and payment transfer information.

The need to deduct money had become a transactional necessity. Furthermore, Groupon used two different processing systems to pay Merchants and that disorganization was apparent through the way financial information was being displayed. From a communication standpoint Merchant Center had been centered around Merchant’s historical relationship with Groupon rather than organizing data by deal type. 


Invoice History: Before



Success of the redesign would be determined by multiple criterions.

  1. A decrease in merchant questions coming into Account Managers
  2. Improved performance rates
  3. Providing a foundation for bringing all financial information into one section when we are able to redesign Merchant Center from the ground up.

The Audience

All Groupon Merchants—International, US, Getaways, and Goods—would benefit from this redesign as Payments are the one feature of Groupon’s Merchant Center available cross product. 

From a user perspective we think about Merchants’ interest in payment information in two highly generalized categories: 

  1. High need for cognition: those who account for every voucher paid to them by Groupon and are tracking the success of their deal versus past deals, or different option types against each other
  2. Low need for cognition: Merchants who trust that the numbers will “work out in the end” and rely on their account or tax preparer to reconcile their sales. Generally are not worried about anything beyond when to expect their next payment and how much it will be.

The team

This project was a truly global endeavor! The team included members from product, operations, financial engineering, account management spread across three different offices. I led design on Invoice History across all Merchant platforms. The core team working on the redesign was made up of one Product Manager from the Berlin office, 1 Product Operations Manager focused on North America from the Chicago office, another Product Operations Manager focused on International markets based out of Berlin, and myself who was located in Palo Alto. Members of impacted teams and financial engineering were brought in as the project progressed.



The backend financial engineering was an initial constraint as there were no resources allocated toward changes to what data was available for display. Therefore, the first phase of this in mid-2014 was a visual refresh of the current section. 

The visual refresh was ultimately found unsatisfactory as it didn’t solve some of the biggest problems.

The resources were eventually available to entirely rebuild the backend that would ultimately deliver the data into the final solution so the team could be more ambitious and holistic in the proposed revisions. 

Also, Groupon uses upwards of eight different payment structures globally and the solution needed to work with the different requirements of each deal term.


Design Process

After significant brainstorming the small team settled on a system that transitioned the organization from invoices to statements. Financial information was realigned around the idea of payment activity rather than specific payment transfers. The statement view summarizes all payment activity into a single bi-monthly view. The activity displayed is the jumping off point for more detailed payment information at the deal level. This detailed payment information would include data such as the breakdown by option type, market, or price point. 

  • This would allow credits and refunds to be contextualized, and allow the introduction of a negative statement balance.
  • We were able to accommodate both high and low cognition user groups. Low cognition Merchants can view the Statement page and receive high level payment data. While those interested in more detailed information can go deeper in the Earnings and view breakdowns at the deal and option levels.
  • This allowed the opportunity to surface more information to Merchants about their individual deals and provide context for more actionable data
  • This opened the door to centralizing all our financial information into one view. Currently payments are made through two different systems which do not currently speak to each other. The plan in to funnel the information into the same list view so we are not airing our dirty laundry to merchants.

After this idea was proposed we took paper prototypes to a few merchants to review the concept. Feedback was very positive and the statement idea was easily understood. We felt confident moving forward and proposing the major alteration to the financial engineering team and account managers.

When we had high fidelity mockups we began meeting with teams dependent on the payment interface. We spent weeks making sure the proposed direction had taken into account all the necessary requirements that might not have been captured in our earlier audits. At the same time we were showing it to North American and European Account Managers to begin onboarding them to the transition. 


Video chronicling the evolution of the Statement History system. I put this together to meet with Product teams to make sure we were meeting the needs of everyone whose product or feature shared Invoice History as a touchpoint.


Renovation of the payment section was developed in phases. We were able to reskin the existing invoice view to the new direction while backend work was happening on the financial data. As backend work wraps up we are testing the entire system with a group of beta merchants to work out the bugs prior to a larger release in mid-June.



Looking back on the timeline of this project, it was easy to succumb to internal thinking that this wasn’t a high priority because it doesn’t generate business. I think we could have done more research upfront and gotten more Merchant testimonials that proved the value of fixing the biggest touchpoint of the Groupon-Merchant relationship. The hacked together nature of the payment information wasn’t completely evident from the outside and that lack of understanding was initially confused as apathy.