Design:
Backend:
{
"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_SAVING (E.g: 2.99) → Possible solutions:
1-) Semi Dynamic Calculation based on the HIGHER TIER (discount + serviceFeeDiscount)
Pros: Flexible, marketing configuration freedom to explore saving values (A/B testings)
Cons: requires some manual configuration / new fee interface changes
2-)Totally Dynamic Calculation based on the HIGHER TIER (fee + serviceFee) - LOWER TIER (fee +serviceFee) -
Pros: More flexible.
Cons: More calculations to handle different tiers / more efforts/ new fee interface changes
This calculation uses maximum delivery fee (higher tier) as reference. The source of this truth is DMP/Homeria. There are chances to generate inconsistences due to misconfiguration and this solution is not subject to the dynamism of delivery fee configuration/evolution. One alternative is to call quotation process for the higher tier.
THRESHOLD( E.g: 20.00) → Possible 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
Cons: Requires more effort to read the higher tier
AMOUNT_AWAY_FROM_MAXIMUM_SAVINGS (E.g.: 8.00 ) →
Threshold - (requestedAmountCents OR
(subTotalCents+taxCents))
0 Comments