Automated Order Status Change in 1C-Bitrix

Situation: an online store on 1C-Bitrix grows to 200 orders per day, and managers spend 6 hours manually changing statuses: confirming payment, canceling overdue orders, marking as delivered. This increases workload, clients complain about delays, and returns rise 20% due to missed notifications. We automate status changes turnkey—from a simple event on payment to full integration with transport companies and business processes. Our approach reduces manual intervention by 70% and significantly saves on manager FTE budget. We have been automating Bitrix for over 5 years and have delivered projects for 50+ stores.

How Automated Order Status Change Works

The system reacts to key events in the order lifecycle. Let's look at three main approaches.

Auto-Status Change on Payment

The event OnSalePaymentPaid fires when the payment module marks payment as completed—both when a manager confirms manually and via automatic IPN from a payment system (e.g., YooKassa or Sber):

AddEventHandler('sale', 'OnSalePaymentPaid', function(\Bitrix\Main\Event $event) { $payment = $event->getParameter('ENTITY'); $order = $payment->getOrder(); if ($payment->isPaid() && $order->getField('STATUS_ID') === 'WAIT_PREPAY') { $order->setField('STATUS_ID', 'F'); $order->save(); } }); 

Auto-Cancellation After Timeout

Implemented via a Bitrix agent that runs on a schedule and checks unpaid orders. A limit of 50 orders per iteration prevents timeouts with large accumulated volume:

// Register agent (once) \CAgent::AddAgent( 'Local\\Sale\\OrderAgents::cancelUnpaidOrders();', 'local', 'N', 3600, // every hour '', 'Y', \ConvertTimeStamp(time() + 3600, 'FULL'), ); class OrderAgents { public static function cancelUnpaidOrders(): string { $deadline = new \Bitrix\Main\Type\DateTime(); $deadline->add('-24 hours'); $result = \Bitrix\Sale\Internals\OrderTable::getList([ 'filter' => [ 'STATUS_ID' => 'WAIT_PREPAY', '<DATE_INSERT' => $deadline, ], 'select' => ['ID'], 'limit' => 50, ]); while ($row = $result->fetch()) { $order = \Bitrix\Sale\Order::load($row['ID']); if ($order) { $order->setField('STATUS_ID', 'CANCEL'); $order->save(); } } return 'Local\\Sale\\OrderAgents::cancelUnpaidOrders();'; } } 

Automation via Business Processes

For complex chains with conditions and delays—use Sale business processes (Shop → Order Business Processes). Available triggers:

• By status—triggered on entering a specific status
• By payment—on payment confirmation or refund
• By time—after N hours/days from creation or status change

Example: "2 hours after moving to 'Handed to courier'—send SMS with rating request." Implemented without code via the BP designer.

Why Automate Status Changes?

Beyond time savings, automation reduces the risk of human factor errors (missed payment, forgotten cancellation) and improves user experience—clients receive up-to-date information without delays. Our clients report a 70% reduction in order processing time and a 15% decrease in returns due to timely notifications. For simple scenarios, agents process orders twice as fast as business processes, but BP is more convenient for complex logic.

Which Approach: Agents or Business Processes?

Which Events Are Used for Auto-Status Change?

Typical scenarios and triggers are summarized in the table:

More details on the OnSalePaymentPaid event are in official documentation. Automation in general is described on Wikipedia.

Work Process

1. Analysis—study current statuses, scenarios, 1C exchange logic.
2. Design—select approach (events/agents/BP) for each scenario.
3. Implementation—write code or configure BP, test on a sample order.
4. Test—run all scenarios (payment, cancellation, delivery) in a staging environment.
5. Deploy—move to production, monitor logs for the first 24 hours.

Deliverables

• Creation of local/php_interface/init.php with event handlers (if needed).
• Configuration of agents with specified periodicity.
• Business process setup (if required) via admin panel.
• Integration with transport company webhook (e.g., CDEK API or Russian Post API).
• Documentation: description of all automatic transitions.
• Access to git repository with code.
• Administrator training (1 hour).
• 14-day guarantee on script correct operation.

A typical mistake when integrating a transport company: if the webhook sends a status not present in the mapping, the order remains unchanged. Solution: log unknown statuses and notify the administrator.

Integration with Transport Company Statuses

// Webhook from TC — POST /bitrix/tools/delivery_webhook.php $trackNumber = $_POST['track']; $deliveryStatus = $_POST['status']; $shipmentResult = \Bitrix\Sale\Internals\ShipmentTable::getList([ 'filter' => ['TRACKING_NUMBER' => $trackNumber], 'select' => ['ORDER_ID'], ]); if ($shipment = $shipmentResult->fetch()) { $order = \Bitrix\Sale\Order::load($shipment['ORDER_ID']); $statusMap = ['delivered' => 'D', 'returned' => 'RETURN_INIT', 'lost' => 'PROBLEM']; $newStatus = $statusMap[$deliveryStatus] ?? null; if ($newStatus && $order) { $order->setField('STATUS_ID', $newStatus); $order->save(); } } 

Auto-Completion of Delivered Orders

Moving to "Closed" 14 days after delivery without complaints:

public static function completeDeliveredOrders(): string { $deadline = new \Bitrix\Main\Type\DateTime(); $deadline->add('-14 days'); $result = \Bitrix\Sale\Internals\OrderTable::getList([ 'filter' => ['STATUS_ID' => 'D', '<DATE_STATUS' => $deadline], 'select' => ['ID'], 'limit' => 100, ]); while ($row = $result->fetch()) { $order = \Bitrix\Sale\Order::load($row['ID']); if ($order) { $order->setField('STATUS_ID', 'CLOSED'); $order->save(); } } return 'Local\\Sale\\OrderAgents::completeDeliveredOrders();'; } 

Timeframes

Auto-status change on payment and one auto-cancellation agent—3–5 hours. Full automation with TC integration, business processes, and multiple agents—1–3 working days. We will assess your project for free—contact us for an audit. Order the setup and receive a ready solution with a 14-day guarantee.