In-depth look into handling declined payments
I really wanted to go in-depth in regards to how I designed this interface, discuss the problem, the constraints and challenges in the design. It was a solution to a problem I really wanted to solve: if a card gets declined, make it clear to users what happen and inform them what to do next, that may involve resolving something with their bank and leading them to customer support. We also wanted to help them complete a purchase. In the same view we show other cards on file and if they don’t have one, we use Apple Pay or let them add a new card, whatever method leads to the fastest checkout. Having an incredible interest in the world of payments, the constraints and barrier lead to very interesting research and a solution that I’m proud of.
The problem I witnessed and one that lead me to design this interface was the amount of frustration errors produce for people. In our case, a typical error will not be Amazon Web Services experiencing an outage or Stripe having problems but people’s cards getting declined. What happens typically is an alert view is presented with very vague language leading to confusion and frustration. It also fails in two very important areas: avoiding confusion and people failing to buy the product they were intending in buying. Not only does this fail people because they are often confused but it also fails the business because the interface didn’t adapt to possibly ask users to try another card or communicate in a clear way what happen and suggest what they should do next.
The Constraints and Barriers
Before I started designing the interface that would lead people to the solution it was critical to understand the constraints that the banking industry impose on 3rd parties. Typically when a credit card is declined, it’s declined for three reasons: fraudulent concerns, late payments or loans on default and expired cards. Fraudulent concerns is mainly the one at fault for payments getting declined. What banks traditionally do is ask customers questions in regard to their recent activity to clear any potential fraudulent concerns. This was the biggest constraint for us. There isn’t an API that could help the bank verify people’s identity and there is also hundreds of banks, just in the U.S. The one and only pathway to a solution is to ask people to call their bank. I felt asking people to call their bank was still a problem. People don’t know their bank’s number and they would have to reach for their wallet to find it. We wanted to present a phone number to their bank below the card and allow them to call. However, the challenge was how to retrieve the number. We didn’t want to ask for the phone number when people add their cards, it’s another thing to ask for and appears unnecessary. The way we retrieve the phone numbers is by understanding what the numbers on a credit card mean. There is a standard and it’s issued by the ISO, in specific the ISO/IEC 7812. This standard teaches us what these numbers on a credit card mean. The first six numbers to any payment card is the Issuer Identification Number. The first number to any credit card is the card type. If you have an Amex it’s three, Visa is four, MasterCard is five and Discover is six. The easiest cards to identify are Amex and Discover because they're both the bank and the network. However, Visa and MasterCard are only the network. To retrieve a phone number we need the additional five numbers in the card and that is the bank number. These numbers are not unique but there are services like Bindb who specialize in fraud prevention and they have databases of all bank numbers and in addition, return information like phone number, URL, bank address, etc. These services are typically used to identify pre-paid cards and in our case, it helped us retrieve a phone number and lead people to a solution instead of confusion.
The Solution and Process
Our goal from the beginning was to solve the two biggest issues I saw with alert views, in specific when related to payments: avoid confusion and create a pathway to a solution. When a card is declined, we show an interface stating the issue and proceed to inform the user what happen and what they should do next. We highlight the card that has been declined, below the card is the phone number to their bank and we also allow people to select another card, if they have one. If they don’t have another card, they can pick Apple Pay or add a new card. The interface will adapt for the fastest way to a completed transaction.
Creating a pathway to a solution
Part of our goal in this interface was to not only better inform the user of what happen but also lead them to the solution. The solution is for them to call their bank. If the user has five or ten minutes, they’re likely to call their bank. Unfortunately, due to constraints this is the only solution. It’s not an exciting or new solution but it’s the only way to remove fraudulent flags from accounts. Choice is important though, we also allow people to select another card or use Apple Pay, if they wish.
Let people complete their transaction
We wanted to lead people to the solution and help solve their problem but we are also aware not everybody has the time and specially in the morning. They have the option to select another card on file and continue their transaction. If they don’t have other cards, Apple Pay will be the following option. If the device is below an iPhone 6, we will default to letting users add a new card. The interface adapts for the fastest way to complete a transaction.
To conclude, designing this interface has been an incredible learning experience. Prototyping played a huge role in how this specific interface turned out. I was able to iterate quite fast and test various hypothesis. Having been incredibly interested in the world of payments only made this discovery a fun and interesting challenge.