Getting invoices paid faster

Plumbers, caterers, massage therapists, fitness studios and home inspectors have all ditched paper invoices in favour of getting paid faster with online credit card payments via Square.


While many know Square for the little white card reader used by sellers at markets or the register in coffee shops, there are many other sellers who don’t have physical storefronts and need to take payments remotely. As a result, Square Invoices was introduced 4 years ago.

With little marketing to-date, adoption has grown organically through existing Square sellers and referrals. These sellers have seen the value in an invoicing system that is integrated with the rest of Square, and are willing to live without some of the features that are available in other invoicing systems.

As a result, the challenge for the team was to make the product more remarkable for existing users before focusing on new user growth.

Role & Process

As a team of 2 designers (within the larger Square design team), we individually led the design on different projects. But sitting next to each other, and our product manager, data scientist and engineers on the team, led to a very open and collaborative process.

I was a very strong advocate for integrating more user research throughout all stages of the design process, resulting in:

  • A design requirements document (‘DRD’) that would be created before a project kick-off and shared with the team alongside the existing product requirements doc. The DRD gathered and grouped user research from all available sources (surveys, support tickets, community forum & social media posts, sales and ongoing phone interviews) and framed the core issues/needs within the overarching jobs-to-be-done for the product. This document helped to bring the team (product, engineering, marketing, data science, support) onto the same page, empathize with our users and align on priorities from a user experience perspective.
  • An in-person and remote usability testing practise with sellers that helped us test designs and prototypes more frequently and consistently and allowed the whole team to be involved.


While there were a seemingly endless number of features we could have built, we spent a lot of time really listening to sellers to prioritize which features would help them:

1. Get paid faster, so that they can better manage their cashflow.
2. Manage their invoices efficiently, so that they can spend less time on invoicing and more time on building their business.
3. Look professional, so that customers have trust in the seller delivering their product or service as promised.

Below you’ll find an overview of some of the projects designed to help fulfill the jobs above for our sellers. I would love to chat about the full process for each project with you, so please don’t hesitate to get in touch.


Invoice Timeline


Imagine that you sent an invoice to a client for a photoshoot you did last week. A few days have passed, including the due date, and it still hasn’t been paid. You’re thinking about following up, but you’re not sure if they’ve seen it yet and you don’t want to look too pushy.

For those without a physical storefront to represent them, looking professional is crucial when building trust and communicating with customers. Without more visiblity into the status of an invoice, sellers don’t have all the information they needed to communicate professionally with their customers. This desire for transparency and visibility was a common theme in our NPS surveys.

We opted for a timeline view to answer questions like ‘When did my customer last view this invoice?’ or ‘When was the last time I sent my customer a reminder?’ to help the seller manage their communication.

Before: the seller could only view the current status of the invoice.

After: the seller can view all activity related to the invoice in the order it took place. Here, for example, you can see that the customer didn't view the invoice until after the due date, and so the seller can take action as they see fit.

The Many States of an Invoice

The invoice timeline shows sellers the status and important actions that have taken place—when it was viewed, sent, updated—so that they have the information they need when communicating with their customer.

The designs needed to relect the multitude of states that an invoice can be in (unpaid, overdue, paid, refunded, failed, cancelled, etc.) and actions that can be taken in each state (for example, a reminder call-to-action is only shown when the invoice has not been paid).

The invoice in an unpaid state

The invoice in a paid state

The invoice in an overdue state

Once there are 3+ activities, the most recent (and relevant) activities remain visible, while past activity is still accessible.

Design Validation

After many iterations, we started a round of user testing to see how sellers would interpret the events in the timeline and how they would act on that information, and to see if there was any information that was missing that sellers would find useful.

The user testing validated many of the decisions we made around what information to present and informed some visual tweaks to the timeline as well. When seeing when the invoice has been viewed, for example, one merchant noted: ‘The viewed dates, that helps me know where they are at. If they just saw it, I’ll give them a couple more days’. Over time, we heard many times in interviews and online about how useful it is to see when the invoice was viewed:

Automatic Reminders


Unpaid invoices are the bane of many sellers’ existence. Reminding a customer to pay an invoice can be a very delicate dance. Sellers don’t want to come off as pushy, but they also need to be paid on-time to run their business as efficiently and stress-free as possible.

The team introduced a ‘Send Reminder’ feature that sellers could use to resend the invoice manually, one-at-a-time. This worked well generally, but was time-consuming and something many sellers would just forget to do. We found that sellers who used invoice reminders were 5% more likely to get paid—a number we hoped to increase by automating the process.

When enabled, sellers can leave the defaults or set custom dates and messages. In a future iteration, sellers will be able to set it on by default so that they don't need to set up the reminders every time.

Sellers can choose any number of days before, on or after the due date and can choose to include a custom message.

Setting Smart Defaults

When deciding which reminder defaults to provide to sellers, we looked to the current usage of manual reminders. We found that reminders were sent most frequently 1 day after the due date, followed by 2 days after. We also saw that sellers typically sent 1.4 reminders per invoices. We decided to set the default number of reminders to 2, set at 1 and 3 days after the due date (we thought 1 and 2 days after might seem a bit irritating).

Reminders enabled on mobile.

Custom date and message.

