Если представить стоимость отдельного заказа (в копейках) в 2-ричной системе счисления (набор бит) и каждый заказ должен устанавливать только свой бит (брать младшие биты, установив остальные в 0), то сумма этих чисел в младших разрядах будет аналогично битовой операции OR, т.е. по итоговой сумме можно будет однозначно понять, какой заказ был включен в нее.
После получения платежки мы получим в сумме в младших битах те заказы - что оплачены, и для последующих заказов берем эти освободившиеся битовые позиции.
Пример, берем младшие 4 бита для адреса (возможность одновременно быть в обработке 4-ем заказам)
1 - 10110001 цена 177р
2 - 01100010 цена 98р
3 - 11110100 цена 244р
4 - 00011000 цена 24р
если платежка пришла по 3-ем заказам, например 1+2+4 то это даст сумму 299р - 100101011, смотрим на младшие биты, установлены 1,2 и 4
Недостаток, 20 заказов это 2^20 копеек - это разница в цене на 10т.р. (т.е. 20-ый заказ может отличаться по цене от первоначального на эту сумму), так же это накладывает ограничение на минимальную цену заказа (можно подбирать для дешевых заказов младшие биты а для по дороже - по старше.
Логично что это подойдет только если заказов мало, например 2^10 это всего 10.24р
К сожалению если не добавить какого то еще знания о возможностях группировки заказов, то это никак не оптимизировать
