Remove MYR base currency check for refunds

[wzul]

What does this change?

This PR implements a major architectural refactor transitioning the CHIP WHMCS module to a "Thin Gateway" architecture and introduces comprehensive multi-currency support.

Core Problem:
Previously, module logic was fragmented across multiple entry points (e.g., chip_cards.php, chip_fpx.php), leading to significant code duplication and maintenance overhead. Furthermore, the module was largely restricted to MYR-only logic, preventing merchants from accepting payments or processing automated refunds for invoices in other currencies without manual intervention.

Technical Solution:

• Thin Gateway Architecture: Centralized core business logic into a single ChipGateway class using the Delegation Pattern. Individual gateway files and callback scripts are now thin wrappers that delegate to this central class, ensuring "DRY" (Don't Repeat Yourself) code.
• Dynamic Multi-Currency Support: Integrated WHMCS's native convertCurrency() across the entire transaction lifecycle.
  • Configuration: chip_config_validate now dynamically fetches available payment methods from the CHIP API based on the "Convert to For Processing" currency setting.
  • Link/Capture: Amounts are converted from the invoice currency to the processing currency before being sent to CHIP.
  • Refunds: Automated refunds now calculate the correct amount to return to CHIP based on the exchange rate at the time of refund.
  • Callbacks: Standardized handling of incoming webhooks to ensure transaction fees and amounts are converted back to the client's base currency for accurate accounting.
• Concurrency & Reliability:
  • Standardized MySQL GET_LOCK naming to chip_payment_$payment_id with a 15-second timeout to prevent race conditions between webhooks and user redirects.
  • Implemented a $0.01 floating-point tolerance check in ChipAction::complete_payment to handle minor rounding discrepancies inherent in currency conversion.
• Modernization & Quality:
  • Enabled declare(strict_types=1) across all core classes (api.php, action.php, gateway.php, exceptions.php).
  • Introduced a custom ChipAPIException and upgraded Guzzle error handling to provide granular feedback for 401 Unauthorized and 404 Not Found statuses.
  • Caching: The CHIP Public Key is now cached in WHMCSSetting to reduce API overhead.
  • CI/CD: Integrated PHP CS Fixer (PSR-12) and established a GitHub Action workflow to automate code style enforcement.
  • Cleaned up deprecated deployment scripts and updated documentation to reflect multi-currency capabilities.

Asana / Jira / Trello task link

How to test

1. Gateway Configuration:
   • Navigate to Setup > Payments > Payment Gateways.
   • Enable a CHIP gateway and set "Convert to For Processing" to a specific currency supported by your CHIP account (e.g., MYR).
   • Save settings and verify that no "Not Servicable" exceptions are thrown during validation.
2. Multi-Currency Checkout:
   • As a client using a currency different from the processing currency (e.g., USD or EUR), attempt to pay an invoice.
   • Verify the redirect to CHIP shows the correctly converted amount in the gateway's processing currency.
3. Callback/Webhook Processing:
   • Complete a transaction and verify the callback updates the invoice status in WHMCS.
   • Review the Gateway Log; ensure the transaction fee and amount are correctly converted from the processing currency back to the client's profile currency.
4. Refund Testing:
   • Initiate an automated refund from the WHMCS invoice admin page.
   • Verify the amount sent to the CHIP API matches the original processing amount (accounting for conversion).
5. Code Standards:
   • Run composer lint locally to ensure no PSR-12 violations.
   • Verify the "PHP CS Fixer" GitHub Action passes on this PR.

Potential Risks & Senior Review Items

• Currency Conversion Math: Please review the logic in ChipGateway::refund and ChipAction::complete_payment. It is critical to verify that exchange rates are applied in the correct direction when moving between invoice_currency and processing_currency.
• Floating Point Delta: The logic abs($payment_amount - $amount) < 0.01 handles standard two-decimal currencies. We should verify if this logic holds for zero-decimal currencies (like JPY) if the merchant's CHIP account supports them.
• Strict Typing & Database Casts: With declare(strict_types=1), verify that results from Capsule queries are explicitly cast where necessary (e.g., (int)$params['convertto'] or (float)$payment['payment']['amount']). Database drivers often return numeric strings which will trigger a TypeError.
• Race Conditions: Review the GET_LOCK implementation in action.php to ensure the lock name is sufficiently unique and the 15-second timeout is appropriate for high-traffic environments.

Is this PR warrant an automatic approval?

No. This PR involves critical changes to financial logic, database-level locking, and core architecture. Manual verification of accounting accuracy and automated refund logic is required before merging.

Images