Bank Transfer On Due Date

Introduction

DJUST supports a bank transfer payment mode called "on due date", designed for B2B scenarios where the buyer pays after shipment, at a contractually agreed payment term.

Unlike a standard bank transfer (on acceptance), where payment must be received before the supplier can ship, the due date mode decouples payment from the logistic order lifecycle. The supplier accepts and ships the order without waiting for funds. The buyer then pays via bank transfer by the computed due date.

This model is common in B2B commerce where trusted buyers operate with deferred payment terms (e.g. 30 days net, 45 days end of month).

✅

Key principle: The due date payment never blocks the logistic order workflow. The supplier can accept, prepare, and ship the order independently of the payment status.

Key Concepts

Payment Modes for Bank Transfer

DJUST supports several bank transfer modes, configured at the customer account level:

The on acceptance and on due date modes are mutually exclusive: a customer account can only have one active at a time. The default mode at account creation is on acceptance.

⚠️

Warning: Only operator admins can change the bank transfer mode on a customer account. Operator users and readers do not have this permission.

Due Date Computation

The due date (payment deadline) is computed from the shipment date of the logistic order, using two parameters configured on the supplier:

Example — SIMPLE mode (30 days):

• Order shipped on July 29
• 29 July + 30 days = August 28
• Due date: August 28

Example — END_OF_MONTH mode (30 days):

• Order shipped on July 29
• 29 July + 30 days = August 28
• Last day of August = August 31
• Due date: August 31

Payment Workflow Status

When an order is placed with BANK_WIRE_ON_DUE_DATE, the platform sets the payment workflow to PAY_ON_DUE_DATE. This status is carried throughout the order lifecycle and signals to all systems that the payment will be deferred.

Typical Workflow

Step-by-step flow

1. Operator configures supplier settings — In the Back Office, set the paymentDueDateDelay and paymentDueDateMode on each supplier that supports due date payments.
2. Operator configures customer account — Enable the due date bank transfer mode on the customer account (instead of the default on acceptance).
3. Customer places an order — The checkout creates a commercial order with paymentOption: BANK_WIRE_ON_DUE_DATE.
4. Supplier accepts the order — The logistic order moves to ACCEPTED_BY_SUPPLIER. No payment is required at this stage.
5. Supplier ships the order — The logistic order moves to SHIPPED. At this point:
   • The due date is computed (shipment date + supplier delay + mode)
   • The PSP is notified that the order is ready for deferred payment
   • The payment status remains WAITING_PAYMENT
6. Customer pays by bank transfer — The customer initiates a bank transfer (typically from an invoice) before the due date.
7. PSP notifies DJUST — The PSP sends a server-to-server notification when funds are received.
8. Reconciliation — DJUST reconciles the incoming payment against the expected order amount.
9. Payment confirmed — The payment status moves to PAID. The logistic order status is unchanged (already SHIPPED or beyond).

End-to-end flow

flowchart LR
    %% Styles (Readme)
    classDef create   fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91;
    classDef read     fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#1e1b4b;
    classDef update   fill:#e0f7fa,stroke:#06b6d4,stroke-width:2px,color:#0c4a6e;
    classDef add      fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
    classDef remove   fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;
    classDef decision fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00;
    classDef place    fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d;
    classDef sys      fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;
    classDef ok       fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
    classDef stop     fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;

    subgraph Config["⚙️ Prerequisites"]
        C1[📘 Configure supplier<br>delay + mode] --> C2[📘 Enable due date<br>on customer account]
    end

    subgraph Order["📦 Order Lifecycle"]
        O1[🆕 Customer places order<br>BANK_WIRE_ON_DUE_DATE] --> O2[✅ Supplier accepts<br>ACCEPTED_BY_SUPPLIER]
        O2 --> O3[📦 Supplier ships<br>SHIPPED]
        O3 --> O4[➡️ PSP notified<br>order ready for payment]
    end

    subgraph Pay["🧾 Payment"]
        P1[💸 Buyer sends<br>bank transfer] --> P2{Reconciliation}
        P2 -->|Match| P3[✅ PAID]
        P2 -->|Partial / No match| P4[⏳ WAITING_PAYMENT]
    end

    C2 --> O1
    O4 --> P1

    C1:::sys
    C2:::sys
    O1:::create
    O2:::update
    O3:::update
    O4:::add
    P1:::create
    P2:::decision
    P3:::ok
    P4:::stop

    style Config rx:10,ry:10
    style Order rx:10,ry:10
    style Pay rx:10,ry:10

Logistic order vs. payment status

Logistic order (independent of payment):

flowchart LR
    classDef create fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91;
    classDef update fill:#e0f7fa,stroke:#06b6d4,stroke-width:2px,color:#0c4a6e;
    classDef place  fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d;

    A[ACCEPTED_BY_SUPPLIER]:::create --> B[SHIPPED]:::update --> C[RECEIVED / CLOSED]:::place

Payment status (progresses separately):

flowchart LR
    classDef sys      fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;
    classDef decision fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00;
    classDef ok       fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
    classDef stop     fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;

    A[WAITING_PAYMENT]:::sys --> B{Reconciliation}:::decision
    B -->|Full amount| C[PAID]:::ok
    B -->|Partial / No match| D[WAITING_PAYMENT]:::stop

✅

Tip: The two tracks (logistic and payment) progress independently. The logistic order can reach RECEIVED or CLOSED while the payment is still in WAITING_PAYMENT.

Configuration

1. Supplier settings (Back Office)

In the Back Office, navigate to the supplier configuration and set the due date parameters:

These settings determine how the due date is computed for every logistic order assigned to this supplier.

⚠️

Warning: If the supplier has no due date settings configured, the platform cannot compute the payment deadline. Ensure these parameters are set before enabling due date payments for customer accounts ordering from this supplier.

2. Customer account settings (Back Office)

On the customer account, set the bank transfer mode to due date (instead of the default "on acceptance").

• Only operator admins can change this setting.
• The modes are mutually exclusive: enabling due date disables on acceptance, and vice versa.
• Default at account creation: on acceptance.

Reconciliation

When the buyer's bank transfer is received, the platform performs automatic reconciliation:

⚠️

Warning: Partial payments do not trigger payment confirmation. Only full (or excess) payments move the order to PAID.

Best Practices

• Configure supplier settings first — Always set paymentDueDateDelay and paymentDueDateMode on the supplier before enabling due date for any customer account.
• Communicate the due date to buyers — The computed due date should appear on invoices generated at shipment time, so the buyer knows the payment deadline.
• Monitor unreconciled transfers — Set up operational processes to review bank transfers that could not be automatically reconciled.
• Use SIMPLE mode for simplicity — SIMPLE mode is easier to predict and communicate. Use END_OF_MONTH only when contractual terms require it.

Common Mistakes

Error Handling

For error codes related to payment operations, refer to the dedicated page: Error / Warning codes