We love helping our clients simplify complicated environments so that payments can be leveraged as a strategic asset. Payments technology has evolved greatly since our firm’s inception, and will continue to do so, but we are always excited to keep up with it. We’ve seen the birth and retirement of different services and philosophies, learning what’s worked, what hasn’t, and why. During times of transition, our clients rely on us to help them stay on track for their goals and to keep them abreast of novel approaches that have proven effective. 

You may be interested in our Infrastructure Review if you are:

• A startup seeking to design and install revenue-handling infrastructure intended for scalability, security, and flexibility.
• Undergoing digital transformations as they migrate to newer cloud-based infrastructure.
• Seeking to enable and maintain payment processing services without exposing the rest of the technology stack to data security risks or overburdening technical debt.
• Transitioning your business model to effectively leverage the benefits of the marketplace and payment facilitator models. 

Our process for this service can generally be broken down into: the Business Framework, the Infrastructure Review, the Architectures, and the Target Operating Model. We like to address Digital Transformation from these four categories because we believe that, as an asset, payments must be fully integrated across business operations and technical functions. As we describe our process in further detail, our guiding principle will continue to be positioning your payments acceptance as a strategic asset for your company’s goals. 

The Business Framework

The function of a payments platform is determined by business needs, but very often, we see that clients have built their processes the other way around. We identify how the payments strategy aligns with the overarching business strategy (if not previously identified) and prioritize the ways in which payments matter most to your organization. 

To put it simply, rank how your CEO would prioritize the following?

• Enhance the customer experience, increasing sales by maximizing approval rates, and mitigating the effect of outages.
• Support growth by connecting to multiple endpoints that enable customers to pay using the currencies and forms of payment which they prefer.
• Lower the cost of payment processing and operations and thereby contributing to the company’s bottom line.

These upfront findings dictate all of our gaps analysis and recommendations, both throughout the engagement and within the final deliverables. The principles discussed when determining the business framework will define the governance of the payments platform and drive all further business decisions. In turn, this framework drives all technical and architectural decisions downstream. RPGC will document the current governance structure in conjunction with the Business Framework to identify any recommendations that better support your specific goals and priorities.

Our calling card is the Entity-Relationship model that we use in this stage of the workshop. While it is often perceived as a technical exercise, RPGC uses the Entity-Relationship model to identify the anatomy of your payment ecology. We focus on how all the actors (e.g. customers, sub-merchants, agencies) and elements (e.g., invoices, payment instruments) interact with each other, allowing us to identify friction points and define business rules. The Entity-Relationship model allows us to find workable compromises and implement best practices that are both realistic and aspirational. 

Gateway and Orchestration Review

As the primary connection to the rest of the ecosystem, the gateway plays a prominent role in the payments stack. We examine the functionality and capabilities of your gateway to identify its current fit for purpose. As a part of our review, we look for:

• Outage and Latency Management. How well does your gateway automatically and immediately switch transactions from failed or slow PSPs to alternative PSPs to avoid outages, timeouts, and the resulting customer abandonment?
• Optimized Routing. How is the routing criteria defined to maximize approval rates, minimize payment costs, and automatically execute those rules with no manual intervention? Are tools provided for non-technical staff to make routing changes for pay-ins and pay-outs?
• Retry Declined Transaction Logic. What logic and end-user tools are used to define criteria for retry declined transactions and input decision trees for these retrials? Does it automatically execute those rules without manual intervention?
• Tokenization. How are tokens managed across multiple providers? Additionally, how do you coordinate the tokenization/detokenization of payment credentials to optimize transaction routing flexibility?
• Card Scheme and Regulatory Compliance. When an update is required, which platforms need changes?
• Nuisance Fee Avoidance and Interchange Optimization. What processes exist today that help minimize card scheme fees (such as “misuse of authorization” or “floor limit” fees) and ensure that transactions have all the proper data elements for optimal interchange qualification? Which of these processes can be automated?
• A/B Testing. What processes and tools are in place to run and report A/B testing, whether the variable in question is a new decline-retry strategy or alternative routing ruleset?  

Given our extensive research, we’re certain we can help you determine what functionality best helps your business.

Reporting Review

We see reporting not as a cost-control function, but a growth management tool. As operations scale and expand, so must reporting requirements. No one debates the need for holistic reporting, with the ability to drill down into granular transaction-level details on a near-real-time basis. Having that level of breadth and depth requires the use of a payments data warehouse (a risky proposition if uncompleted or poorly designed) or customizations to a vendor tool. With our experience designing reporting environments and our intimate knowledge of the market solutions, we can take a lot of guesswork out of scope. Our actionable guidance can prevent reconciliation from becoming a growing problem so that your folks aren’t spending much of their time just compiling reports across providers.

We review the existing available data elements and help gather the remaining requisite data that needs to be mapped to transaction reporting. We identify the necessary features your solution needs to support to meet the business requirements and the tools that will be used to retrieve, ingest, process, manipulate, and present the payments data. By interviewing the stakeholders who operate the solution and the end-clients of the solution (payments, risk, treasury, finance, accounting, marketing, etc.) we determine the priorities that the implemented reporting solution needs to solve.

