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

The sellers might not know we have other SQ products that can do what they need at a lower price. 
There is no specialized alternative to MKE for remote and instantaneous payments.

Job to be done

As a seller, help me easily take a payment over the phone in the fastest way possible.
As a seller, help me form a trusting and long-lasting relationship with my customers.
As a customer, help me easily place an order in the most secure and trustworthy way possible.

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

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)

System Usability Score: Ave. 94 (Best imaginable score)
“I think that I would like to use this system frequently.” 85%

Pros

Allow seller's customers to use stored payment methods. 
It is nice to avoid having to type in the whole credit card #, allowing the customer privacy and making customers feel that their card info is more secure. 
Convenient for both buyer and seller. It can save time by sending a payment link to the customer instead of spending time asking for card details over the phone. So you can eliminate that and ask customers to put in the credit info themselves, especially in a noisy and busy environment. 
The request is lower rates more beneficial.

Cons

The “Request payment” may not be suitable for less technical customers. The Charge is better to quickly complete instead of waiting and hoping the customer does it themselves. 
The “Request payment” could take more time to complete payment. It would be faster to directly enter the card number. Sellers may prefer manually entering the card number to complete payment faster.

Insights

Improved Phone-Based Payment Process  
Making remote payment process easier benefits sellers and buyers, particularly in busy environments where they need to listen to credit card details. It would reduce errors, enhance efficiency, and improve customer experience. 
Buyer Convenience 
The "Request payment" feature would handle different payment scenarios, including manual charges and customer-initiated payments. Saving payment information on the buyer's phone would help save time and simplify the checkout process. 
Enhanced Privacy  
Customers would appreciate the added privacy and security of not having to repeatedly input their credit card information. This can help build trust and improve the perception of sellers' business.

Suggestions

Auto-Suggestion for Recurring Customers Offer auto-suggestions for recurring customer numbers to simplify selecting payment recipients. 
Symbolic Icons Enhance the user interface with symbols next to specific words to indicate actions (e.g., "charge$", "Request envelope," or an arrow to signify sending a payment link), making the feature more intuitive. 
Bulk Payment Requests Allow payment requests to multiple phone numbers at once. It would improve efficiency for sellers dealing with multiple customers at once. 
Custom Message Allow sellers to include custom messages along with payment requests, enhancing personalization and communication. 
Preview of what the buyer's checkout page To feel completely comfortable with adopting the "Request payment," the sellers want to clearly understand the buyer's experience during checkout. What that experience looked like before they would feel comfortable, adopting the system.

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

Page updated

Google Sites

Report abuse