The project currently utilizes two payment providers out of five originally integrated. Two providers were completely removed, and one remains as an unused client class in the repository. The system also includes support for cryptocurrency payments, though the client is currently inactive.
To manage diverse payment methods, the system employs a unified interface, InvoiceContract, which standardizes data on payers, products, and net amounts. This approach prevents logic duplication when adding new providers. Financial calculations are handled using integer-based arithmetic to avoid floating-point errors.
Telegram native payments require a specific payload strategy: storing a database record ID rather than user or product IDs. The system must respond to pre_checkout_query requests within 10 seconds. Additionally, the telegramPaymentChargeId must be saved to enable future refunds via the API.
External payment providers communicate via webhooks, which are verified using HMAC signatures calculated from raw request bodies. The system uses hash_equals for secure comparison. Proper error handling is critical: 4xx status codes signal permanent failures, while 5xx codes trigger retries to prevent lost payments.
