Payment Rules
Payment Rules
Payment Rules
Enterprise clients in Argentina were drowning in hundreds of payment settings due to a legacy system that couldn’t handle overlapping promotions. At the same time, U.S. and European merchants found the tool overly complex and irrelevant to their needs. I led the redesign of VTEX’s payments settings, reframing it as a modular, platform-based system.
Role
Lead Designer
Company
VTEX
Field
Payments
Year
2022
Role
Lead Designer
Company
VTEX
Field
Payments
Year
2022
One outdated experience, two opposite audiences
At VTEX, the payments team dealt with a legacy, confusing, and unsystematic tool for setting up payment options.
Although it displayed numerous features, North American and European clients didn't need them and thought it was all too confusing. Meanwhile, in Latin America ( especially Argentina) store survival depended on multiple options for installments, discounts, and banking partnerships beeing displayed at checkout. That meant creating hundreds and even thousands of setups in our tool by hand.
One outdated experience, two opposite audiences
At VTEX, the payments team dealt with a legacy, confusing, and unsystematic tool for setting up payment options.
Although it displayed numerous features, North American and European clients didn't need them and thought it was all too confusing. Meanwhile, in Latin America ( especially Argentina) store survival depended on multiple options for installments, discounts, and banking partnerships beeing displayed at checkout. That meant creating hundreds and even thousands of setups in our tool by hand.
One outdated experience, two opposite audiences
At VTEX, the payments team dealt with a legacy, confusing, and unsystematic tool for setting up payment options.
Although it displayed numerous features, North American and European clients didn't need them and thought it was all too confusing. Meanwhile, in Latin America ( especially Argentina) store survival depended on multiple options for installments, discounts, and banking partnerships beeing displayed at checkout. That meant creating hundreds and even thousands of setups in our tool by hand.
An Elusive Challenge
Neither the account managers nor the business leaders at VTEX could clearly convey why clients were creating so many payment option cards. All Argentinian clients asked for was a feature to add products to multiple groupings when filtering payment conditions.
An Elusive Challenge
Neither the account managers nor the business leaders at VTEX could clearly convey why clients were creating so many payment option cards. All Argentinian clients asked for was a feature to add products to multiple groupings when filtering payment conditions.
An Elusive Challenge
Neither the account managers nor the business leaders at VTEX could clearly convey why clients were creating so many payment option cards. All Argentinian clients asked for was a feature to add products to multiple groupings when filtering payment conditions.
Finding the root cause
Interviews with Brazilian and Argentine clients revealed a consistent pattern:
Each installment option had to be broken down into multiple separate payment condition setups.
By not being able to use a product in a real situation, we had no visibility of the size of the problem. When two payment options overlapped at checkout — for example, a Samsung smartphone eligible for 12 installments and paying with Mastercard making it eligible for 18 — a third setup was required to cover the intersection. On top of that, every condition still had to be replicated across each payment method and card issuer, multiplying the complexity exponentially.
The result was a combinatorial explosion: hundreds of payment option setups created per store, with one particular store's case reaching 430 active setups and thousands of inactive ones.
For this one store, the operational team spent a full week each month just updating payment conditions one by one.
The system didn’t fail due to too many features, but because of an absence of systemic thinking.
Finding the root cause
Interviews with Brazilian and Argentine clients revealed a consistent pattern:
Each installment option had to be broken down into multiple separate payment condition setups.
By not being able to use a product in a real situation, we had no visibility of the size of the problem. When two payment options overlapped at checkout — for example, a Samsung smartphone eligible for 12 installments and paying with Mastercard making it eligible for 18 — a third setup was required to cover the intersection. On top of that, every condition still had to be replicated across each payment method and card issuer, multiplying the complexity exponentially.
The result was a combinatorial explosion: hundreds of payment option setups created per store, with one particular store's case reaching 430 active setups and thousands of inactive ones.
For this one store, the operational team spent a full week each month just updating payment conditions one by one.
The system didn’t fail due to too many features, but because of an absence of systemic thinking.
Finding the root cause
Interviews with Brazilian and Argentine clients revealed a consistent pattern:
Each installment option had to be broken down into multiple separate payment condition setups.
By not being able to use a product in a real situation, we had no visibility of the size of the problem. When two payment options overlapped at checkout — for example, a Samsung smartphone eligible for 12 installments and paying with Mastercard making it eligible for 18 — a third setup was required to cover the intersection. On top of that, every condition still had to be replicated across each payment method and card issuer, multiplying the complexity exponentially.
The result was a combinatorial explosion: hundreds of payment option setups created per store, with one particular store's case reaching 430 active setups and thousands of inactive ones.
For this one store, the operational team spent a full week each month just updating payment conditions one by one.
The system didn’t fail due to too many features, but because of an absence of systemic thinking.
Stacked on Problems
It was clear that features for filtering promotions based on dates, products in cart, and even credit card issuers were added one at a time, as a client request. Each patch added another layer of complexity.
Confusing naming: the term “conditions” was used in three completely different features, including the tool name.
Confusing functionality: to accept new payment methods, one would need to create empty conditions for it
Limited architecture: operators couldn't create one setup for multiple payment methods, issuers, banks, etc.
The conclusion was clear: fixing the interface wasn’t enough. The tool needed to become a modular, flexible, and evolvable platform that could account for clients' requests and innovative payment options at checkout.
Stacked on Problems
It was clear that features for filtering promotions based on dates, products in cart, and even credit card issuers were added one at a time, as a client request. Each patch added another layer of complexity.
Confusing naming: the term “conditions” was used in three completely different features, including the tool name.
Confusing functionality: to accept new payment methods, one would need to create empty conditions for it
Limited architecture: operators couldn't create one setup for multiple payment methods, issuers, banks, etc.
The conclusion was clear: fixing the interface wasn’t enough. The tool needed to become a modular, flexible, and evolvable platform that could account for clients' requests and innovative payment options at checkout.
Stacked on Problems
It was clear that features for filtering promotions based on dates, products in cart, and even credit card issuers were added one at a time, as a client request. Each patch added another layer of complexity.
Confusing naming: the term “conditions” was used in three completely different features, including the tool name.
Confusing functionality: to accept new payment methods, one would need to create empty conditions for it
Limited architecture: operators couldn't create one setup for multiple payment methods, issuers, banks, etc.
The conclusion was clear: fixing the interface wasn’t enough. The tool needed to become a modular, flexible, and evolvable platform that could account for clients' requests and innovative payment options at checkout.
Beyond the Interface: Redesigning Core Mechanics
VTEX's admin was being remade, and it posed the perfect opportunity to redesign our legacy tool as well. We proposed renaming entities for consistency and clarity:
Payment conditions → Payment rules
Payment ID → Payment methods
Installments and interest rates → Payment terms
Commercial conditions → Product groups
I separated payment methods (what USA and European Clients needed) from payment rules. Then the engineering team and I designed a new model based on an “If This Then That” logic. Merchants could combine multiple conditions in a single rule, and rules could be cumulative, meaning that if two rules applied, both would be shown.
Thus, a Samsung smartphone paid with Mastercard issued by Banco Provicia would inherit all applicable promotions at once, instead of requiring dozens of redundant rules.
Beyond the Interface: Redesigning Core Mechanics
VTEX's admin was being remade, and it posed the perfect opportunity to redesign our legacy tool as well. We proposed renaming entities for consistency and clarity:
Payment conditions → Payment rules
Payment ID → Payment methods
Installments and interest rates → Payment terms
Commercial conditions → Product groups
I separated payment methods (what USA and European Clients needed) from payment rules. Then the engineering team and I designed a new model based on an “If This Then That” logic. Merchants could combine multiple conditions in a single rule, and rules could be cumulative, meaning that if two rules applied, both would be shown.
Thus, a Samsung smartphone paid with Mastercard issued by Banco Provicia would inherit all applicable promotions at once, instead of requiring dozens of redundant rules.
Beyond the Interface: Redesigning Core Mechanics
VTEX's admin was being remade, and it posed the perfect opportunity to redesign our legacy tool as well. We proposed renaming entities for consistency and clarity:
Payment conditions → Payment rules
Payment ID → Payment methods
Installments and interest rates → Payment terms
Commercial conditions → Product groups
I separated payment methods (what USA and European Clients needed) from payment rules. Then the engineering team and I designed a new model based on an “If This Then That” logic. Merchants could combine multiple conditions in a single rule, and rules could be cumulative, meaning that if two rules applied, both would be shown.
Thus, a Samsung smartphone paid with Mastercard issued by Banco Provicia would inherit all applicable promotions at once, instead of requiring dozens of redundant rules.
Systemic thinking for a modular platform
The new design suggested geolocation-based experiences:
LATAM would see rich options like installments, promotions, and powerful conditioning.
US/Europe would see only payment methods, without cognitive overload.
Payment rules listing had filters, search, and different views for organizing rules
More than solving the present, the new structure was built to absorb future conditions and evolutions without decaying into patchwork, because instead of each condition (like date or product group) being a feature, they were options inside a much more robust system.
Systemic thinking for a modular platform
The new design suggested geolocation-based experiences:
LATAM would see rich options like installments, promotions, and powerful conditioning.
US/Europe would see only payment methods, without cognitive overload.
Payment rules listing had filters, search, and different views for organizing rules
More than solving the present, the new structure was built to absorb future conditions and evolutions without decaying into patchwork, because instead of each condition (like date or product group) being a feature, they were options inside a much more robust system.
Systemic thinking for a modular platform
The new design suggested geolocation-based experiences:
LATAM would see rich options like installments, promotions, and powerful conditioning.
US/Europe would see only payment methods, without cognitive overload.
Payment rules listing had filters, search, and different views for organizing rules
More than solving the present, the new structure was built to absorb future conditions and evolutions without decaying into patchwork, because instead of each condition (like date or product group) being a feature, they were options inside a much more robust system.
Impact and Results: From hundreds of setups to a dozen
In prototypes and user testing, we saw that Argentine enterprise clients could reduce their payment rules from 400+ down to around 20. A Brazilian client scenario dropped from 24 to just 7.
The tests highlighted immediate potential for operational efficiency: less time spent configuring, fewer errors, and clearer rule management.
Even subtle changes — like the new naming system — went unnoticed by participants, proof that the new structure felt natural.
While not fully implemented during my time at VTEX, the results validated the systemic, modular approach as the right direction for the platform.
Impact and Results: From hundreds of setups to a dozen
In prototypes and user testing, we saw that Argentine enterprise clients could reduce their payment rules from 400+ down to around 20. A Brazilian client scenario dropped from 24 to just 7.
The tests highlighted immediate potential for operational efficiency: less time spent configuring, fewer errors, and clearer rule management.
Even subtle changes — like the new naming system — went unnoticed by participants, proof that the new structure felt natural.
While not fully implemented during my time at VTEX, the results validated the systemic, modular approach as the right direction for the platform.
Impact and Results: From hundreds of setups to a dozen
In prototypes and user testing, we saw that Argentine enterprise clients could reduce their payment rules from 400+ down to around 20. A Brazilian client scenario dropped from 24 to just 7.
The tests highlighted immediate potential for operational efficiency: less time spent configuring, fewer errors, and clearer rule management.
Even subtle changes — like the new naming system — went unnoticed by participants, proof that the new structure felt natural.
While not fully implemented during my time at VTEX, the results validated the systemic, modular approach as the right direction for the platform.