Quick start

🚧

In development

A previous version of the Merchant Boarding API (v2 and v2.1) is live currently, however a new enhanced version is in development. The new version suits the requirement where consumers send information in sections before submitting the full payload. The new version of the API expected in Q3 2022.

The current version that is live requires the consumer to send in all information in one payload, as opposed to invididual sections.

Please note the API specification may change while it's in development

Boarding merchants to Fiserv systems is a key prerequisite for them to start processing transactions. The boarding process sets up a merchant in the appropriate systems and activates the desired services and equipment.

Why use the boarding API?

There are multiple components involved in the processing of a transaction end to end. Each system is responsible for one or more of the following example processes:

  • transaction authorisations
  • transaction clearing, settlement and funding
  • billing and inventory
  • customer relationship management
  • credit risk assessment

Instead of entering the merchant's details into each system individually or even manually, the merchant boarding API provides automation. This improves the quality of the data and eliminates the chances of mistyping. Furthermore the overall merchant activation process is significantly accelerated.

Required APIs and resources

Required APIs

Merchant Boarding Resources

A merchant is structured into 3 core components:

  1. A business can be used to organise a merchant into different segments (e.g. geographical locations) and to form a layered hierarchy. A business doesn't have a transacting MID (merchant ID) so never has any terminals associated directly to it.
  2. A store can be physical or online and is where transactions take place. A store has a transacting MID so will have terminals associated directly to it. These stores will sit under a business.
  3. An ownership entity is associated to the parent business entity and contains the details about the legal entity and the owners of it i.e. the directors and/or main beneficiaries.

The API is comprised of several resources which make up a complete merchant application:

  • Bank Accounts: these are the bank accounts associated with the merchant for pay-outs (funding) and fees
  • Contacts: these are the contacts details used for stores or businesses e.g. shipping, billing, legal. The address used for contacts is always related to the merchant (it's not the personal address of the contact)
  • Owners: these are the details about the owners and main beneficiaries of the merchant. Details include ownership percentage and personal contact details which are then used for KYC and AML checks. The address used for owners is always the personal address of the owner
  • Stores: these are the physical or online stores where transactions take place. The details captured here serve two main purposes. One is to ensure the store is set up with the right equipment and acquiring offer. Another is to ensure underwriting checks can be carried out effectively
  • Businesses: these are the details about the business (name, mcc, bank accounts) and its structure. A parent business can be set up to have child entities to form a hierarchy structure
  • Ownership Entities: these are the legal entity details about the merchant, which included the owners
  • Merchant Applications: this resource contains the details related to a specific application (status, seller information, documents), and is used to create, update and monitor applications

Process flow

The process below splits up the merchant application into individual resources so that the consumer can input information in sections with smaller payloads. Then the whole application is connected together using IDs.

πŸ“˜

All resources require a merchant application to be created first. Any resources created under a merchantApplicationId can only be used for that application.


Did this page help you?