Discount values for carts ?

Ive been looking at the following API resource for various template_transactions:

https://api.foxycart.com/carts/XXXXXXXXX/discounts

... but because, "discounts are historical records of coupons used in a transaction", as per the Foxy API documentation for discounts I'm guessing we'll never find any "discount" values for template_transactions, correct?

Good question. The discounts URI should list out any coupons that are applied to the cart. If you're viewing template_transactions - I'm assuming you're coming from a subscription - so any discounts shown are coupons that are applied to that subscription.

If you were coming from a transaction, the discounts listed from there would relate to historical information about the coupons that were applied to that order.

I've been looking into this a bit, and I'm not quite sure how or why some subscription templates have coupons displayed as discounts and some do not. My hunch is, it has something to do with if that transaction was ever been modified by the customer directly in the cart via a sub_token. We'll look into this further, but in the mean time I suggest not relying on the discounts but instead look to the applied coupon codes.

I'll look forward to more info on this, because if we can't get the fx:discounts / amount for transaction templates it looks like we'll need to jump through some scary calculations just to get the total discount for the subscription, and the total order amount. For example, we'd have to:

1) Go to the fx:transaction_template2) Get the total_item_price. (hopefully this is consistently applied? -- it seems to be so far)3) Zoom into fx:applied_coupon_codes and if coupon found, then zoom into fx:coupon and find the discount amount by doing some error-prone calculation on coupon values (e.g., incremental|1-20|4-0) by parsing these values and cross referencing the transaction_template fx:items / price and quantity for all applicable line items to calculate the "total discount amount".4) Subtract the "total discount amount" from the total_item_price to get the "total order amount".5) Pray that all this works!

So hopefully, the missing data under fx:discounts is a bug? And maybe it can be fixed so our discount data can be populated for our subscription transaction templates?

------------------------------Also, I'm noticing the fx:transaction_template / total_order is inconsistently applied too, with most orders showing a 0 value. For example:

Hey @Epotratz. Sorry for not responding sooner. I think @fc_adam mentioned having this page open in a tab and it getting lost in the shuffle.

It's possible that you're using the subscription template in ways we haven't really designed it for at this point, and we may have to look into things with more detail on our end to see what can consistently be relied on. For the most part, the subscription template's primary role is to just keep track of which items are part of the subscription which tells the system which categories are involved and how discounts and taxes should be applied. Since all of that can be modified and changed at any time, we don't really rely on those calculated values to be up to date. What matters is at the moment the subscription runs, a copy of that template is used and values are calculated and updated in real time at that moment. I don't think we have things in place currently to update all subscription templates as store settings change over time (coupons removed, category settings changed, etc). Our system just uses it as a template and then figures things out in real time when charging the customer.

So, given then, we'll have to figure out what options we have. One is to show the previous transaction which will be accurate as long as the store settings haven't been modified. The other is for us to look into this deeper and figure out what level of burden we can reasonably take on to ensure the template is kept up-to-date with any and all changes made to coupons, taxes, category discount settings, and the like so that when viewing the template via the hAPI, it will accurately show what will be charged to the customer in the future. I think we do some of this already in our admin, but the hAPI shows more of the raw data as it is, not calculated data.

I'll be discussing this with our team to figure out what makes sense and how we can move forward. Ideally, if the data was just kept up-to-date for you, that would be ideal, but that may not be something we can implement easily or soon.

I can imagine some of the challenges, but I wonder, why even have these fields (i.e., fx:discounts / amount and total_order) available in the Foxy API if they aren't applied consistently? If a developer relied on them, It would certainly lead to problematic API integrations.

If the fx:discounts / amount and total_order were applied consistently, it would solve our issues. Essentially, we just want to see 1) what the customer will pay, and 2) what discount(s) will be applied.

As an aside, we never change our coupon values or category discounts. And if we did, I imagine that we would want the option to NOT update any of the existing subscriptions, since the customer expects to pay a certain fixed price. (FYI, this is the default behavior for Bold Apps Subscription Module for Shopify -- price changes don't affect pre-existing subscriptions)

Unfortunately, we don't have many good answers for you at the moment. The way we handle subscription template transactions is not much different than how we handle carts which is to say it's all pending until the transaction is actually charged (usually through the application front-end interface). What the API is essentially showing is an uncompleted cart which is just a template for creating the new transaction. As far as the raw data is concerned, it's not yet possible to calculate things exactly as they'll be unless you use the sub_token link to pull up the cart in the application and then use the JSON from that. That's not ideal and may come with its own challenges regarding how future subscription taxes, shipping, and discounts are calculated and displayed, but that may be the only option at this point.

We have a ticket to research this further and come up with a solution, but currently, unfortunately, we don't have a good path forward without some fundamental re-work with how we handle date-based orders. The previous transaction may be the best approach for now to show the customer what was charged and the sub_token link with cart=json to get what will be charged in the future.