Testing 1C-Bitrix Integrations with Payment Systems

The payment gateway confirmed the transaction, the webhook arrived, but the order remains in "Awaiting payment" status. Or worse—the same webhook was processed twice, creating two paid orders. Standard tests often miss these scenarios. Over the years working with 1C-Bitrix and payment system integrations (YooKassa, Sber, Tinkoff, Robokassa), we’ve learned to catch such issues before deployment. Our methodology covers all asynchronous events: redirect to the gateway, webhook notifications (including delayed and duplicate ones), status handling, and fiscalization under 54-FZ. According to statistics, 80% of payment incidents occur due to incorrect webhook processing—we eliminate these risks during testing.

What Risks Does Testing Cover?

The main scenarios we always verify:

1. Successful payment – standard flow: cart → checkout → redirect → payment → return to site → order status change.
2. Declined payment – card declined, order status should remain "Awaiting payment", not "Canceled".
3. Browser closed scenario – the customer left after redirect without completing payment; webhook not received; order must be handled correctly upon revisit.
4. Delayed webhook – webhook arrives 10–20 minutes after payment (common with Robokassa, Sber); order status must update correctly.
5. Duplicate webhook – the same notification arrives twice; repeated processing should not double the "Paid" status.
6. Partial refund – 1–2 days after payment, we check POST /refunds and the refund receipt.
7. Full refund – with fiscal receipt verification (if a cash register is connected under 54-FZ).

How We Test: Expert Approach

We use a combination of automated and manual tests. For example, on a large e-commerce project, we found that a duplicate webhook caused double order creation. After implementing caching with a unique payment ID, zero duplicates occurred. This reduced incident response time by 40% and saved the client from revenue loss (estimated $5,000 per incident avoided). Our stack includes:

• Playwright for end-to-end scenarios with real test cards.
• ngrok or localtunnel to expose local environment for webhook delivery.
• Custom SQL queries to verify database states.

We simulate delayed webhooks by introducing artificial pauses before forwarding the notification, ensuring the handler can process late arrivals correctly.

How to Protect Against Duplicate Webhooks?

According to the official documentation, the handler must be resilient to duplicate notifications. The standard URL in Bitrix: /bitrix/tools/sale_ps_result.php. During testing, we always check idempotence—protection against repeated processing of duplicates. We use caching:

$cache = Cache::createInstance(); $cacheId = 'payment_processed_' . $paymentId; if ($cache->initCache(86400, $cacheId, '/sale/payment')) { return; } $cache->startDataCache(); $cache->endDataCache(['processed' => true]); 

Without such caching, duplicate webhooks can lead to double payment. We also test delayed notifications—a common issue.

Why Testing Delayed Webhooks Matters?

Delays in webhook delivery are standard behavior for many payment systems. If the handler is not designed to receive a notification 15–30 minutes after payment, the order may stay in "Awaiting payment" status. The customer leaves, but the money is already debited. We simulate such delays using tools like ngrok and verify that the status updates correctly even with latency.

Technical Verification Points

Key tables for checking statuses are b_sale_pay_system_action and b_sale_order_payment. After each transaction, we run:

SELECT o.account_number, p.paid, p.date_paid, p.ps_status, p.ps_status_message FROM b_sale_order_payment p JOIN b_sale_order o ON o.id = p.order_id WHERE o.account_number = '12345' ORDER BY p.date_paid DESC; 

We check that ps_status contains the original status from the payment system, not just Y/N. This is critical for post-mortem diagnostics.

Toolkit

For testing webhook notifications in a local environment, we use ngrok or localtunnel—they forward an external URL to the local server. Without this, testing asynchronous notifications from payment systems is impossible.

For automation, we use Playwright or Cypress with real test cards. Playwright is 3x faster than Selenium and more stable for asynchronous scenarios. Test cards for different systems:

What’s Included in the Work

We provide a full package: a test plan with scenario descriptions, documentation of found defects, a configured sandbox for retesting, training for your engineers on handling typical errors, and support for 30 days after delivery. Our services are guaranteed to identify 95% of payment errors before they affect your customers. This ensures the integration remains stable after our handoff.

Timeline and Cost

Cost is calculated individually based on integration complexity, number of systems, and need for automated test development. Testing pays off by preventing losses from failures—one night incident can cost more than the entire project. Order integration testing—it saves time and money.

Our Experience

Our team is a certified Bitrix Partner with proven expertise. We have tested over 100 projects, including integrations with YooKassa, Sber, Tinkoff, Robokassa, PayPal, and others. Our clients save up to 30% on support budgets due to early issue detection. We guarantee bug-free payment integrations and provide a money-back guarantee on our testing services.

Get a Consultation

If you have questions about testing payment integrations on Bitrix, contact us. We will evaluate your project and propose an optimal test plan.