Order Validation Rules

Every transition from a draft state (DRAFT, DRAFT_ON_HOLD) to a confirmed state (CREATED) — especially when initiating a payment — is subject to strict order validation rules. These checks are essential to prevent inconsistent or invalid orders from reaching suppliers or payment providers.

Scope

Validation is enforced in the following situations:

When calling PAY-101 (Initiate payment)
When explicitly updating an order from DRAFT to CREATED via ORDER-212 or ORDER-220
When putting an order on hold via ORDER-207
When verifying order readiness before starting a Bank Transfer payment process

Only Checkout V2/V3 orders are eligible for validation. Legacy orders in Checkout V1 are not eligible for this validation layer.
The frontend must be prepared to handle multiple simultaneous validation errors and display them clearly by order line.

Order Validate Permission

A dedicated permission ORDER_VALIDATE controls whether a customer user is allowed to leave the checkout phase (i.e. validate, place on hold, or initiate payment for an order).

This permission is distinct from ORDER_VALIDATE_ON_ALL_ACCOUNT, which only controls the scope of orders a user can act on (own orders vs. all account orders).

Behavior matrix

ORDER_VALIDATE	ORDER_VALIDATE_ON_ALL_ACCOUNT	Can validate own orders	Can validate other users' orders
`true`	`false`	Yes	No
`true`	`true`	Yes	Yes
`false`	`false`	No	No
`false`	`true`	No	Yes

⚠️
Warning: When ORDER_VALIDATE is false, the user cannot validate their own orders even if they have ORDER_VALIDATE_ON_ALL_ACCOUNT set to true. In that case, they can only validate orders placed by other users on the same account.

Affected endpoints

All APIs that allow leaving the checkout phase are subject to this permission check:

Validate order — PUT /v1/shop/commercial-orders/{orderCommercialId}/created (ORDER-212)
Put order on hold — PUT /v1/shop/commercial-orders/{orderCommercialId}/hold (ORDER-207)
Initiate payment — POST /v1/shop/payments (PAY-101)

If the user does not have the ORDER_VALIDATE permission for the targeted order, these endpoints return 403 with error code F-E-030.

✅
Tip: By default, all customer users have ORDER_VALIDATE set to true, preserving backward compatibility. Operators can revoke this right via user group management to enforce supervisory workflows where orders must be reviewed by a different user before being confirmed.

⚙️ Validation Logic

✅ If validation is successful:

The order transitions to CREATED
Payment-related workflows (Bank Transfer, Credit Card, etc.) are allowed to proceed
Logistic order pricing and status updates are triggered where applicable

❌ If validation fails:

An error response is returned immediately
The frontend must display detailed line-level feedback to the customer
No payment can be initiated and the order remains unchanged

🛑 Validation Errors

🔐 Authentication & Authorization

The ORDER_VALIDATE right controls whether a customer user can exit the checkout phase. When ORDER_VALIDATE is false, the user cannot validate their own orders — even if they hold ORDER_VALIDATE_ON_ALL_ACCOUNT, they may only validate orders belonging to other users in the same account, never their own.

This check applies to all actions that transition an order out of DRAFT:

Placing the order via ORDER-212
Putting the order on hold via ORDER-207
Initiating a payment via PAY-101

Code	Message
`OR0026`	Access denied - The user does not have permission to validate the order
`F-E-030`	Access denied - The user does not have access to the order or lacks the required role

📦 Order Existence

Code	Message
`OR0001`	Commercial order not found
`OR0002`	Logistic order not found

🔄 Status Constraints

Code	Message
`OR0020`	Cannot update the order to `CREATED` - current status is already beyond `CREATED`
`OR0033`	The commercial order has already been validated

🏷️ Delivery & Billing Information

Code	Message
`OR0014`	Shipping address is missing
`OR0015`	Billing address is missing
`OR0016`	Shipping type is missing

📏 Order Content Validation

Code	Message
`OR0028`	Invalid order - reasons may include: Inactive offer (inventory or price) / supplier / product /variant Invalid quantity Insufficient stock Quantity constraints (min, max, pack size mismatch)

Code

Message

OR0028

Invalid order - reasons may include:

Inactive offer (inventory or price) / supplier / product /variant
Invalid quantity
Insufficient stock
Quantity constraints (min, max, pack size mismatch)

💳 Payment Eligibility

Code	Message
`OR0023`	No payment provider configured and non-payment orders are not allowed
`OR0001`	Invalid payment option (e.g. `BANK_WIRE_ON_DUE_DATE`) for this customer account

❗ Other Errors

Code	Message
`OR0022`	Cannot initialize order - the cart contains no items
`OR0005`	Failed to calculate logistic item prices

🔁 Post-Validation Workflows

If the validation is successful:

Payment processing or logistic confirmation may continue

If the validation fails:

No downstream action (payment/logistics) is triggered
The user is required to correct the issues and resubmit

Order Validation Rules

Scope

Order Validate Permission

Warning: When `ORDER_VALIDATE` is `false`, the user cannot validate their own orders even if they have `ORDER_VALIDATE_ON_ALL_ACCOUNT` set to `true`. In that case, they can only validate orders placed by other users on the same account.

Tip: By default, all customer users have `ORDER_VALIDATE` set to `true`, preserving backward compatibility. Operators can revoke this right via user group management to enforce supervisory workflows where orders must be reviewed by a different user before being confirmed.

⚙️ Validation Logic

🛑 Validation Errors

🔐 Authentication & Authorization

📦 Order Existence

🔄 Status Constraints

🏷️ Delivery & Billing Information

📏 Order Content Validation

💳 Payment Eligibility

❗ Other Errors

🔁 Post-Validation Workflows

Scope

Order Validate Permission

Warning: When ORDER_VALIDATE is false, the user cannot validate their own orders even if they have ORDER_VALIDATE_ON_ALL_ACCOUNT set to true. In that case, they can only validate orders placed by other users on the same account.

Tip: By default, all customer users have ORDER_VALIDATE set to true, preserving backward compatibility. Operators can revoke this right via user group management to enforce supervisory workflows where orders must be reviewed by a different user before being confirmed.

⚙️ Validation Logic

🛑 Validation Errors

🔐 Authentication & Authorization

📦 Order Existence

🔄 Status Constraints

🏷️ Delivery & Billing Information

📏 Order Content Validation

💳 Payment Eligibility

❗ Other Errors

🔁 Post-Validation Workflows

Warning: When `ORDER_VALIDATE` is `false`, the user cannot validate their own orders even if they have `ORDER_VALIDATE_ON_ALL_ACCOUNT` set to `true`. In that case, they can only validate orders placed by other users on the same account.

Tip: By default, all customer users have `ORDER_VALIDATE` set to `true`, preserving backward compatibility. Operators can revoke this right via user group management to enforce supervisory workflows where orders must be reviewed by a different user before being confirmed.