Replies: 2 comments 1 reply
-
Another problem with the current one-shot model is that we don't even know which referral fee category an item belongs to (due to variations in sub-categorisation and certain exceptions). |
Beta Was this translation helpful? Give feedback.
-
Agree that this would be a fantastic improvement if we could calculate the fees reliably and correctly after one request for an asin/sku, without having to ping the server again. Bit of a nitpick on the suggested implementation -- money should never be dealt with using floating point. Amazon doesn't seem to understand this, though. |
Beta Was this translation helpful? Give feedback.
-
The Use Case
Trying to show fees based on a variable price, i.e. the user being able to enter a new amount (or dragging a slider) and correct fees to be shown. The Fees API (both GetMyFees and the batched endpoint) currently accepts a certain product and theoretical selling price as input, then spits out the fees based on that theoretical price.
If the price is changed, a new API request is required, and this would be unnecessary if you provided the referral fee structure instead of just a one-shot total. We could save a lot of server hits, bandwidth and round-trip time.
The Idea
Can this please be improved by also returning the following information:
getCatalogItem
orlistCatalogItems
, or possibly by ensuring that it matches up withbrowseClassification
in thesummaries
. This would allow the result to be reusedNote that the current categorisation
Referral Fee Percentage Structure
Example (as a child of
FeesEstimate
) - numbers are fictitious and just to illustrate the idea:The above would mean in English:
"12.5% for the portion of the sales price up to and including 100, and 8% for the portion of the sales price of 100.01 and above."
Example 2:
In English:
"8% on the whole of the sales price for items priced up to and including 15, or 15% on the whole of the sales price for items priced 15.01 and higher."
Example 3:
In English:
"12% flat rate on all products in this category"
Notes:
FeeAmount
object to include the currency.Alternatives
If this can't be included into the existing feesApi returns, another possibility might be to ensure that the referral fee category is returned by the Catalog API, and then making a separate (new) API call just to retrieve the referral fee structure. This could be either for a single category, or even better, a single call to load all referral fees for all categories on the marketplace in question. It could be cached API client-side for the duration of the interaction and no further API calls would be necessary for that duration.
Low-Price FBA Fees
Along similar lines, the new low-price FBA Fees need something similar. That way we don't need 5 requests just to figure out what the fees might be if a user is near the $10 threshold.
Beta Was this translation helpful? Give feedback.
All reactions