Naranja Credit Card: Partial Payments
--
How we were able to implement a new form of digital payment of the credit card statement through research and validation methods with users and the business.
Context
A large number of users made partial payments of their statements through different physical channels, but they didn’t have the possibility to do so from Naranja Online or from the app.
This number is increasing every month, so having this payment option in our digital channels would provide a solution for these users who currently do it in a physical location or from a third-party service (Rapipago, Homebanking, etc.).
My role was to plan and execute each step of the process, having full ownership in each instance that I was validating with the Payments team (stakeholders + devs) and obtaining feedback from the design team.
Nowadays, this solution is implemented in the payment flows of statements in all Naranja’s digital channels.
Objectives
- Give our users the possibility to make partial payments of their credit card statement through our digital channels.
- Identify the best payment allocation logic for our users.
- Define the best option to choose in terms of development and business costs.
What is a payment in Naranja?
When we talk about Payments, we refer to the payment of the credit card statement. Since 2017 this task can be done online through Naranja’s channels, and this tool gradually added more functionalities to match those that can be done in a physical location.
The user can pay:
- Everything (the statement’s total)
- Plan Z (it is a specific Naranja’s payment option that allows users to finance their total statement in installments)
- The minimum (it is the minimum amount that we offer our clients to pay that month)
How is a partial payment of the statement given?
In two very complex ways that are outside our digital channels:
- The logic of imputation of local payments: A person, when going to pay their statement to a physical location of Naranja talks to someone at the register, and manually this person processes a partial payment. This allows the user to choose how to finance the payment and pay a specific amount, knowing how much they have to pay to be up to date that month.
- The logic of imputation of third-party payments: When paying with third-party services (Rapipago, homebanking, etc.) if the person does not enter the exact amount of a payment plan it will be assigned to the payment plan closest to the amount entered and It will be taken as partial payment until the remaining amount is completed to reach said payment plan.
The challenge
Here arises the main challenge in which we must validate the value that each option adds to our users and business to make a decision based on metrics on what type of tool we are going to build:
Hypothesis
As a starting point, the hypothesis arises that users do not stay up to date and need to make partial payments because:
- The economic context of the country.
- Because the minimum amounts of Naranja are high.
- They pay with multiple payment sources.
- Because of how and when they receive their salaries.
- Because the payment of the card is not a priority in relation to other services.
Research
To research these hypotheses and/or generate new ones, it is necessary to understand the contexts of our users, how they pay, and what are the drivers that lead them to make partial payments.
Data collection
As a first step, we began researching the following points with our data models:
- The possibility of users with partial payments to be migrated from physical to digital channels. (validating this initiative from the business objective)
- How many paid with the local payment allocation logic (choosing the payment plan).
- How many paid with the logic of imputation of third-party payments (without necessarily choosing the payment plan).
In order to do this, we analyzed the partial payment database from December in Córdoba, Capital Federal, and Resistencia (these places were chosen considering business strategy and representativeness) to understand the possibility of users to be migrated, and how many paid with the local logic and how many with the third-party logic.
These were our findings:
- 69% of users are not paying with digital channels. This opens up a user market to be able to migrate.
- Of that percentage, 83% have a high chance of migrating to pay to a digital channel according to our data models.
On this 83%, we saw that the partial payments were made in these percentages according to each logic:
Qualitative validation: User interviews
A research plan was defined with the objective of understanding the payment profiles of our users when deciding to make a partial payment.
30 users were called (10 from each region) and the first insights showed the following:
- Some people do not know they are making a partial payment
- They pay US dollars separately from pesos and this is considered as a partial payment
- They make partial payments by mistake at the time of payment - Some people are making partial payments consciously.
- They learned it on a physical location and already know how to do it
- They learned ir from a mistake paying for Third Parties
Based on these calls, we were able to make a first qualitative validation of all the hypotheses raised, except that the card is not a priority of payments. In fact, this research showed us the opposite.
Quantitative validation: Surveys
To make the results obtained qualitatively more representative, we expanded the sample of users and conducted quantitative surveys with the aim of validating hypotheses and knowing opinions and trends of our users on:
- How they pay for their statements and why they do it that way
- By what means do they pay their consumption in dollars if they have
- Know what time of the month they pay their statement
- Validate if they understand the concept of partial payment
- Why do they make partial payments
- If they had problems making a partial payment (with or without intention to do so)
These surveys ended up validating our hypotheses and gave us the support in metrics of the best way to face the construction of this tool:
Prototype design
Having validated by the business and users the way forward, the next step was the design of the solution.
Taking into account that the payment flow of the statements is critical, I organized a workshop in which other people from the design team and some stakeholders participated in the creation of the solution together and with different approaches.
This helped us to stress the idea of flow and avoid as much as possible biases when thinking about the solution.
The positive aspect of this activity was that in one day we were able to materialize several ideas to quickly see if they were valuable.
Prototype validation
For the validation of which prototype we should build we carry out remote tests.
Objective:
Compare the prototypes to validate that all people who pay online can continue to do so without friction, and those who make partial payments understand how.
Profiles:
Users that paid the previous month ´everything´, others that paid using Plan Z, and others that made partial payments.
Method:
First Click Test with the 2 prototypes and the current flow.
For this activity, each participant according to their profile will receive a task to be completed in one of the prototypes that will be randomly assigned to them.
This way we were able to understand the behavior with this feature of those who make partial payments. This also allowed us to understand if those that don’t make partial payments notice new frictions or opportunities in this flow.
Results:
Based on the samples that the tests gave us, we were able to identify certain behaviors that served as key insights for the final design of the flow. and of course, they helped us understand which was the most optimal prototype to advance.
Conclusions:
We decided to move forward with Prototype B, which from the Enter an amount option takes the user to the Prototype C screen.
We saw that those who want to make a partial payment with this flow will find themselves in a controlled context in which we can incorporate specific messages and wordings of the partial payment.
And in addition, it didn’t generate friction in the other profiles.
Final flow:
With all this road traveled, having validated the business case and the needs of the users; to then generate a prototype and test the correct path, we diagram the necessary flows to complete the journey.
This journey has been implemented since August 2019 so that Naranja users can make partial payments digitally through Naranja Online and the Naranja App.
Today it is still in production and with positive results.
Thank you for reading!
Nico Shuga
