You would just need to have a UomConversion between your custom currency (i.e. yourbrand’s reward points) and the underlying order currency uom like USD.
There will need to be some code changes for this to be possible, but with a local UomConversion it should be pretty simple to do.
BTW, I wouldn’t change the price, I would change the payment for the price. When you go to a store and purchase with loyalty points, the price tag in USD doesn’t change.
Thank you so much for sharing your thoughts @michael - your approach makes perfect sense for both checkout and order processing. Here’s how I’m planning to incorporate it:
1. Two Order Items per Order
Rather than changing the product price itself, we’ll represent the cash + points scenario with two order items:
Product item at the full USD price
Discount item where we convert redeemed points to their USD equivalent via our UoM conversion
This keeps the order’s grandTotal in USD and satisfies the requirement that “sum of authorized payments = grandTotal.”
2. Payments and Point Redemptions
Cash payment: We’ll only create a record in the Payment table for the USD portion of the order.
Reward points: The point portion will be handled entirely in the FinancialAccountTrans table, debiting the customer’s loyalty FinAccount by the points redeemed.
3. Displaying Dual Prices in the Storefront
For our product listings and PDPs, we still need to show both:
Current price (e.g. $20.00)
Cash + points price (e.g. $10.00 + 10 pts)
To support this, I plan to introduce a small custom entity, ProductPriceAttribute, to hold the “cash + points” value. I’m open to suggestions if anyone has alternative patterns here!
4. Rewards Points Flow
The rewards points redemption will be fully recorded in our FinancialAccountTrans ledger, ensuring we have a clear audit trail of point balances and redemptions.
Any thoughts on the custom ProductPriceAttribute approach for ecommerce listings would be especially welcome!
Hi @nirendra! This seems like a standard reward points functionality that a lot of ecom stores have. Your 4 points above seem sane, we also handle reward points using a similar flow. Regarding point 3 though, why do you want to show 2 prices in the storefront? I haven’t seen any store do that. Usually they just say 1 point = 1 USD or whatever other value, and the customer then calculates the price depending on how many points he has.
Hi @grozadanut! Thanks for the feedback. In India (and several other markets), showing both cash and points prices side-by-side is actually pretty common in e-commerce. It helps customers immediately see the value of their points and simplifies the checkout decision—marketing teams love it because it drives engagement and retention.
Ah, so it’s a fixed number of points, I see. Well, I don’t think there is support for multiple prices in Moqui at this point, but if a generic solution would be implemented I would also be interested to contribute. In my case I want to show different prices for different UOMs(eg: 10 USD/sqm or 5 USD/piece).
In fact, the data model already supports multiple prices(ProductPrice entity), for example list price, current price, discounted price for volume… So I guess it’s a matter of just UI to show multiple prices on the product page.
For your case though, I don’t think the model supports point based pricing, so I guess you need to handle the points separately, for example in the ProductPriceAttribute as you just described.
Seems like if you want to do multiple currency prices, you would just have one base currency price, and calculate a set value of virtual money based on some percentage of the total price. You could also have a maximum percentage of the product price available to spend via a certain currency (like your points).