Handle additionalCosts
Understanding dynamic cost fields and how to process them correctly
MERGEPORT
Last Update 13 дней назад
The field additionalCosts in MERGEPORT orders contains extra charges applied by the ordering platform.
Important:
additionalCosts is not a predefined enum.
The values are free-text and depend entirely on the respective provider (e.g. Wolt, Lieferando, Uber Eats, Foodora).
This means:
Important:
additionalCosts is not a predefined enum.
The values are free-text and depend entirely on the respective provider (e.g. Wolt, Lieferando, Uber Eats, Foodora).
This means:
- There is no fixed list of possible values
- New values can appear at any time
- Naming may vary slightly between platforms
Example Values
Here are some examples of additionalCosts names observed so far:
Important:
This list is not exhaustive and should not be treated as complete
- Delivery
- Service Fee
- Extra Distance
- Discount Delivery
- Minimum Order Surcharge
- Campaign Surcharge
- Priority Delivery Fee
Important:
This list is not exhaustive and should not be treated as complete
Why There Is No Fixed List
Each platform defines its own pricing structure and naming conventions.
As a result:
Example:
As a result:
- Costs may differ by provider
- Names may change over time
- Similar concepts may use different labels
Example:
- “Service Fee” vs. “ServiceCharge”
- “Delivery Fee” vs. “Delivery”
Recommended Implementation
To ensure a robust integration, your POS or backend should:
1. Handle Known Values Explicitly
If required for UI or business logic, you may map known values:
2. Support Unknown Values Gracefully
Do not assume that all values are known.
Your system should:
3. Apply Light Normalization (Recommended)
We recommend adding a normalization layer, for example:
Example:
Best Practice
1. Handle Known Values Explicitly
If required for UI or business logic, you may map known values:
- Delivery → delivery fee
- Service Fee → service charge
2. Support Unknown Values Gracefully
Do not assume that all values are known.
Your system should:
- Still display or process unknown values
- Not fail or ignore them
- Treat them as generic additional costs
3. Apply Light Normalization (Recommended)
We recommend adding a normalization layer, for example:
- Remove underscores
- Convert camelCase to readable text
- Map similar values to a unified category
Example:
- service_fee → Service Fee
- serviceFee → Service Fee
Best Practice
- Do not hardcode a fixed list of values
- Always process all entries in additionalCosts
- Keep your implementation flexible and forward-compatible
