Handle additionalCosts
Understanding dynamic cost fields and how to process them correctly
MERGEPORT
Last Update 2 months ago
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
