SAP Payment Portals:
Selecting the right solution for your organization
Software selection is challenging enough for IT organizations. Add in concerns and risks of storing and processing credit card transactions, those challenges increase exponentially. The primary concern for any solution being evaluated is PCI Compliance, which is a certification process ensuring no raw credit card data is stored or accessible within the ERP system. Some additional considerations include AR processes included in a solution, target audience, hosted versus on-premise, managing 3rd party vendors, solution customization, and finally cost. There are additional considerations when making a selection, but these are the most common and the topics we will cover in this post.
Accounts Receivable Processes
There are many SAP Accounts Receivable processes which could be in scope for an SAP Payment Portal Solution. The most obvious one and the main reason for selecting a solution is the ability for customers to login, list, and pay open invoices. This is just the beginning. There are also processes to consider such as Partial Payments, Residual Payments, Settlement, Cash Applications, Disputes, Collections, Auto-Payments, Credits, and Surcharges. Before embarking on a search for a solution, it is important for those in AR to define what processes must be included in any solution. Not all these processes are customer facing and therefore may not be required as part of a solution. Proper planning will help in creating short lists of vendors whose solutions are a match from the start.
Target Audience
One of the important questions to ask when choosing a solution is who is the target audience? As was mentioned above, there are numerous AR processes and not all of these are customer facing. Is the goal to replace working with AR processes in SAP with a web-based tool? If so, then a solution that includes all those processes may be more suitable but would come at a higher cost, more complexity, and longer implementation periods. If the target audience is only external customers who need the ability to login and pay open invoices, then a solution with critical features but less back-office support functions is a better fit as these solutions are less costly, have smaller delivery teams, and deploy much more quickly. Within the audience of external customers there are large versus small organizations. This has an impact on the solution selected. Large organizations tend to have more automated processes such as direct debit, EDI, etc., where users would not have a need to login to a portal. It’s the smaller organizations without large volumes of transactions that would benefit from a payment portal.
Hosted versus On-Premises
Another significant decision for customers evaluating SAP Payment Portals is whether to select a hosted or on-premises system. Hosted solutions rely on the vendor to maintain the system technically while the customer’s resources are dedicated to content, catalogs, master data, user management, etc. Customers choose this type of solution because they may not have the in-house skills or resources to maintain such a system. These Payment Portals, even when hosted in a private cloud, tend to be less customizable since implementations are on a common code base. When a new release is deployed, all customers get the new features. Highly customized Accounts Receivable processes paired with a very standard and close to out-of-the-box solution may fall short of critical business requirements.
Managing 3rd Party Vendors
Once all the requirements are defined and a shortlist of solutions has been defined, understanding and managing the vendors involved will move to the forefront. When it comes to payment processing it is certain there will be more than one 3rd Party vendor to work with. It may not be only the vendor selling the solution, it would include gateway processors, processors for the banks, additional vendors with specialization in certain areas such as 3D-Secure Credit Card processing. The most important aspect is asking the right questions. Vendors have a responsibility to make clients aware if their solutions require establishing relationships with other vendors and if there may be additional license implications with those vendors, etc. This is not to suggest one vendor is responsible for ALL the information about another vendor or partner, but it is highly likely these vendors have existing relationships or partnerships and can advise a potential client as to what questions they should be asking and who else needs to be involved.
Solution Customization
All Payment Portal solutions on the market can be customized. The level of customization will depend on the type of solution whether it is hosted or on premises. Hosted systems, even those in a private cloud, tend to be less customizable because all customers are on a common code base. Customizations may be limited to field labels or styling of the portal with corporate logo, colors, fonts, etc. Business processes on a hosted solution are less customizable. Clients need to be prepared to sacrifice on processes if the primary goal of a solution is having a vendor maintain it. An on-premise solution favors a high level of customizations since the client is getting a code base they can modify as much as needed and is not shared with other customers.
Cost
When it comes to pricing SAP Payment Portals there are a variety of models customers will encounter. Costs will be made up of implementation, subscriptions, licensed modules, transactions, and/or number of users. There may be different cost for web-based transactions or modules versus transactions or modules used in the SAP system. There may be additional costs for support or maintenance agreements. The important point is to ask the right questions before seeking budget so all costs are known. Nobody wants to seek more budget after making the initial request. Let’s review some of the cost components. First, we will look at implementation. Implementation costs will vary depending on the solution selected. Solutions with a common code base and less customizations will have lower implementation costs. The size of the delivery team can impact costs. Ask the vendor what an out of the box implementation costs and how long those projects run. Ask the level of difficulty in making customizations, this can also drive up cost. Next there may be licensed modules sold by the vendor. This gets back to the topic of the target audience. If the primary audience are external customers, not all modules may be needed. Ask if modules are licensed separately for web access versus SAP. Ask if there are any maintenance fees for licensed modules. Next are potential subscription costs. These will typically be tied to a metric such as number of users or number of transactions executed in the solution. Make sure this is defined clearly and if there is any auditing mechanism and if so, how that process works and what is the frequency? The bottom line, pricing can be very confusing and fraught with surprises, so asking the right questions up front is critical
Conclusion
When selecting an SAP Payment Portal there are a myriad of considerations. This post only covered some of the most critical of those considerations. There are more things to consider, but with proper research, planning, and evaluation a right-size solution can be selected and improve cash flow for the organization. Some potential customers may find the process too daunting and opt for a vendor who specializes in software selection to run the process for them from short-listing to demo evaluation, to final selection. This adds cost to the entire project but it can also ensure the proper solution is selected.
