How Split Payments Are Handled in MERGEPORT

 

Some platforms, like Wolt and Uber Eats, support split payments.


This means that part of the order is already paid online (e.g. via promotion or voucher), while another part remains open and must be paid at delivery or pickup.

MERGEPORT forwards these payments as separate payment entries to the POS system.

Example Case

Wolt order with total amount:
17.22 €

Breakdown:

• 14.00 € already paid via Wolt promotion
• 3.22 € still open

In this case, MERGEPORT forwards two separate payments:

1. Payment already completed (online payment / coupon / card)
2. Payment still open (e.g. cash on delivery)

This reflects the real financial flow correctly.

Why This Is Not a Discount

The 14.00 € promotion is not a discount from the restaurant’s perspective.

Important:

• The restaurant receives the 14.00 € from Wolt.
• Therefore, it is not a value reduction.
• It is simply a different payment method.

If this were handled as a discount, the restaurant revenue would be reduced incorrectly.

That is why split payments are modeled as multiple payments instead of using the discounts field.

In the order payload, payments are listed inside:

paymentInfo

Example structure:

• One entry with payOnDelivery: true
• One entry with payOnDelivery: false and coupon: true

From the example JSON  :

• 3.22 € marked as CASH, payOnDelivery: true
• 14.00 € marked as CARD, coupon: true, payOnDelivery: false

This clearly separates:

• Amount already settled online
• Amount still to be collected

How POS Systems Should Handle Split Payments

Your POS integration should:

• Read all entries in paymentInfo
• Post already paid amounts as settled payments
• Post remaining amounts as open payments
• Not interpret online-paid portions as discounts
• Not reduce revenue incorrectly

If the POS does not support multiple payments per order, reconciliation issues may occur.

Best Practice

• Always treat promotions handled by the platform as payments, not as discounts
• Ensure your POS supports multiple payment entries
• Reconcile platform settlements with paymentInfo values