{"id":130,"date":"2026-10-09T09:00:00","date_gmt":"2026-10-09T07:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=130"},"modified":"2026-10-09T09:00:00","modified_gmt":"2026-10-09T07:00:00","slug":"providerbedrag-controleren-orderafronding","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/check-the-provider-amount-before-completing-the-order\/","title":{"rendered":"Check the provider amount before completing the order"},"content":{"rendered":"

Process an online store order's payment only after the current provider amount matches the amount due for that order.<\/strong> A \u201csuccessful\u201d status alone is insufficient. Also check the provider reference, currency and amount in the smallest currency unit, directly on the server.<\/p>\n

This check concerns technical integrity, not accounting advice. Otherwise, an incorrect link between terminal attempt and order, a changed cart or a rounding error can make an order look paid when the received transaction represents something different.<\/p>\n

Compare whole amounts without floating point<\/h2>\n

Preferably store and compare money in cents or the relevant smallest currency unit. An order total of \u20ac 123.45 then becomes 12345. This avoids binary rounding differences with decimal numbers. Record how currencies with a different scale are handled and include that logic in tests.<\/p>\n

Use the current outstanding order amount associated with the payment attempt. An employee must not change lines or shipping unnoticed during an active terminal action. If a change is necessary, cancel the attempt, recalculate the order and deliberately start a new transaction with a new reference.<\/p>\n

Define the check's timing. Check the amount when the provider payment is confirmed, not only when the request is created. Read the order again immediately beforehand, because another process may have changed tax, discount or shipping. Link an attempt to a frozen expected amount and compare it with the current order. A difference between the two already warrants investigation, even before checking the provider.<\/p>\n

Determine a safe outcome for each discrepancy<\/h2>\n
\n\n\n\n\n\n\n\n\n\n\n
Observation<\/th>\nTechnical response<\/th>\nAdministrator action<\/th>\n<\/tr>\n<\/thead>\n
Successful status, matching amount<\/td>\nProcess payment once<\/td>\nNo manual action<\/td>\n<\/tr>\n
Successful status, lower amount<\/td>\nDo not automatically mark as paid<\/td>\nInvestigate transaction and order<\/td>\n<\/tr>\n
Successful status, higher amount<\/td>\nDo not automatically offset the difference<\/td>\nAssess according to the internal process<\/td>\n<\/tr>\n
Different currencies<\/td>\nBlock as a mismatch<\/td>\nCheck configuration<\/td>\n<\/tr>\n
Unknown provider reference<\/td>\nDo not link to the order<\/td>\nReview source and logs<\/td>\n<\/tr>\n
Payment already processed<\/td>\nNo second payment action<\/td>\nRecord the repeated message<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

\u201cPayment received\u201d is not the same as \u201cfulfilment completed\u201d. WooCommerce's payment flow may process stock and move the order to \u201cProcessing\u201d or \u201cCompleted\u201d, depending on what still needs delivery. Design warehouse and shipping actions around the appropriate order status, not a general word such as \u201cfinished\u201d.<\/p>\n

Do not give employees only a cryptic error code. Explain that payment could not automatically be linked to the order and that the order must not be paid again before checking. Retain technical references in secure logs so support can search specifically without copying sensitive payment data.<\/p>\n

Prevent an administrator from hiding the problem with one undocumented status click. A manual follow-up action should record authorisation, reason and time. It then remains visible afterwards that the automatic check was deliberately overridden. Do not have software make tax or financial judgements; it supplies the data the authorised team uses under its own procedure.<\/p>\n

Fictional example: shipping changes during a card payment<\/h2>\n

Showroom Noord starts a card payment for an order of 480 euros. While waiting, a colleague accidentally changes the shipping method, increasing the order total. The provider confirms the original transaction, but the current order expects a different amount. The integration puts the order into a review state and releases no second stock or fulfilment action.<\/p>\n

An administrator sees the provider reference, amount paid and expected order amount side by side. The team then follows its established operational procedure. The software does not decide how to resolve a difference financially; it prevents the discrepancy from becoming invisible. Systems subsequently exchanging order status and payment information can clearly distinguish \u201ctechnically received\u201d from \u201cresolved in business terms\u201d.<\/p>\n

This review state must also remain recognisable in an accounting or ERP integration. Read how a WooCommerce\u2013AFAS integration<\/a> can be configured around the complete order chain.<\/p>\n

Technical checklist<\/h2>\n