Skip to content

Solve Common Issues

Have you found any problem? don't worry, check out the list of common known issues below, you will most likely find the solution here. Otherwise, go to contact section.

Missing Orders Analysis

Identify and categorize the common scenarios responsible for transaction data loss into solvable integration issues and unavoidable user behaviors.

Solvable Integration Issues

  • Missing Redirection: The payment method does not redirect the user to the final order confirmation page.
  • Non-Standard Controller: The payment method uses a custom controller that does not follow PrestaShop development standards.
  • Missing Hooks: The order confirmation page template fails to display or execute the necessary PrestaShop hooks.

Out of Control Scenarios

  • Premature Closure: The visitor closes the browser window before the order confirmation page loads, preventing the module from sending the purchase event.
  • Ad Blockers: The visitor utilizes an active ad blocker or privacy extension that strictly prevents tracking script execution.

Unavoidable Data Loss Recovery

To recover transactions lost to premature closures or ad blockers, you must configure the tracking module APIs and activate the cron job to ensure automatic server-to-server synchronization.

Payment Gateway Redirection

Verify your gateway settings to ensure users automatically reach the final order confirmation page.

  1. Access your PrestaShop payment module configuration and your external payment provider's dashboard.
  2. Enable the automatic return or auto-redirect feature back to your merchant store.
  3. Verify that the redirection process executes automatically without requiring the user to manually click a return button.

Non-Standard Payment Controllers

Replace or upgrade payment modules that fail to expose standard transaction parameters.

Payment Gateway Compatibility

The tracking module universally supports all payment gateways, provided they adhere their custom controllers to minimum PrestaShop development standards. Ensure your custom payment controller meets at least one of the following development standards to allow the tracking module to fetch the order payload: * The order confirmation URL explicitly contains either the id_cart or id_order parameter. * The controller class exposes a public property named $id_cart, $id_order, or the complete $order object.

  1. Update your current payment module to the latest version to ensure compatibility with recent PrestaShop architecture standards.
  2. Replace the payment module with a compliant, professional alternative if the updated version still utilizes a non-standard custom controller.

Missing Template Hooks

Ensure your active theme and payment modules properly execute the standard PrestaShop display hooks.

  1. Verify within your PrestaShop back office that the tracking module is correctly anchored to the required checkout and order confirmation hooks.
  2. Contact your theme developer or the payment module creator to request specific integration instructions if the standard hooks are not defined within the confirmation template.

Troubleshooting Chain of Responsibility

Isolate the root cause of tracking failures by systematically verifying each link in the data transmission chain.

Strict Sequential Dependency

Data flows in an absolute sequence. If a preceding step fails or is blocked, none of the subsequent processes can execute.

  1. Verify DataLayer Event Generation: Confirm that the PrestaShop module successfully pushes the expected e-commerce event into the browser's data layer.
  2. Verify GTM Execution and Consent: Ensure Google Tag Manager detects the data layer event, reads an active user consent state, and fires the required tag successfully.
  3. Confirm Platform Data Reception: Inspect the destination tracking platform's diagnostic interface to validate that the event payload was received and processed.

Diagnostic Workflow

Perform a complete test transaction to trace the event flow and identify exact integration bottlenecks.

  1. Launch the Tag Assistant Preview mode for either your Client-side or Server-side Google Tag Manager container, depending on your active integration architecture.
  2. Complete a test purchase on your storefront using the problematic payment method and wait for the final order confirmation page to load completely.
  3. Open your browser's Developer Tools (press F12 or Ctrl+Shift+J / Cmd+Option+J) and navigate to the Console tab.
  4. Type dataLayer into the console prompt, press Enter, and search the returned array to confirm the purchase event was generated.
  5. Return to the active Tag Assistant window to verify that Google Tag Manager received the event and fired the corresponding tag with a succeeded status.
  6. Inspect the Tag Assistant Consent tab to ensure the necessary consent signals were granted by the user prior to the event trigger.
  7. Log into your target platform (e.g., Google Analytics 4 Realtime, Meta Events Manager) and check the diagnostic logs to validate final delivery and configuration.

Missing Refunds

Understand the refund synchronization flow and how the module processes order status changes to trigger full or partial refund events.

Uninvoiced Orders

Process full refunds for payment methods that do not automatically generate an invoice, such as bank wire or cash on delivery.

  1. Navigate to the specific order within your PrestaShop back office.

  2. Change the order status to a designated refund state (e.g., "Refunded" or "Canceled").

  3. The module automatically transmits a full refund event and logs the entire order as fully refunded in its internal control table.

Invoiced Orders

Process accurate partial or full refunds for completed orders by issuing PrestaShop credit slips prior to altering the order status.

Credit Slip Prerequisite

You must generate at least one credit slip in PrestaShop before changing the order status. Changing the status without a prior credit slip prevents the module from calculating the refund value.

  1. Open the invoiced order within your PrestaShop back office.

  2. Generate a PrestaShop credit slip specifying the exact products and amounts to be refunded.

  3. Change the overall order status to your designated refund state.

  4. The module automatically reads all pending credit slips, transmits a refund event with the exact combined sum, and marks those specific slips as processed in the control table.

Google Analytics 4 Reporting

Analyze refund data correctly by understanding how Google Analytics 4 processes independent temporal events.

A GA4 refund event does not retroactively modify, deduct from, or erase the original purchase event data.

Date Range Selection

To view accurate net revenue in your reports, your active date range must strictly encompass both the original purchase date and the subsequent refund date.

For example, if a customer makes a purchase on May 1st and you process their refund on May 15th, viewing a GA4 report filtered only from May 1st to May 10th will display the full purchase revenue. You must expand the date range to encompass May 1st through May 15th to see the refund event successfully offset the original purchase.