Appearance
Place an order from the current cart
POST
/rest/v1/checkout/place-order
Authorizations
bearerAuth
JWT access token obtained from /rest/auth/admin/login or /rest/auth/customer/login
Type
HTTP (bearer)
Request Body
application/json
JSON "transportId": 0, "paymentMethod": "string", "shippingAddress": { }, "billingAddress": { }, "notes": "string", "payway": "string", "returnUrl": "string", "cancelUrl": "string", "redeemPoints": false
{
}
Responses
Order placed successfully. The body always carries orderId, orderSerial and status. Two further keys are OPTIONAL and are OMITTED — not null — when they do not apply, so branch on the key's presence.
paymentRedirect — present for a payway that hands the customer to a gateway. It carries url, method (GET or POST) and params; a POST means the client must build an auto-submitting form rather than navigate.
transactionId (#724) — the gateway's own reference for this payment, when the adapter produced one. The SAME value GET /rest/checkout/payment-status/{orderId} returns under that name. FOR paybybank THIS IS THE BANK PAYMENT CODE AND IT IS THE WHOLE PRODUCT: that payway has no redirect at all, so the order is created PENDING and the customer pays by typing this code into their own banking app. A client that shows a generic success screen without it has placed an order the customer cannot pay, and which the incomplete-order sweep will later cancel. It is returned here because the alternative — reading it back from payment-status — is customer-authenticated, while this endpoint accepts a GUEST with only an email, so a guest could place a PayByBank order and never be able to read its code.
NOT a status discriminator: requiresRedirect on GET /rest/checkout/payment-methods still reports false for both the offline payways and paybybank, which behave completely differently after placement — the offline three land PENDING_ACCEPTED and are done, paybybank lands PENDING and is unpaid. Telling those apart from the picker alone is tracked separately.