{"id":133,"date":"2026-10-12T09:00:00","date_gmt":"2026-10-12T07:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=133"},"modified":"2026-10-12T09:00:00","modified_gmt":"2026-10-12T07:00:00","slug":"pin-contant-een-order-modelleren","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/modelling-card-and-cash-on-one-woocommerce-order\/","title":{"rendered":"Modelling card and cash on one WooCommerce order"},"content":{"rendered":"

Model a combination of card and cash as two payment components for one order.<\/strong> Record the amount, method, status and any provider reference for each component. Mark the order as paid only when the sum of confirmed components exactly equals the order amount due.<\/p>\n

Splitting a payment is not a free-text note saying \u201cpart cash\u201d. Such a note cannot be reliably checked, recovered or passed on. The software needs to know which part is already confirmed through the terminal, which part an employee still needs to record and what happens if one half fails.<\/p>\n

Start with a fixed calculation rule<\/h2>\n

Let the employee enter one component and calculate the other on the server as the remaining amount. If an order totals 86.40 and 50.00 is paid by card, the cash component is 36.40. Compare in cents and accept no negative or zero-value components. Recalculate if the order is still allowed to change before payment.<\/p>\n

Define which component comes first too. A terminal payment is external and may enter an unknown intermediate state. Cash requires an employee\u2019s manual confirmation. A clear flow might take the card payment first, then clearly show the remaining cash amount and require deliberate confirmation that it has been received.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Data<\/th>\nCard component<\/th>\nCash component<\/th>\n<\/tr>\n<\/thead>\n
Amount<\/td>\nFixed amount in cents<\/td>\nRemaining amount calculated by the server<\/td>\n<\/tr>\n
Evidence<\/td>\nProvider reference and current status<\/td>\nAuthorised employee and timestamp<\/td>\n<\/tr>\n
Intermediate status<\/td>\nStarted, successful, declined or unknown<\/td>\nAwaiting confirmation or received<\/td>\n<\/tr>\n
Recovery<\/td>\nQuery the provider again<\/td>\nResume the manual step<\/td>\n<\/tr>\n
Transition to paid<\/td>\nOnly when the confirmed sum exactly equals the order total<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

After that transition to paid, a physical order may remain \u201cProcessing\u201d because picking or delivery is still required. Use \u201cCompleted\u201d only when fulfilment is actually finished under the chosen WooCommerce flow. This keeps proof of payment and operational progress as two separate questions.<\/p>\n

Make the intermediate state explicit<\/h2>\n

After a successful card payment but before cash is confirmed, the order is not yet fully paid. Use a distinct, recognisable status and block fulfilment. Show the amount already paid, the remaining amount and the next action. An employee opening the screen later must be able to resume the flow without starting another terminal payment.<\/p>\n

On cancellation, reversing is not automatically the same as deleting. A confirmed provider payment may require a separate reversal procedure; the software should not interpret this independently. It must prevent the order from silently being erased and show the available references to an authorised employee. This article provides technical process guidance, not financial or accounting advice.<\/p>\n

Block substantive order changes once one component has started. An extra product or different shipping changes the total and therefore the remaining amount. If a change is necessary, put the flow into a review state and do not restart automatically. The employee first needs to see which payment has already been externally confirmed and determine how to handle the difference under the internal procedure.<\/p>\n

Fictional example: a showroom customer pays in two parts<\/h2>\n

At home-furnishings store Veldhuis, a customer buys a cabinet. He wants to pay partly by card and the rest in cash. Employee Omar enters 300.00 as the card component. The server calculates the remaining amount and shows both parts before the terminal starts. The card payment succeeds, but the tablet refreshes immediately afterwards.<\/p>\n

When Omar reopens the order, he sees the verified card reference and the outstanding cash step. The \u201cpay by card again\u201d button is unavailable. He counts the cash, confirms receipt using his own account and the order check compares both components with the order total. Only then is the order marked paid.<\/p>\n

The downstream accounting system receives the final order and separate payment information according to the agreed data responsibilities. An integration layer such as Yindle Connect<\/a> can structure these order and exception flows between the online store and business software.<\/p>\n

On the customer confirmation, Veldhuis can summarise the payment methods and amounts clearly without showing technical provider data. More detail remains available in administration for checking. This keeps an internal reference off the receipt while making clear that the customer has not paid twice for the same component.<\/p>\n

Test cases for split payments<\/h2>\n