The G2A Pay Payment Gateway Module processes transactions for sites hosted on ASPnix. This expanded changelog preserves every original entry while adding context on why each change matters for reliability and compatibility. Payment modules must track provider API shifts and platform updates to avoid declined transactions or licensing failures during checkout.

The entries below follow the exact release sequence and content from the original records. Later versions address defects exposed in production use, adopt stronger dependencies, and align with ASPnix platform changes. Running an outdated copy exposes you to known failure modes that these updates explicitly correct.

#Release History

#Version 1.0.6 - Released 10.12.2017

This release fixed the issue with Public Pay payments using the merchant's email address. The defect caused transaction rejection or silent failure when the configured merchant identifier was an email instead of a numeric account value. Correcting the handling logic eliminated the mismatch and restored successful payment completion in all documented merchant configurations.

#Version 1.0.5 - Released 06.18.2017

Updates for the new Public Pay release (June 2018). The module was completely rewritten to be more reliable. It now uses GuzzleHTTP for API requests. The rewrite replaced brittle custom HTTP code with a mature library that correctly manages headers, timeouts, retries, and error responses. This directly reduces intermittent failures when G2A Pay endpoints return transient errors or rate-limit responses.

#Version 1.0.4 - Released 07.10.2017

Updated to work with the ASPnix 2.0 licensing system. Various small improvements. The licensing change was required for correct key validation and module activation on the updated ASPnix platform. Accompanying refinements tightened configuration parsing, improved logging of validation errors, and hardened input sanitization against malformed callback data.

#Version 1.0.0 - Released 08.03.2015

Initial Release. This version established baseline functionality for order creation, payment redirection, and callback verification between the hosted storefront and G2A Pay endpoints. All subsequent releases iterate on this foundation.

#Technical Impact of the Rewrite

The 1.0.5 rewrite produced the largest reliability gain. GuzzleHTTP centralizes request construction, automatically follows appropriate redirects, and throws typed exceptions that the module can map to specific checkout error messages. Earlier versions used file_get_contents or basic cURL calls that lacked consistent timeout enforcement and detailed debug output. After the change, administrators see clearer log entries when troubleshooting declined or timed-out transactions.

The Public Pay update preparation in the same release ensured the module would continue functioning after G2A altered response formats and endpoint paths. Without that work, merchants would have encountered broken checkout flows once the provider completed their June 2018 rollout.

#Common Pitfalls and Mitigation

  • Email-based merchant identifiers trigger the exact defect fixed in 1.0.6; confirm your account settings match the updated handling.
  • Modules older than 1.0.5 lack GuzzleHTTP dependency and will not survive future Public Pay API adjustments.
  • ASPnix 2.0 licensing validation fails silently on 1.0.3 and earlier; update before license renewal to prevent module deactivation.
  • Always clear opcode caches and test a full purchase cycle in sandbox mode after replacing module files.

#Practical Takeaway

Apply the most recent module version that incorporates every fix listed above. Compare your installed files against the 1.0.6 package, verify GuzzleHTTP is present, and confirm ASPnix 2.0 licensing reports valid status. This sequence prevents the known issues documented in the changelog and keeps payment processing stable under normal production load.