Transactions
A guide to how transactions represent payment lifecycles in DJUST
This documentation provides a complete overview of the Transactions feature in DJUST Pay.
It explains:
- What a transaction represents
- How transactions are structured
- How visibility works across roles and stores
- How platform configuration impacts financial behavior
What is a Transaction in DJUST?
In DJUST, a transaction represents the financial lifecycle of a payment associated with an order.
A transaction acts as a financial container that groups together all events related to a payment.
It is the core object used to:
- Track payment activity
- Monitor financial status
A transaction does not represent a single technical action. It represents the complete financial lifecycle of a payment.
Les transactions sont une fonctionnalité disponible uniquement pour les utilisateurs utilisant DJUST PAY. Les autres PSP ne sont pas concernés par cette feature.
Transactions Architecture
The Transactions feature is structured in three levels:
| Level | View | Purpose |
|---|---|---|
| 1 | Transactions list | Aggregated overview (one row = one transaction) |
| 2 | Events list | Full lifecycle timeline (one row = one event) |
| 3 | Event details | Detailed snapshot of one specific event |
This layered structure allows users to move from:
Monitoring → Investigation → Technical detail
User access & visibility
Transactions are exposed through different views depending on:
- The user role (Operator or Supplier)
- The effective store context (when the environment is configured in multistore mode)
- The platform configuration (Marketplace or E-commerce)
The underlying financial model remains identical for all users. However, the data scope and visibility rules differ.
Store Context
Transactions are always store-contextualized.
Back Office
- Users access transactions within the currently selected store.
- witching store changes the visible dataset.
API
- If dj-store is provided → data is restricted to that store.
- If not provided → data may include all stores the user is authorized for.
Click here to view the API details: Transactions
In a monostore configuration, all transactions are automatically scoped to the single available store, and no store selection is required.
Role-Based Visibility
Operator
- Can access transactions within their authorized store scope.
- In Marketplace mode, can access transactions across all suppliers in that store.
- Has visibility on commission breakdown and supplier data.
- Acts as financial supervisor.
Supplier
- Can access only transactions linked to their own logistic orders.
- Cannot see transactions of other suppliers.
- Has visibility limited to their own financial perimeter.
- Acts as payment monitor for their own sales.
This ensures strict financial isolation while preserving a shared transaction structure.
Platform Configuration Impact
The behavior of transactions differs depending on whether the platform operates in Marketplace or E-commerce mode.
Marketplace Mode**
Operator
- Can access transactions across all suppliers within their authorized store scope.
- Has access to full commission breakdown.
Supplier
- Sees only their own transactions.
- Cannot see data related to other suppliers.
- Sees only the commission and financial data applicable to them.
E-commerce Mode (Single Seller)
- No multi-supplier logic.
- Transactions are linked to a single merchant entity.
- Marketplace commission concepts do not apply.
Operator
- Acts as merchant administrator.
- Has full visibility within store scope.
Updated 11 days ago