{"id":3259,"date":"2026-10-28T13:13:46","date_gmt":"2026-10-28T03:13:46","guid":{"rendered":"https:\/\/www.gpayments.com\/blog\/?p=3259"},"modified":"2026-10-28T13:13:48","modified_gmt":"2026-10-28T03:13:48","slug":"prevent-duplicate-payments-after-3ds","status":"publish","type":"post","link":"https:\/\/www.gpayments.com\/blog\/article\/prevent-duplicate-payments-after-3ds\/","title":{"rendered":"How to Prevent Duplicate Payments After a 3DS Challenge"},"content":{"rendered":"\n

How to Prevent Duplicate Payments After a 3DS Challenge<\/h1>\n

A customer completes a 3D Secure (3DS) challenge, but the checkout page does not update. They click the payment button again, refresh the browser or return to the merchant’s website.<\/p>\n

If the payment integration treats each action as a new transaction, the customer could be charged more than once.<\/p>\n

Preventing duplicate payments after 3DS requires accurate authentication-result retrieval, payment-state management and appropriate retry controls.<\/strong> Merchants and payment service providers (PSPs) need to distinguish retries of an existing payment from genuine new purchase attempts.<\/p>\n

Why Duplicate Payments Can Occur After 3DS Authentication<\/h2>\n

EMV 3DS handles cardholder authentication. It does not independently manage every part of the merchant’s checkout, payment authorisation or order lifecycle.<\/p>\n

In a challenge flow, the issuer’s Access Control Server (ACS) authenticates the cardholder and communicates the result through the relevant protocol messages. Payment authorisation is a separate process. Problems arise when the merchant’s systems lose track of that separation.<\/p>\n

For example, a customer may complete authentication while the browser loses connectivity before receiving confirmation that the payment succeeded. The merchant’s front end might display an incomplete checkout, even though the payment processor has already accepted the authorisation. Starting another payment without checking the first outcome could create a duplicate charge.<\/p>\n

Distinguishing a Retry From a New Payment<\/h2>\n

Not every repeated request represents a duplicate.<\/p>\n\n\n\n\n\n\n\n\n
Event<\/th>\nRecommended interpretation<\/th>\n<\/tr>\n
Customer refreshes during a challenge<\/td>\nPossible continuation of the existing authentication journey<\/td>\n<\/tr>\n
Browser returns after successful authentication<\/td>\nExisting payment attempt needs its latest state checked<\/td>\n<\/tr>\n
Server retries a request after a network timeout<\/td>\nOriginal processing outcome may be unknown<\/td>\n<\/tr>\n
Customer deliberately starts a second order<\/td>\nPotentially a legitimate new payment<\/td>\n<\/tr>\n
Customer changes the basket and submits again<\/td>\nA materially different payment requiring fresh assessment<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The important distinction is between repeating an operation<\/strong> and starting a new commercial transaction<\/strong>. Repeated 3DS challenge requests may be necessary to recover from an interrupted authentication flow. However, handling duplicate authentication messages does not prevent the merchant’s payment system from submitting duplicate authorisation requests.<\/p>\n

How Authentication Results and Payment Retries Should Be Managed<\/h2>\n

A checkout interruption does not necessarily mean authentication or payment authorisation has failed. Before initiating another attempt, merchants should check the status of the existing transaction.<\/p>\n

GPayments’ ActiveServer documentation<\/a> explains how a 3DS Requestor can retrieve a browser authentication result using the threeDSServerTransID<\/code> through the \/api\/v2\/auth\/brw\/result<\/code> endpoint. This allows the integration to obtain the outcome associated with an existing authentication transaction when that result is available.<\/p>\n

For example:<\/p>\n

    \n
  1. \n

    The merchant initiates a payment that requires 3DS authentication.<\/p>\n<\/li>\n

  2. \n

    The customer completes the authentication challenge, but the checkout loses connectivity before displaying the result.<\/p>\n<\/li>\n

  3. \n

    The merchant’s integration uses the existing threeDSServerTransID<\/code> to request the authentication result from ActiveServer.<\/p>\n<\/li>\n

  4. \n

    If the result is not yet available, the integration follows the appropriate authentication recovery or timeout-handling process rather than immediately initiating a new transaction.<\/p>\n<\/li>\n

  5. \n

    Once the authentication outcome is established, the merchant checks whether payment authorisation has already been submitted and determines the appropriate next action.<\/p>\n<\/li>\n<\/ol>\n

    The merchant should not submit another payment authorisation solely because the browser failed to display a confirmation.<\/p>\n

    Retrieving a 3DS authentication result is not the same as preventing duplicate payment authorisations.<\/strong> Merchants and payment service providers must separately implement payment-state management, retry controls and, where supported, API idempotency to prevent repeated requests from creating duplicate charges.<\/p>\n

    Why Payment Status Should Come From the Server<\/h2>\n

    A browser success page is not a reliable payment ledger. Customers can close tabs, lose connectivity or fail to return from an authentication screen. A missing browser confirmation does not prove that authorisation failed.<\/p>\n

    The merchant’s server should maintain a reliable record of each payment attempt and reconcile its status with the payment processor’s responses, notifications or transaction-status enquiries. When an authorisation outcome is uncertain, the merchant should verify that outcome before submitting another request.<\/p>\n

    A practical design distinguishes states such as payment initiated, authentication required, awaiting result, authorised, declined and cancelled. A pending state must not automatically be treated as a failure that permits another charge.<\/p>\n

    Teams should also test whether repeated notifications or callbacks cause the same fulfilment event to run twice.<\/p>\n

    What Merchants Should Test<\/h2>\n

    Duplicate-payment prevention needs its own testing scenarios:<\/p>\n