When our clients build a data warehouse, we help define which other technical services (both internal and external) that feed the warehouse. We also help our clients define the dashboard design, the SLAs the warehouse must be kept to, the KPIs to track and the alert thresholds to notify users when volume is out of pre-set tolerances. These processes will keep our clients on track for their goals after our engagement has ended. We have seen the effects of compelling data-powered narratives for change within several of our clients; we advocate for access to good data.

Platform Architecture

Architectures organize payment processing requirements into functional components that quickly communicate how operational elements interact with each other and with internal business units. When done right, they are built to adhere to the Business Framework. This approach is beneficial because it maps the effective means for performance monitoring, risk management (both fraud and credit risk), and data compartmentalization. It’s our “secret sauce” to developing guiding north stars for our clients.

Each Architecture organizes the payment processing requirements to define your Target Operating Model. While initial development is arduous, such Architectures significantly reduce the effort and cost required to operate a global payments platform and implement new methods of payment in the future. Because each organization is different, even from those in the same industry, these Architectures are not a “cookie-cutter” one-size-fits-all approach. Instead, these Architectures serve as templates to ensure all requirements are accounted for so that continued effort and costs are reduced when developing, operating, and maintaining a global payments platform.

The Functional Payments Architecture

When there are multiple channels interacting with each other, clear business and technical interfaces between channels and ownership needs to be defined. What makes the Functional Payments Architecture unique is that it defines canonical views of transactions so they can be consistently processed by the platform, regardless of payment instrument. We organize payment processing requirements into functional components, which quickly communicate how operational elements interact with each other and with internal business units. 

Functional components are defined in plain language and built to adhere to the Business Framework. The Functional Payments Architecture also identifies boundaries and establishes clear responsibility for each function and mapping it with back-office systems. These boundaries facilitate the development of APIs between functions, easing the introduction of new or enhanced components by easily “plugging them in” with minimum platform disruption. 

This methodology maps all payment method flows and the locations of payment platform’s functional components in order to facilitate their technical and business implementation. RPGC uses this model to identify functions that are in place and functions that will need to be developed in order to support other forms of payment.

The Functional Fraud/Risk Architecture

The Fraud/Risk Architecture identifies the components, tools, and their interaction to minimize fraud losses. Using the client’s defined acceptable risk profile, this Architecture identifies where the fraud/risk function is integrated into the overall platform. Like the Functional Payments Architecture, the Fraud/Risk Architecture identifies boundaries between functions and components that are then mapped back to back-office systems.  This Architecture maps the locations of the risk and chargeback management tools, customer service, and how they interact with customer-facing channels. Doing so ensures economic design using a layered approach, regardless of which pieces of the risk platform are bought or built. 

Operational Architecture

The Operational Architecture describes the rules and procedures that need to be established to ensure consistent and efficient payment processing across all channels regardless of payment instrument or checkout flow. These processes include customer/agency onboarding, decline retry approaches, and reconciliation. RPGC defines the roles and responsibilities for operating and managing the payments platform, as well as the required skills for each role. We also share best practices for vendor’s day-to-day management, including how to perform a Quarterly Business Review, how to successfully escalate issues with vendors, and how to manage the Vendor’s performance according to clear and mutually agreed upon Service Level Agreements (SLAs).

Technology Architecture

The Technology Architecture outlines the physical attributes of the platform such as database structure, event logging capabilities, and connectivity. The objective of this Architecture is to define the requirements for the IT organization to make the platform fault-tolerant and resilient while efficiently supporting high transaction volumes and being capable of linearly scaling up.

Compliance Architecture

The Compliance Architecture defines the ideal data architecture to optimize PCI DSS control costs. Approaches to contain or reduce scope including P2PE, tokenization, and segmentation will be reviewed and applied to the current state architecture. The list of scope reduction opportunities, controls, and flows will be documented and updated here.

Organizational Architecture

The Organizational Architecture documents how the payments function should be organized and how information should flow between internal stakeholders. This Architecture defines the roles for those individuals operating and managing the payments platform plus the required skills for each role. Our recommended headcounts, resource requirements, and job descriptions are based upon your transaction volume, count of payment vendor relationships, toolset, and business complexity.

Target Operating Model

Using the above Architectures as the underlying foundation, the Target Operating Model defines the ideal payments processing environment within a two-year roadmap. It consists of the Business Framework, the Architectures, the aforementioned two-year roadmap, and recommendations for an ideal working state. These recommendations are arranged so that you can begin to implement them while:

• Causing minimum disruption to the business, 
• Maintaining the Business Framework, 
• Keeping payment and fraud costs low, 
• Enhancing the customer experience.

We love to empower our clients with the necessary knowledge to reach attainable goals that support the overarching business and push them to think about the future strategically. No two clients are alike, regardless of geography, Merchant Category Code, or culture. While 3-5 year strategies are wonderful guiding stars, it’s difficult to realistically plan more than 18 months in advance. Our Payments Infrastructure Design and Review ensures that you have a target landscape custom tailored for you.