Design:
...
{
"0":{
"app":{
"discount":0,
"serviceFeeDiscount":0,
"fee":199,
"serviceFee":100
}
},
"10":{
"app":{
"discount":99,
"serviceFeeDiscount":50,
"fee":199,
"serviceFee":100
}
},
"20":{
"app":{
"discount":199,
"serviceFeeDiscount":100,
"fee":199,
"serviceFee":100
}
}
}
Frontend:
MAXIMUM_POTENTIAL_DISCOUNTSAVING (E.g: 2.99)
...
Dynamic Calculation based on the HIGHER TIER discount + serviceFeeDiscount
Pros: Flexible
Cons: Less autonomy (control) / more complex / new interface impacts
...
:
LOWER TIER (fee + serviceFee ) - HIGHER TIER (fee +serviceFee )
Pros: More flexible.
Cons: More calculations to handle different tiers / more efforts/ new fee interface changes
| Note |
|---|
DMP and Homeria are Delivery fee source of truth. Therefore, LD need to be in sync with them to avoid inconsistences of the information |
THRESHOLD( E.g: 20.00) → We have two optionsPossible solutions:
1-)Calculation based on FF discounted-delivery-threshold-cents
Pros: Existing approach / minimum efforts
Cons: Less flexible/ requires caution when configuring / changing config
2-) Dynamic Calculation based on the HIGHER tier ( service from fee table modal can be reused)
Pros : flexible (recommended)
Cons: Requires more effort to read the higher tier and return it via new field in the interface
AMOUNT_AWAY_FROM_MAXIMUM_DISCOUNTSAVINGS (E.g.: 8.00 ) →
Threshold - (requestedAmountCents OR
(subTotalCents+taxCents)cart price without fees)