Testing 1C-Bitrix integrations with payment systems

Testing 1C-Bitrix Integrations with Payment Systems

Payment integration is one of the most painful areas in a Bitrix-based e-commerce project. A failure here means direct financial losses: money has been charged, the order was not created, the customer is panicking. Testing payment handlers is fundamentally different from testing regular functionality — you cannot just "click a button and see what happens". The full transaction lifecycle must be reproduced, including asynchronous events and failure scenarios.

What to Test and How

Before running tests, deploy the project with valid test credentials for the payment system. Most aggregators (YooKassa, Sber, Tinkoff, Robokassa) provide a sandbox environment with a separate shopId and secretKey. These are entered in the payment system settings: Store → Payment Systems → {System} → Settings.

Scenarios that must be tested:

1. Successful payment — standard flow: cart → checkout → redirect → payment → return to site → order status change
2. Declined payment — card declined; order status must remain "Awaiting payment", not "Cancelled"
3. "Closed browser" scenario — buyer left after redirect without completing payment; webhook was not received; order must be handled correctly on next visit
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; reprocessing must not double the "Paid" status
6. Partial refund — 1–2 days after payment, verify POST /refunds and the refund receipt
7. Full refund — with verification of the fiscal receipt (if a cash register is connected under fiscal law)

Technical Verification Points

The key tables for checking statuses are b_sale_pay_system_action (handler configuration) and b_sale_order_payment (order payments). After each transaction in a test:

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;

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

The webhook handler is the most vulnerable point. Standard URL in Bitrix: /bitrix/tools/sale_ps_result.php. During testing, always verify:

// Handler idempotency — protection against duplicates
$cache = Cache::createInstance();
$cacheId = 'payment_processed_' . $paymentId;
if ($cache->initCache(86400, $cacheId, '/sale/payment')) {
    return; // Already processed
}
// ... processing logic ...
$cache->startDataCache();
$cache->endDataCache(['processed' => true]);

Tooling

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

For scenario automation — Playwright or Cypress with real test cards. Test cards for different systems:

Timelines