The timeline shows when the next reminder is scheduled to prevent over-communication.

The customer's view of the email reminder with custom message from the seller.

Design Validation and in-person usability testing validated that sellers understood what the feature would do, how to enable it and edit the defaults.

Surveys and phone calls with sellers also validated some of our design and product assumptions. For example, we decided to limit the number of reminders to 5 and found that over 50% of survey respondents would send 1 or 2 reminders and 0% would send more than 5.

Almost 75% of survey respondents said they would set the same reminders for every invoice—this validated our hypothesis that a global setting would save sellers time by not having to set up reminders every time. A settings page for this and other defaults was in development, but unfortunately wasn’t available at launch.

Redesigning Recurring Invoices


Square sellers use recurring invoices to send invoices on a repeat schedule—imagine a martial arts school offering a monthly membership or a wine shop offering a bi-monthly wine club.

When I joined, a year and a half after the feature was initially released, we decided to redesign parts of the feature for a number of reasons:

  • Low adoption: We weren’t seeing the adoption numbers we’d hoped for—10% of sellers exhibited recurring behavior but weren’t using the recurring invoices functionality.
  • Usability issues: There were a number of usability issues that frustrated sellers, costing them time and money (for example, when a customer chose to save a card on file with the seller, the card wasn’t applied for future recurring invoices—this confused many sellers, as they thought it would be an automatic process).
  • Discoverability issues: We saw many support issues along the lines of “Do you guys have a way I can set up automatic monthly payments with my clients?”. Sellers were asking for functionality we already had but either couldn’t find it or didn’t think of what they were trying to do as a recurring invoice.

Previously, the forms to create an invoice and a recurring invoice were separate. We decided to combine the form under a 'Frequency' option in order to improve discoverability of the feature and to bring feature parity between the forms.

We added search, filters, stats and toast confirmations to help sellers find, manage and navigate their recurring invoices more easily.

Prioritizing for Impact

To determine what would have the greatest impact on helping sellers manage their invoices more efficiently, get paid faster and look more professional in their communication, I looked at:

  • Support issues to find and track the most common and painful issues.
  • In-product feedback to learn about the experience of current sellers and what’s top of mind for them.
  • Phone calls with existing sellers to learn more about their specific use cases and to validate open questions we had from the support issues and feedback.
  • to test the discoverability of recurring invoices with non-Square users.

Previously, recurring invoices could only be created and managed on the web. To increase adoption, we introduced recurring invoices on mobile.

Recurring options on mobile

Simplifying the process for allowing customers to save a card on file for automatic payments.

Additional stats and timeline events for a recurring invoices.

Design Validation

After many iterations and rounds of user testing and phone calls to validate that we were making the right changes, we launched in a Beta period to gather more feedback from sellers.

Post-launch, I followed up on the phone with many of the sellers that had provided initial feedback, and we also launched a feedback widget for sellers to provide feedback in-product.

We knew there was still some missing functionality that we weren’t able to prioritize at this point, but through constant validation during the process and via multiple channels, we were confident in the changes and the impact they would have for these sellers:

"I love the new system! Makes keeping up with my customers recurring invoices or automatic charging a breeze!!"
"Good changes! I like being able to allow automatic payments in one click instead of having to save their card and then edit the invoice. Also, I'm glad Square doesn't send an email every time you update a recurring invoice."
"Very pleased with the updates. It seems to run much faster and the option to search recurring invoices is also great. Your company is kick ass."

File Attachments


Square sellers use file attachments to provide their buyer with all the information they need in order to make a payment and close the sale.

Previously, sellers would need to separately email the file to their customer, creating more work for the seller and providing a less professional experience.

While a seemingly pretty simple feature on the surface, there were a number of things to take into account: from the type and quantity of files allowed, to how long files should be stored, to how the files would be represented in an invoice preview, the invoice email and the invoice payment page.

Adding a photo attachment on mobile.

Option to rename attachment, helping the seller to look more professional.

Uploaded attachment on the invoice form.

Customer's view of the attachment while paying the invoice.

Professional File Names

On mobile, I wanted to ensure that sellers would still look professional—right down to the naming of their files. While it is easy to rename a file on a desktop computer, it’s not so easy to do on a phone. We provided sellers with a generic name of Invoice-Attachment-#, rather than the default IMG_####, and sellers had the option to rename it completely before adding it if they have the time.

Adding a file attachment on desktop.

Uploaded attachments on the invoice form.

Customer's view of the attachment while paying the invoice.

Design Validation

Usability testing via UserTesting and with existing sellers showed that they had no problems finding the functionality on desktop and mobile, selecting files, renaming them, uploading them, and verifying that they were uploaded. Some confusion arose around how the uploaded file was presented to the customer in initial iterations, so this gave us time to iterate.

Upon release, the feature gained a healthy adoption and we continued to monitor things like the average number of files being uploaded and most common file types being uploaded to make sure the limits we initially set continued to serve our sellers well.

"It's important to have a better reference available when reviewing past transactions and this helps provide additional details to the customer in one format and location."
"Found it perfect for sending the signed contract along with the invoice to our clients. It takes a step out of our process and saves us time."
"Easy to do and allows my customers to review the detailed documents we produce."