Glossary
Terms and concepts that you should help you understand the Marketplacer platform quicker!
3 minute read
| Term | Description |
|---|---|
| Advert | 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 | 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. |
| Connected Integration | This is 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. |
| Invoice | An Invoice is the part of the overall customer order that an individual Seller has to fulfill. 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 |
| 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) |
| 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 the release 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 | Business entity that places products for sale on the marketplace. An 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 event 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 |
| Seller API Legacy | The REST API that allowed Sellers to build integrations into Marketplacer. This API is no longer bing actively developed and has been replaced with the GraphQL alternative. |
| V2 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 |