VirtueMart 4.8.6: Checkout leaves orders without billing details when a customer

[webf]

VirtueMart 4.8.6: Checkout leaves orders without billing details when a customer note contains an emoji; separate payment calculation error

We encountered two database errors during checkout on an existing VirtueMart 4.8.6 installation (build 11642). Both errors occurred on two attempts to place the same order.
1. An emoji in the customer note prevents the billing address from being saved
On our installation, customer_note is defined as VARCHAR(5000) NOT NULL DEFAULT '' with the utf8mb3 character set in both #__virtuemart_order_userinfos and #__virtuemart_userinfos. The installation SQL in the package we inspected uses utf8mb4 for both tables.

To reproduce: On an installation with these legacy column definitions, submit a checkout with an otherwise valid billing address and a note containing U+1F60A (F0 9F 98 8A in UTF-8).

Actual result: MySQL reports Incorrect string value for customer_note on both the insert into #__virtuemart_order_userinfos and the update to #__virtuemart_userinfos. The order header and items are saved, but the billing address is missing. The checkout displays a thank-you heading even though RO Payments cannot proceed and reports The received data has no order ID field.

Expected result: The note and billing address should be saved together. If saving fails, checkout should clearly report the failure and should not leave behind an incomplete order.

Local verification: After converting only the two customer_note columns to utf8mb4, a test through the VirtueMart order model saved the order item, billing address, and emoji correctly. The same emoji could be read back unchanged from both tables. We did not test the browser checkout or payment flow in that run.
2. Payment calculation rule uses -1 in an unsigned column
During both checkout attempts, VirtueMart also tried to insert virtuemart_calc_id = -1 into #__virtuemart_order_calc_rules for a payment without an associated calculation rule. Our live column is INT UNSIGNED, so MySQL reports Out of range value for column 'virtuemart_calc_id'. The installation SQL we inspected defines this column as a signed integer.

Could you confirm whether an upgrade migration is intended to bring these legacy columns in line with the installation schema, and what correction you recommend for existing shops? It would also be helpful to know whether checkout can stop cleanly when saving the billing address fails.

Thank you.

[webf]

3. Cancelling an order without a billing record saves the status but then throws an error
The incomplete orders from issue 1 were still visible in the VirtueMart order list, but opening either order showed an "Order not found" warning. We therefore changed their status to Cancelled (X) directly from the order list.

Actual result: After submitting the status change, VirtueMart displayed the following PHP error:
Attempt to assign property "order_total" on null

A database check confirmed that the cancellation had already been saved: both order headers, all order items, and the latest order history entries were set to X. The error page therefore made a successful status change look as though it had failed.

The latest history entries showed customer_notified = 1, but we could not confirm that an email was sent. In the code we inspected, the history entry is written before notification processing. The error is consistent with VirtueMart trying to prepare the invoice or email view when the billing record is missing.

Expected result: An incomplete order should be cancellable from the order list without a PHP error. If the status change is saved but a notification cannot be prepared, the backend should report those outcomes separately. The history should distinguish a requested notification from one that was actually sent.