VISA DIGITAL BENEFITS PLATFORM • SYSTEM DESIGN FOR CONFIGURATION OF CARD BENEFITS
Visa Digital Benefits Platform (VDBP) is an internal enterprise product used by issuing banks and Visa administrators to configure cardholder benefits and packages at scale. Over time, the product expanded beyond “creating benefits” into a richer system: tiers and extensions, parent-child relationships, approval workflows, package inheritance, and operational tooling.
VDBP sits at the intersection of policy, configuration, and operational risk. The design challenge wasn’t a single flow — it was building an interface that stays understandable as the system grows: more tiers, more extensions, more approval states, more constraints, and more downstream impact. The goal was clarity at scale without slowing teams down.
As issuing banks expanded benefit offerings across regions and card tiers, the old model pushed teams toward duplication: creating a new benefit record for every variation. Over time, the benefits library became crowded and harder to manage, and operational risk increased as more states and dependencies were layered on top.
We aligned on outcomes that supported scale and safety:
The core shift was moving from a copy-based approach to a parent-child model. Instead of creating a brand-new benefit for each variation, admins could define a base benefit once, add tiers, and create extensions that inherited and selectively overrode attributes.
Once hierarchy existed in the model, the UX could support package inheritance, prevent conflicts, and surface the “shape” of the system directly in the interface.
The benefits and packages menus needed to be high-signal views: clear hierarchy, clear approval state, and clear next actions. I added hierarchy and approval status as first-class information so admins could immediately understand what they were looking at (Base vs Extension levels) and what they could safely do next (Saved Draft, Pending Approval, Published, Expired, Rejected).
The result is menu-level triage: scan, spot what matters, and decide whether to approve, investigate, or edit — without hunting through detail pages.
Previously, selecting an item in the menu often meant navigating away immediately into a full detail view. I introduced an overlay pattern for both benefits and packages so users could get the essential information in context: status, history, relationship hierarchy, and included usage.
The overlay supports core actions without losing your place: approve, reject, view details, or jump into editing. This keeps teams fast during reviews and high-volume admin sessions.
The left-hand sidebar on benefit and package detail views was my addition. It provides stable orientation: where you are, what section you’re editing, and what relationships exist (parent/child, related packages, related benefits).
On packages, the sidebar also surfaces summary information by card tier (count, cost, value) and breaks down responsibility (Visa vs Issuer) so users can reason about impact while configuring a package.
Benefits are governed by eligibility and qualification rules (tiers, coverage limits, currencies, periods of time, and regional constraints). The design had to support deep configuration while keeping the UX navigable and auditable.
Benefits needed to support multiple markets and supporting documentation. Additional language support and attachments were designed as first-class sections so admins could manage localized content and required documents without losing context.
Enterprise workflows involve partial completion, missing files, and validation failures. Designing the “unhappy paths” mattered here: the UI needed to communicate what went wrong and what to do next without derailing the overall workflow.
Packages are where benefits become “real” for cardholders. The UI needed to show not only which benefits were included, but how they were inherited or cascaded from parent packages, and how optional bundles and cardholder choices affected the final structure.
Adding benefits isn’t just selecting from a list. The system enforces rules to prevent conflicts (e.g., a child benefit can’t be added if the parent is already included, or vice versa). These constraints were made visible in-context so users understand why something is blocked and how to proceed.
As VDBP matured, operational features were added to support real-world maintenance. Renewal reminders and email settings are one example: the product needed to handle time-based states and notifications without forcing admins out of their workflow.
I’m proud that this product scaled with increasing complexity without becoming brittle. Most of the work was about making relationships, risk, and state visible enough that admins could move confidently and quickly — and avoid expensive mistakes.
Next, I’d push further on previewing downstream impact: clearer “what will change if I publish this?” indicators before committing actions that ripple into packages and assignments.
LinkedIn
AngelList
Dribbble
Twitter
Pinterest
Medium
Behance
