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.

📘

Transactions are a feature available only for merchants using DJUST PAY. Other PSPs are not concerned by this feature.

Transactions Architecture

The Transactions feature is structured in three levels:

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.