Should the order_no field be the Commerce Order No?

My guess is the intent here was to ensure there was a unique order number for each transaction. Sometimes when there's a conflict, a payment gateway will reject the transaction attempt. At the very least, we'll be removing the pre-created Payment entity in 📌 Do not create a Payment entity until a payment has succeeded Fixed , so we won't have the payment uuid in the order number field.

However, if preventing duplication is indeed a requirement, perhaps we're wise to keep the timestamp suffix. We do this in the PayPal module as well. Is it not possible to search via "order number beginning with ______" in the Moneris interface? If not, we can research further to see if it's fine to have multiple transactions with the same order number.

And I guess this is really just a concern in pre-production ... naturally, once you go live, there will be no duplication of order numbers ... so maybe it's a moot point? Or maybe we could just make it a setting in the gateway configuration itself?

Here's a screenshot of an email produced by Moneris.

It just seems to me the Order ID is pretty prominently displayed and a long number like 91-7dc5125d-f510-4258-bd0e-b6694d09d23b-1686219548 isn't very user friendly.

The reference number is Moneris's unique transaction number - i.e. 660160580010200010

Have a look here: https://developer.moneris.com:3000/livedemo/checkout/preload_req/guide/d...

The order_no falls under the optional fields section, I wonder if that is an indication that it's less important than we think.

marchuk.vitaliy → made their first commit to this issue’s fork.

Yes, order_no is not required, but if we omit it, the ticket number part will be used for it.
For example, the ticket number is 1687869483HDYGZqd81ovcDYYopoinQobQpoPYLT, so the order_no will be 1687869483HDYGZqd81ovcDYY which is not very user-friendly.
So I switched to the pattern we usually use in cases like this "order_id-current_time", like 255-1687871631, which looks much better.
Opened MR with the fixes.

Committed!

"order_id-current_time" is more readable but it's not meaningful to the customer or the merchant in our case.

Could we use the pattern "order_no-current_time"?

This change would account for people who are using Number patterns (like us).

@redsky
Unfortunately, we do not have an order number at this time as it is generated when the order is placed (see commerce/modules/order/src/EventSubscriber/OrderNumberSubscriber.php).
Actually, we can generate it for the Draft order, but it will look weird because the order is not placed but has an Order Number.

What's your opinion on this?

@marchukvitaliy,

I see what you mean about it looking weird. If we generated the number early and the payment failed you might be “wasting” the order number.

I feel like it might be the lesser of 2 evils to have the order_no be the most useful.

Do you think we should make this configurable? A checkbox, something like “Generate Order No early to include in Transaction”.

Let me know what you think.

Thanks,
Chris

@redsky
We've never gone that deep or thought too much about order_no. Usually, it's just order_id or order_id-current_time and that's it.
A solution could be to use order_id for Prod and order_id-current_time for Sandbox so in this case for Prod we'll have user-friendly order IDs and for Sandbox we won't have duplicates. Alternatively, we may open a separate issue where we provide users with the option to alter order ID.

@rszrama what is your opinion on this?

I like your idea of not adding time to the order number in Prod.

However that does not solve the issue that the number is prominently displayed to the user in an email receipt and order_no is the number meaningful to the user where as order_id is a surrogate key not known to them. I'd

If you think we should make that user configurable I'm happy to open a new ticket. I just wanted to make sure you've seen the screenshot of the email, and how this number is intended by Moneris to be useful to the user:

Seems like a tricky issue! If this is truly for display purposes only, I don't see a harm in eliminating the timestamp. If we get reports of errors in the future based on colliding order numbers, we can bring the appended timestamp back.

However, the issue with order number generation is a trickier one. Depending on your circumstances, some merchants may be required to maintain sequential order numbers for all placed orders, which would be disrupted by incomplete payments.

I'd be in favor of a payment gateway configuration that allowed the merchant to choose an appropriate strategy. We can always add additional strategies to it in the future.

Type: Radios
Label: Moneris Checkout order number strategy
Options:

• Use the order ID.
• Use the order ID with timestamp appended.
• Generate the order number early and use it instead of the ID.

Help text: Note: generating order numbers will likely result in out of order or missing order numbers based on if / when the orders are placed.

I like that solution @rszrama! +1

@rszrama

I added the fix per comment #15 and merged MR into the 1.x branch.
So, can this issue be marked as fixed?

Thanks for putting your heads together and coming up with this solution! I've tested the "Generate the order number early and use it instead of the ID." strategy and it works great!

Automatically closed - issue fixed for 2 weeks with no activity.