H-Script 1.0.8: updated payment gateways, tokens across networks, and stronger financial safeguards
A major H-Script update is ready for release preparation: shared gateway connections, Stripe Checkout, token selection from CryptoCurrencyAPI, separate accounting for network-specific assets, and a redesigned payment page. Financial processing gains stronger checks for retries and concurrent requests, while the Docker build moves to PHP 8.4.27 to address two critical vulnerabilities.
A clearer payment workflow
H-Script has prepared a substantial set of improvements to its financial core, gateway configuration, and account interface. The goal is to make payment setup easier to understand and financial processing more resilient to duplicate notifications, concurrent requests, and interrupted execution. The changes are prepared for inclusion in an upcoming release. Existing installations are updated separately, after the release has been selected and verified.
One gateway, one shared connection
CryptoCurrencyAPI, Volet, PayKassa, and Stripe now have a shared provider connection page. API credentials and the gateway state are managed centrally, while each currency retains its own limits, fees, display precision, and available operations. This reduces duplicated configuration and separates provider access from individual payment methods. Administrators can open the shared connection directly from the currency list and use provider filters to find the relevant entries. The homepage integration count is now calculated from the available catalog: each provider counts as one gateway, regardless of how many currencies it supports.
Stripe and a refreshed integration catalog
Stripe Checkout integration has been added using the official SDK. Payment sessions and signed notifications are matched to the original invoice, amount, and currency. Returning from the payment page does not by itself confirm that funds have arrived. The update also expands Volet currency setup and CryptoCurrencyAPI network support. ePayCore and the obsolete standalone TRONAPI, EtherAPI, XRPAPI, and BNBAPI integrations have been removed from the active catalog. Retiring old connections preserves their associated financial records and history.
A token is more than its symbol
The same token symbol can exist on multiple blockchains and refer to different contracts. The updated model identifies an asset by its currency, network, and contract. For example, USDT on Ethereum and USDT on TRON are represented as separate currencies with their own settings and balances. An invoice already bound to one network does not require another network selection. This helps prevent similarly named assets from being confused and keeps payment details aligned with the original invoice.
Token selection from CryptoCurrencyAPI
On a supported CryptoCurrencyAPI network page, administrators can load the token list directly from the gateway API, search by symbol or contract, and add the tokens they select. Installations no longer need to rely solely on a small, predefined token list. Catalog availability still depends on the network and the provider API; the interface explains when a catalog is unavailable. Newly added currencies start with payment acceptance disabled, giving administrators time to verify the asset, contract, limits, and fees before enabling it.
Network wallets and invoice addresses
Separate settings are available for the wallet that collects incoming funds and the source wallet used for manual payouts. A primary or additional address supported by the connection can be specified for collection, with changes applying to new invoices. Each invoice receives its own payment address for the customer. The manual payout source is shown to the administrator as part of the payment details. Configuring this source does not enable automatic transfers for providers where automated withdrawals are not implemented.
An updated payment page
Payment details now appear in a dedicated card with a prominent network label, address, amount, copy buttons, and an address QR code. The page tracks invoice status automatically using received payment notifications and redirects the customer to the account dashboard after crediting. Confirmation information is displayed when the provider supplies it. The payment, cancellation, and status-check buttons follow a more consistent layout. Manual confirmation in the administration area is organized into clearer sections for reviewing payment details and choosing an action.
Stronger financial processing
Key financial calculation paths now use decimal arithmetic with explicit validation of amounts, fees, and precision. Duplicate request and notification handling has been strengthened so that receiving the same confirmed event again does not issue another credit. Additional checks bind processing to the original operation, validate state transitions, and apply current execution policies. Registration bonuses and referral rewards are more tightly linked to their source events and protected against repeated issuance. Critical registration and confirmation steps now share a transaction boundary.
Testing concurrent requests and failures
The financial changes underwent independent review and automated testing on MySQL 8.4, MariaDB 10.11, and MariaDB 11.4. Scenarios cover concurrent requests, repeated notifications, SQL failures, transaction rollback, recovery after an application restart, and reconciliation of the resulting records. The interface was tested in Chromium and WebKit, including mobile layouts. These checks complement provider-specific testing: a merchant connection still needs to be verified in the chosen provider's test environment before live payment acceptance is enabled.
PHP 8.4.27 and external resources
The Docker build now uses PHP 8.4.27. This release fixes CVE-2026-109618 and CVE-2026-109619, covered by the PHP team's security advisory published on October 21, 2026. Existing containers must be rebuilt and redeployed to receive the runtime fixes. On conventional hosting, PHP must be updated by the server administrator or hosting provider. Interface fonts and icons are served locally, and unconditional permissions for external resource loading have been reduced. Exceptions for configured external services take their enabled state into account.
Everyday interface improvements
Pinned menu entries are stored in account preferences and remain available after signing in again. Operation history filters and pagination styling have been corrected. Opening a new FAQ item closes the previous one. Security settings use a more consistent layout, while gateway, network, and currency states are highlighted with separate badges. Connection pages now use the full content width, and currency settings are visually distinguished from network wallet settings.
PAW Payments and partner programs
PAW now has prepared forms for shared connection setup, accounting-currency selection, and ordinary per-currency settings. The PAW and CryptoCurrencyAPI panels include H-Script partner links and explain the manual cashback process. Cashback is paid after transactions are reconciled with the relevant provider; it is not credited automatically to the website's balance.
Before updating an installation
For an existing installation, retain a verified backup, deploy the selected release, and apply the required database updates through the Configurator's normal update mechanism. Re-running the initial installer is not a migration method for an existing database. After updating, review gateway credentials and modes, currencies, networks, token contracts, and payment details. Enable acceptance only after verifying the selected method in the provider's test environment. Updating the PHP container and migrating the database schema are separate steps.