Process an online store order's payment only after the current provider amount matches the amount due for that order. A “successful” status alone is insufficient. Also check the provider reference, currency and amount in the smallest currency unit, directly on the server.
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.
Compare whole amounts without floating point
Preferably store and compare money in cents or the relevant smallest currency unit. An order total of € 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.
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.
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.
Determine a safe outcome for each discrepancy
| Observation | Technical response | Administrator action |
|---|---|---|
| Successful status, matching amount | Process payment once | No manual action |
| Successful status, lower amount | Do not automatically mark as paid | Investigate transaction and order |
| Successful status, higher amount | Do not automatically offset the difference | Assess according to the internal process |
| Different currencies | Block as a mismatch | Check configuration |
| Unknown provider reference | Do not link to the order | Review source and logs |
| Payment already processed | No second payment action | Record the repeated message |
“Payment received” is not the same as “fulfilment completed”. WooCommerce's payment flow may process stock and move the order to “Processing” or “Completed”, depending on what still needs delivery. Design warehouse and shipping actions around the appropriate order status, not a general word such as “finished”.
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.
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.
Fictional example: shipping changes during a card payment
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.
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 “technically received” from “resolved in business terms”.
This review state must also remain recognisable in an accounting or ERP integration. Read how a WooCommerce–AFAS integration can be configured around the complete order chain.
Technical checklist
- Compare amounts in the smallest currency unit.
- Always compare the expected and received currencies.
- Link the provider reference to exactly one payment attempt and order.
- If uncertain, retrieve the current status directly from the provider.
- Lock the payment transition against simultaneous polling and webhooks.
- Never let amount discrepancies flow silently into fulfilment.
- Make the review state visible to an authorised administrator role.
- Test payment processing, tax, discounts and changed shipping costs.
Finally, document who investigates discrepancies and what information they need. Good software supplies evidence and blocks an unsafe automatic step; the internal team determines the follow-up process. More about responsibility across the chain appears in reliably integrating an online store and ERP.
Discuss with Yindle how payment checks should work in your integration.