Visa's stated purpose is to uplift everyone, everywhere by being the best way to pay and be paid.

This is achieved through Visa's payment network alongside various technologies and extend it.

One of these technologies is Click to Pay, an EMVco standard for online payments.

Before 2019, the four major card networks had their own online checkout solutions, with Visa's being Visa Checkout.

The consumer portal for managing Click to Pay, internally known as the Destination Site, dates back to the creation of Visa Checkout.

With the EMVco standarization of the Click to Pay specification, the goal was for issuing banks to adopt and implement Click to Pay the same way they had implemented Contactless: as a feature of the card.

As a result, issueing banks were expected to manage Click to Pay as a card feature, rather than Visa continuing to maintain a cardholder-facing portal. This lead to a low prioritization for enhancements to the Destination Site.

Despite a brand refresh in 2019, its overall look, feel, and architecture has remained largely unchanged.

By 2022, issuers largely still hadn't adopted management of Click to Pay as a card feature, so the Destination Site remained in use.

Over the next year and a half, there were brief attempts at improving parts of the site and occasionally discussing a full redesign, but these efforts did not progress due to limited prioritization.


The team had explored a simple reskin of the Destination Site, but engineering flagged that we could not limit the work to visual changes; meaningful “under-the-hood” updates would also be required and could not be prioritized at the time.

Around this time, I was assigned to update the registration flow for the Destination Site so that we could support stronger identity verification and new technologies such as passkeys.

By Early 2024, we decided to completely redesign the Destination Site.

New features that depended on the portal had gained priority, so we needed to improve the overall experience as much as possible.

I worked with my Product Manager counterpart to outline our objectives:

  • Adopt Visa's current design system to ensure brand cohesion and accessibility compliance.
  • Re-envision the Destination Site as a flexible framework so new features could be added more easily over time.

We also had some limitations to start off with:

  • Engineering capacity and prioritization were still unclear, though we had access to a technical architect in the interim.
  • We could not rely on near-term support from our design research team, and the existing Destination Site had limited instrumentation, which meant we had very little real usage data to guide decisions.

To get started, I broke down the key objects that users interact with into their constituent metadata and mapped how they relate to one another.

From there, I drafted multiple information architecture options, grounding them in design heuristics and other established principles.


Our next step was to create wireframes for the most promising information architectures and partner with design research to conduct user testing.

About a month into this process, we heard that the team working on Visa Payment Passkeys was planning its own consumer-facing website.

Rather than building two separate sites for cardholders to manage Visa card features, we decided to work toward a single experience we called the Visa Consumer Portal.

The Passkeys designer and I audited the state of our respective projects and collaborated with our product partners to determine how to move forward.


This expanded scope introduced new considerations:

  • Click to Pay's backend was outdated, and substantial changes were out of scope in the near term, while the Passkeys backend would be entirely new.
  • We identified another product that handled marketing opt-in for cardholders, but we did not yet know whether that team would want to migrate onto the unified platform.

Because of the technical landscape, we evaluated two main approaches:

  • Build a single website that could bridge data from two separate backends until Click to Pay's backend could be re-architected, or
  • Create a shared design language and launch two separate portals, with the option to consolidate them later once the Click to Pay backend was modernized.

The biggest constraint was time: the Passkeys portal needed to launch in August, with engineering work starting in early June.

These converstations were happening in mid-April, which meant we had six to eight weeks to hand-off designs to engineering.

I mapped the next eight weeks of work into two-week increments, starting with alignment at a high level.

To ensure a shared mental model and vocabulary, I led the group through the same data-object and information-architecture exercises I had used for the Destination Site redesign

We used that model to iterate on different information architectures, relying on peer and stakeholder feedback to choose navigation patterns that best supported common use cases and jobs-to-be-done.


Next, we began exploring the UI.

We produced several layout concepts for the home and card views and refined them through regular critique sessions.


At this point, we provided an initial handoff to engineering so they could begin scoping their work.

We had aligned on the main page layout and broken it into reusable components to support modularization, especially since Click to Pay and Payment Passkeys would remain separate portals in the near term.

We delivered MVP Consumer Portal designs on time, but due to various factors the redesigned Click to Pay Consumer Portal did not launch until mid-June 2025, nearly a year later.

Our goal of creating a modular, extensible framework was achieved, as the new design and front-end architecture now make it much easier to support additional functionality.

However, the recent launch, the lack of instrumentation on the previous Destination Site, and low overall Click to Pay adoption mean that we cannot yet quantify improvements with meaningful metrics.