{"id":66,"date":"2026-10-16T09:00:00","date_gmt":"2026-10-16T07:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=66"},"modified":"2026-10-16T09:00:00","modified_gmt":"2026-10-16T07:00:00","slug":"idempotentie-dubbele-orders-notities-refunds","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/idempotency-in-e-commerce-prevent-duplicate-orders-notes-and-refunds\/","title":{"rendered":"Idempotency in e-commerce: prevent duplicate orders, notes and refunds"},"content":{"rendered":"

Idempotency means the same technical request can be submitted safely multiple times without duplicating the business result. This is essential in e-commerce: webhooks are repeated, network connections fail and confirmation can be missing even though the first action was completed. Without idempotency, duplicate AFAS orders, repeated WooCommerce notes or even multiple refunds can result.<\/p>\n\n

\u201cWe process every message only once\u201d is not a realistic foundation. Design a process in which repetition is normal and traceable instead.<\/p>\n\n

Why messages arrive twice<\/h2>\n\n

A system that receives no timely confirmation after sending cannot be certain the recipient completed the request. Retrying is then sensible. A webhook provider may also resend an event if the response was late. Administrators can additionally restart a failed task manually.<\/p>\n\n

There are therefore two separate questions:<\/p>\n\n

    \n
  1. Have we seen this technical message before?<\/li>\n
  2. Has the desired business result already been achieved?<\/li>\n<\/ol>\n\n

    Answering only the first question is insufficient. A new event may refer to the same order again, while the result must exist only once.<\/p>\n\n

    Choose a stable identity<\/h2>\n\n

    Use a key describing the business result, such as the combination of online store, order number and action type. For a refund, the intended amount or specific return action also belongs to the identity. The key must remain the same on repeated attempts and must not be randomly regenerated.<\/p>\n\n

    Also retain external references. If a WooCommerce order has already received an AFAS sales order number, the integration can check during recovery that the relationship still holds. A visible title or customer name is not a reliable key: it can change and is not necessarily unique.<\/p>\n\n

    Read before writing again<\/h2>\n\n

    Suppose a request to AFAS or Mollie times out. Whether the action completed is unknown. Do not immediately resend the same mutation. First use the stable external identity to check whether the intended result already exists. If the outcome remains uncertain, refer the action to an employee rather than guessing.<\/p>\n\n

    This pattern is also called reconciliation: the integration compares the desired state with the demonstrable current state before deciding the next step. It takes more design work than a simple retry, but prevents financial and administrative harm.<\/p>\n\n

    Different actions need different protection<\/h2>\n\n
    \n \n \n
    Action<\/th>Risk on repetition<\/th>Appropriate protection<\/th><\/tr>\n <\/thead>\n
    Create an AFAS order<\/td>Duplicate sales order<\/td>Check and retain the external order reference<\/td><\/tr>\n
    Add a WooCommerce note<\/td>Cluttered order history and repeated email<\/td>Stable note identity or recognition of the existing outcome<\/td><\/tr>\n
    Set stock to a value<\/td>Old value overwrites new value<\/td>Check version\/order; write an absolute value<\/td><\/tr>\n
    Issue a refund<\/td>Multiple movements of money<\/td>Unique refund request plus provider verification<\/td><\/tr>\n
    Process delivery status<\/td>Reversion to an older status<\/td>Allowed status transitions and event order<\/td><\/tr>\n <\/tbody>\n<\/table><\/figure>\n\n

    Prevent webhook echoes<\/h2>\n\n

    Duplicate processing can also arise from a loop. Connect changes a WooCommerce order, WooCommerce publishes a new webhook event and that event starts the same action again. Mark the origin of changes or recognise the already processed state. Save only when something actually changes.<\/p>\n\n

    That final rule seems small, but matters. An unnecessary \u201csave\u201d can trigger new hooks, notifications and follow-up processes even if the content stayed the same.<\/p>\n\n

    Make retries visible and targeted<\/h2>\n\n

    Administrators need more than a red error and a generic \u201cretry\u201d button. Show the intended business action, which external steps have succeeded and which step can safely run again. A multi-step return may already be recorded in AFAS while only the payment provider still needs checking.<\/p>\n\n

    Use a limit and increasing delay for automatic retries. Permanent input errors do not improve through endless repetition. Pause a task with an understandable recovery reason when mapping, permissions or source data needs changing.<\/p>\n\n

    Test uncertain outcomes in particular<\/h2>\n\n