Glossary
Terms and concepts that should help you understand the Marketplacer platform quicker.
4 minute read
| Term | Alias | Description |
|---|---|---|
| Advert | Product | An Advert is essentially a Product in Marketplacer (it is referred to as an Advert for historical reasons). An Advert belongs to 1 Seller and has 1 or more Variants. |
| Advert Vetting | Product Vetting | Advert Vetting is an optional workflow that an Operator can enable. Vetting allows the Operator to ensure that Products (Adverts) adhere to their own publishing standards before they can be placed for sale on the marketplace. |
| Catalog Rules | Catalog rules allow the marketplace operator to set further validation criteria for products and variants that have to be satisfied in order for a product to be considered valid. E.g. A product must have a minimum of 3 images and a description length of at least 250 characters. Catalog rules complement Advert Vetting. | |
| Connected Integration | This is the primary way that Operators will connect their existing eCommerce platform into Markerplacer. With this model the frontend shopper experience, (including checkout and payment), is still provided by the Operators eCommerce platform. | |
| Golden Record | Golden Product | Golden Records are template products held in our central product database, that allow products to be created quickly and consistently using that product template. |
| Invoice | Order | An Invoice is the part of the overall customer order that an individual Seller has to fulfil. An Order will always have at least 1 Invoice (1 Invoice per Seller participating in the Order) |
| Invoice Amendment | Following the completion of an Order (and therefore the creation of Invoices) there may be reasons why those individual Invoices need to be amended, (for example when a customer requires a refund). In such cases an Invoice will have associated Invoice Amendments. An Invoice can have 0 or more Invoice Amendments. | |
| Operator | The business entity that runs the marketplace and is the merchant of record for the transactions that occur on the marketplace. | |
| Operator API | The GraphQL API that provides Operators with the ability to build (amongst other things) a Connect Integration | |
| Option Type | Attribute | Option Types refer to the way an Advert or Variant can be defined. So common Option Types would be color and Size. Option Types will then have 1 or move Option Values, which contain the range of values that it is possible for the Option Type to have. |
| Option Value | Attribute Value | The values that an Option Type can have. In the example where we have an Option Type of Color, possible Option Values would be: Red, Green, Blue etc. |
| Order | An Order is the “marketplace-level” object that acts as the container for a customer’s entire purchase. An Order object in Marketplacer will always have at least 1 Invoice attached to it, (1 invoice per seller) | |
| Prototype | Attribute Group | Prototypes are the glue between a Taxon and the Option Types that Taxon has. So we assign Option Types to a Prototype, and then assign a Prototype to the Taxon. This means we can assign that same defined Prototype to any number of other Taxons. |
| Remittance Advice | Remittance Advices group multiple Remittances together under 1 “advice”. Prior to this feature you had to rely solely on the relationship between a Remittance and an Invoice / Invoice Amendment (a Remittance can only relate to 1 Invoice or Invoice Amendment) which made things like reporting problematic. With Remittance Advices, it is now easy to see the relationships between multiple Remittances and the Invoice (and Invoice Amendments) that they are related to. | |
| Remittance Action | This is a GraphQL object type that models the payout actions to occur, e.g. the use of Hyperwallet to pay a Seller. | |
| Remittance Event | This is a GraphQL object type that models the events on an Remittance Action. e.g. did the action to pay a seller via Xero succeed or fail? | |
| Seller | Retailer | Business entity that places products for sale on the marketplace. A Seller is responsible for fulfilling Invoices on an Order, a Seller can only have 1 Invoice per Order. There are usually 10’s, 100’s or even 1000’s of individual Sellers on a single marketplace. |
| Seller API | The GraphQL API that allows Sellers to build integrations into Marketplacer. This can take a number of forms but will usually include the following functions: Product Creation, Invoice Retrieval & Shipment Creation | |
| Legacy Seller API | v2 API | The REST API that allowed Sellers to build integrations into Marketplacer. This API is no longer being actively developed and has been replaced with the GraphQL alternative. |
| Taxon | Category | A taxon represents where the product sits in the categorization hierarchy. The products taxon, determines the Option Values that can be assigned to it, this relationship is enabled via the prototype. |
| V2 API | Legacy Seller API | See Seller API Legacy |
| Variant | An Advert always has to have at least 1 Variant. It is at the Variant level where concepts such as SKU, Barcodes and Inventory sit. When placing an order in Marketplacer, it is the Variant that is actually being purchased. | |
| Vetting | See Advert Vetting |