Remote Payment Experiment

As a seller, help me easily take a payment over the phone in the fastest way possible and ensure my customers' credit card information is safe.

July 2023 - September 2023

Synchronous remote payment experiment

How might we streamline the Manual Card Entry (MKE) process to reduce costs for sellers and make it more accessible for simple transactions, especially over the phone?

Overview

In response to declining engagement among Manual Card Entry (MKE) users, a crucial payment method, I conducted a comprehensive audit to identify pain points in both seller and buyer experiences. Beyond the seller-facing interface, issues were discovered in the buyer's payment phase. Proposing a range of solutions, I engaged stakeholders from Cross-functional teams, addressing concerns and refining solutions through iterative design concept validation. Usability testing with 20 SPOS users yielded overwhelmingly positive feedback, with over 96% satisfaction. Actively seeking and incorporating user suggestions, this project not only addressed current challenges but also laid the groundwork for future project phases.

Why?

MKE(Manual Card Entry) represents a significant portion (~35%) of Terminal Gross Profit (GP), but its growth and GP mix have consistently decreased, reaching negative YoY(Year over Year) growth for the first time in Q4 2022. The MKE growth slowdown is not limited to Register Terminal, but a Square-wide issue. The main driver is the slowdown of active merchants processing MKE while MKE volume per seller stayed constant.

Target users

Manual Card Entry power users who take credit card information over the phone and manually enter it into their app. 

Seller Pain Points

[MKE]

The seller prefers accepting payments over the phone but is not happy with the higher processing fees charged by Square when done through MKE.

The seller finds over-the-phone payments to be time-consuming to hear and enter long card numbers.

[Payment link]

The seller has to manually type in phone numbers, even for loyal customers with profiles.

The seller currently has to check his email or refresh the transactions page to see if a customer has paid for their order. He wishes this information was more readily available. He finds that customers often take long to pay through payment links. 

Customer Pain Points

[MKE]

Customers finds giving their card information over the phone to be time consuming and untrustworthy.

[Payment link]
Customers find online checkout to be just as time consuming. They have to parse through a long checkout page when all they want to do is pay. 

Goals

Test more streamlined UX experience for Payment Links to simulate a more synchronous transaction for remote sellers.

Provide a faster and more effortless “1 to 1” payment experience rather than its current “1 to many” oriented payment experience.


Business Success Metrics

% of MKE Seller Churn decreases

% of MKE Volume per Seller

% of MKE Sellers adopting other payment methods

# of MKE sellers adopting Payment Link V2 (Remote Payment)

Problem statement

Job to be done

Design Explorations

seller experience

To enhance the synchronous remote payment experience, promote the payment link for MKE. This would help streamline the remote payment process, making it more efficient and user-friendly.

Proposed concept

“Charge” or “Request payment”

Proposed "Home" screen

Proposed "Waiting/Processing" screen

buyer experience

Simplify the checkout process.

Proposed concept

Highlight the "Express Checkout" option and simplify the checkout requirements to speed up the transaction completed.

Buyer "Checkout" design audit

Proposed "Buyer Checkout" screen

Design Concept testing

Text Prototype

Test Prototype

Test intro

We will test the payment usability of "Request payment (FKA, Payment link)" as an alternative remote payment method. This will help to determine if it is helpful for sellers who accept payment over the phone.

Scenario

A customer has requested your service over the phone, and you need to charge them a service fee. You have two options: Manually enter their card details into your phone or send them a payment request via text message, allowing them to pay using their mobile wallets, such as Apple Pay or Google Pay, on their phone. For this test, you will choose the latter option of sending a payment request to the customer.

Task

Describe how you might benefit from using this. What will it help you do?

Could you tell us if the term "Request payment" is clear to you?

If not, what alternative phrase would you suggest for this function?

How would you improve this payment request if you could customize it?

Usability test (10 item questionnaire).

Results (20 testers)

Pros

Cons

Insights

Suggestions

6. Delivery Confirmation
Sellers wanted to confirm if customers received and viewed payment requests for transparency and certainty.


7. Payment Request via Email
Consider adding the option to request payment via email in addition to phone numbers, offering users more flexibility in their communication methods.


8. Wording change 
There needs to be more clarity. Suggest rephrasing the action as "send payment request" for clarity and user-friendliness. Also, Clearly communicate whether the customer or the merchant bears the transaction fee to avoid confusion and provide transparency.


9. International Invoices
Clarify the distinction between sending an invoice and sending a payment request, especially concerning international transactions.

10. In-Depth Invoice Option 
Provide a more comprehensive invoice feature, allowing users to specify payment terms details and include various relevant information, catering to businesses with specific invoicing needs.

considerations for the next version