Skip to main content

Merchant hierarchy

Depending on your business structure, you may need to create and manage several merchant accounts.

Think of each business entity as a separate node in the hierarchy tree you create within Fraugster. All nodes represent logical groupings of merchants that require at least an AI model on our end.

There are two types of nodes: leaf nodes and connecting nodes. A leaf node is a node that sends scoring requests to Fraugster. A connecting node groups other nodes logically.

The node at the root level of the hierarchy is the node where the technical integration with Fraugster happens. This includes the API integration with the Fraugster platform either as a channel partner (typically a PSP) or as a direct customer (typically payment companies or standalone merchants). A connecting node does not send scoring requests to Fraugster. Leaf nodes should do that instead.

Fraugster supports up to 5 levels in the hierarchy (integration node + 4 levels of nodes). Nodes inherit the configuration of their connecting node unless you decide to change it.

This articles serves the purpose of showing you a few examples of hierarchies. You don't have to figure it out on your own – we help you work out the correct hierarchy that best answers your needs.

When do I need to create a new merchant?

When you are setting up your technical integration and Dashboard account, answering the following questions helps you understand how many merchants you need to create in the hierarchy.

  • Does a node need a customized model for scoring transactions?
  • Does a node represent an invoiceable entity?
  • Does a node need a separate Fraugster account?

If the answer to at least one of these questions is yes, then this entity does represent a separate merchant in the hierarchy and needs to be configured as such.

If, however, the answer to all of these questions is no, then this entity doesn't represent a separate merchant, but rather a sub-merchant. A sub-merchant is always associated with a particular merchant and always inherits its configuration. It makes sense to set up a sub-merchant if you want to be able to filter its flow on the Dashboard and see metrics in reports.

How are nodes identified?

The entity that directly integrates with Fraugster is assigned a client_id within Fraugster. This is a unique ID used by Fraugster internally.

Every node that represents a merchant has a unique seller_id. It is agreed upon with the client during the integration process. A leaf node that sends scoring requests must have a unique seller_id; this datapoint is mandatory in every scoring API request.

A sub_seller represents the ID of the sub-merchant. It's sent with every API request to identify the sub-seller. Important: sub-seller is not a mandatory datapoint, so we don’t validate this data. You must ensure data quality if you want sub-seller information to be displayed correctly on the Dashboard and work in rules.

Here are a few examples of merchant hierarchies:

At your node, you can only view transactions that belong to you and the nodes down the hierarchy (not up the hierarchy).