Web Content Display

Merchant Management

Finding the right solution for your business setup can significanlty increase the transparency and efficiency of your business operations. At optile we offer two merchant setup options, which can be adjusted and suited to fit your business: 

  1. Single Merchant Setup
  2. Group Merchant Setup

The simple setup is meant for a single business model, which is represented as a merchant with a single default division.

Each merchant can also have one or more business lines, regions, or other entities which are represented as merchant's divisions. In the Figure 1 below,  this setup is depicted as a connection between optile and a single merchant. In such a setup it is also possible to share the same payment provider credentials between divisions. The number of divisions is unlimited.

User accounts at the Merchant level can be configured to have access to payment-related data of all divisions. Thus, a user can get access to data on an individual division level and get an aggregated overview of all divisions' performance.

Figure 1. Merchant Setup Structure

Web Content Display

Merchant Groups

As your business grows, so does the organizational complexity. In order to provide transparent and flexible management of your expanded and grown business, optile also offers the setup for a merchant group with one or more merchants.

In this setup a Client can scale up from a single merchant to a group of merchants. In this scenario, each merchant can be configured to have the full functional capacity as in the standard single merchant setup or to have restricted configurations, depending on a Client's preference. For example, an individual merchant can retain the autonomy of configuring payment routing on his own, or  this can be restricted for him and configured only by users with rights on a higher merchant group level.

The essential benefit of this setup is that a Client can gain overarching functionality across individual merchants. Thus, grouping merchants allows to centralize the management of payment flows, to get an aggregated view on monitoring, invoicing and reporting of payment data, as well as to configure user accounts accross merchants (see Figure 2).

The centralized management of payment flows is an option for a Client to configure how the transactions should be processed for individual merchants. This includes the  entire optile's range of applications  for configuring merchant contracts, routing of payments, settings of automated denial management, etc.

Besides the possibilities of monitoring, invoicing and reporting on payment data per merchant, users on a merchant group level additionally gain an aggregated overview of such data for all merchants and their divisions. Thus, it is possible to analyze individual transaction details per merchant and drill-down into an individual merchant's payment flows, as well as to receive the statistics and invoicing on a cross-merchant level for a global overview of payment trends.

Having this range of functionality makes it essential to ensure that each user has the proper set of access rights. This can be done with the flexible user management system offered by optile. Thus, the access rights of users can be configured to be restricted to a single merchant, to several merchants or to an entire group of merchants.

Figure 2. Merchant Functionality Areas

Web Content Display

Divisions vs Groups

Compare the implications of using Divisions vs. a Group with multiple merchant accounts:

  Divisions (of one Merchant) Group with multiple Merchant accounts
API Access Simple: All Divisions use the same API credentials. Separate: Each merchant account has a different set of API credentials.
User Access Simple: All merchant users have access to all divisions, to the same degree depending on their role. Fine-granular: Users have access to those merchants they belong to. This can be configured to be the whole group, but doesn't have to. The degree of access can vary by assigning different roles for different merchants.
Provider Contracts Configuration Shared contracts: Each division can use all contracts that were defined for the merchant.

Separate: Different merchants cannot share contracts. So contract data has to be entered again if needed.

Using the same provider contract in scope of 2 or more merchants may lead to technical issues with Chargeback processing if it is based on SFTP report files that can only be done in scope of 1 merchant (danger of race condition if 2nd merchant tries to process report files of the same contract), e.g. with WireCard or Global Collect.

Notification URLs of Providers

No issues: Typically division differentiation by providers is neither supported nor necessary.

 

Caveat: If a notification URL (provider to optile) is configured on the provider side, it can only identify one merchant (notification URL includes merchant code). In this case multiple merchants cannot use the same provider account.

Examples: Adyen, Sofort (workaround through "projects" possible), PayOne, Neteller. Possibly others.

Customer Registrations Shared: Account and Recurring Registrations are shared, i.e. they can be used by any division. Merchants cannot share Account and Recurring Registrations.
Dynamic Payment Page Individual payment page and routing configuration, further separation by country possible. The same as with Divisions.

 

Divisions vs Groups

Compare the implications of using Divisions vs. a Group with multiple merchant accounts:

Please sign in to view further details of this article. Login

Web Content Display

White Labeling

If you are a platform provider with multiple merchants as your customer, you can offer white-labeled frontends for your customers to configure their payment setup and analyse their payment data on optile's side without getting in touch with the optile brand.

  • Option 1: Leverage optile's API-first approach to build your own frontends. Your system can get access to (almost) all APIs that are also used by all applications of the optile merchant portal. Please approach us about the authentication details.
  • Option 2 (planned for the future): optile portal white-labeling. A centralized definition of your corporate design (e.g. colors and logo) applies to all of optile's frontend applications, such as Merchant Portal, My Customers, My Dashboard, My Transactions, Risk Management and other applications.
  • Option 3 (planned for the future): Integrate the frontend code of an optile portal application directly into a your native website. This way API access and UI rendering are handled within your domain with minimal coding required on your side. This would need a preparation of optile's authentication system in order to permit users' access tokens that were issued by your identity provider.

 

White Labeling

If you are a platform provider with multiple merchants as your customer, you can offer white-labeled frontends for your customers to configure their payment setup and analyse their payment data on optile's side without getting in touch with the optile brand.

Please sign in to view further details of this article. Login