Business Entities
Logical Entities
Pliants API endpoints are grouped by the relevant classes of data objects available on the Pliant platform. Learn more about that on this page.
Our API design is reflecting these data objects. Each entity has one or multiple REST endpoints to read and update data. Additionally, we offer callback subscription endpoints, which can be used to register a callback URL for relevant events.
Entity Relations
Description of Entities
| Entity | Short Description |
|---|---|
| Organization | Basically our (and our partners) customers. That's the entity that has the contractual business relationship with “us” (Pliant). An organization must be a company and has at least one cardholder. |
| Team | Organizations can (but must not) have one or multiple teams. Teams help our customers to group cardholders logically (e.g. departments, hierarchies). For accounting purposes we also enable customers to assign a cost centre number to each team. |
| Cardholder | Cardholders are most likely the employees of the Organizations. There are several roles (e.g. Admin, Owner, Accountant, Cardholder). One cardholder can have multiple roles. One cardholder can also be part of multiple organizations. A cardholder is typically the one who is using the credit card or the admin/accountant who is approving transactions. Important: Only you as a partner of Pliant has access to the Pliant API, so it is through your interface that the organizations (typically, your own customer) cardholders can interact with this API. |
| Card | We do offer physical and virtual credit cards which must always be assigned to one cardholder. A card does have a certain spending limit (which reflects the overall organization's spending limit as well). Important: A cardholder can have multiple cards but one card must always have one cardholder |
| Transaction | With our cards, the cardholders are able to pay almost everywhere. Thus transactions most likely reflect payments. There are a few special cases (Refunds, Chargebacks and Card checks). The transaction object holds all the accounting relevant data. Important: Most elements of a transaction cannot be changed as they are provided by our payment partners (e.g. Amount, Date, Time, Cardholder ...). |
| Receipt | Typically cardholders upload receipts to a transaction as the receipt proofs (in a non-structured way) the transaction. It can be replaced as long as the transaction is not immutable |
| Payment | Payments can either be - Bill payments ... which are billed by us and paid by our organizations based on their billing period (daily, weekly, monthly) - Top-ups ... which equals funds being transferred onto the platform that can then be used by the cardholders of the organization to spend money with our cards |
| Account Entry | Account entries are our way to combine all - transactions (money transferred away from the system) - payments (money transferred into the system) |
| Bill | Based on the billing period configured by the customer we create bills (which is basically a credit card statement for all the cards that have been actively used in the given billing period). |
Updated 4 months ago