Setting Up Installment Checkout in 1C-Bitrix

Installment checkout in 1C-Bitrix: where it breaks

Installment checkout in 1C-Bitrix almost always breaks not at the moment the credit module is connected, but at the junction of three subsystems: the cart, the payment gateway, and the exchange with 1C.

The cart lives in the session and stores the order contents, the credit module forms an application on the bank's side, and the application status must return back to Bitrix and travel to 1C.

As long as these three loops are in sync, everything works; if one of them lags by a single step, the order "hangs" in an undefined state.

The most common failure is a desync between the cart and the credit module. The user changes the order contents or the delivery method after the application has already gone to the bank, and the amount in the credit decision stops matching the amount in the cart.

If editing is not blocked at this step, the order goes to 1C with one amount while the bank confirms another — the discrepancy surfaces at the shipping stage.

The second class of problems is the loss of the application status when returning from the payment gateway.

The client closes the tab, loses the session, or returns via an old link, and the handler does not receive the bank's response: the application remains in the "processing" status even though the decision has already been made.

This is cured by an idempotent handler and scheduled status reconciliation, not only by the user's return.

The third failure is duplicate orders. A double click on the confirmation button, a repeated handler call, or a redirect from the gateway creates two orders for one application, and both arrive in 1C.

The protection is a unique application key on the Bitrix side and a check before creating the entity. We break down how this is closed at the level of the exchange architecture.

What correct installment integration delivers

The key effect of correct integration is not a "installment button on the page," but an end-to-end scenario where the loan application and order placement live in a single flow.

When the bank module receives cart data directly from the order, the customer does not need to re-enter the contents of the purchase and the amount — checkout time is reduced from several minutes to tens of seconds, and the share of abandoned carts at the payment step drops severalfold.

It is precisely at this step that most of those who have already reached checkout and are mentally ready to buy are lost.

A separate loss point is the return from the payment page. If the bank declined the application or the customer changed their mind, with a naive integration the cart is reset and the order is lost: the person returns to an empty site and leaves.

With proper handling of the return status, the cart contents, the selected delivery method, and the applied discounts are preserved, and the customer is immediately offered an alternative — a different program, a smaller down payment, or regular payment.

This moves a rejection from the "lost customer" class into the "retry" class, and the share of approved applications grows because the system itself selects suitable terms instead of a single rigid option.

Checkout conversion is also directly affected by how the module communicates with the bank at the moment of placement.

A synchronous request with a wait for a response hangs the page and provokes repeated clicks; an asynchronous scheme with clear states — "application sent," "decision made," "clarification needed" — keeps the customer informed and prevents them from closing the tab.

Logging of every step and idempotency of operations protect against duplicate orders and duplicate applications when the connection drops.

In total, this yields a predictable funnel: fewer abandoned carts, a shorter path to payment, a higher share of approved applications, and a manageable return from the payment page instead of an irretrievable loss of the customer.

Installment connection options: comparison of approaches

The choice of how to connect installments determines how flexibly you can manage the terms and how quickly the order will be processed.

The built-in module covers the typical "approve and process" scenario without modifications, the payment gateway provides ready-made bank scenarios and limits, and a custom handler is needed where the approval logic is tied to your customer and inventory data.

In practice, approaches are most often combined: the built-in module or gateway handles payment processing, while the custom handler handles customer verification and calculation of the available amount. This provides predictable order processing and control over declines at every step.

Stages of implementing installments into checkout

The work goes from auditing the current checkout to handover for operation: first we establish how an order is placed now, then we design the installment scheme, and only after that do we touch the code.

This order eliminates rework halfway through — each subsequent stage relies on an agreed-upon scheme rather than guesswork.

1. Checkout audit. We analyze the cart, the checkout steps, delivery and payment methods, and the rules for calculating discounts and promo codes. Separately, we look at where amounts are stored in the order and how they are passed to the accounting system — this determines where installments will be integrated.
2. Interaction scheme. We agree on how installments combine with payment, delivery, and order statuses: which payment method appears in checkout, what happens to the amount when the order is sent to the accounting system, and how the installment flag gets there.
3. Module setup. We connect and configure the module according to the agreed scheme: terms, available periods, limits on amount and products, access rights. We set up the exchange so that installment data is correctly reflected in the order and in accounting.
4. Scenario testing. We run through the full customer journey: checkout with installments, partial refund, order cancellation, repeated payment attempt, order with a promo code. We also check the reverse side — the correctness of statuses and amounts in the accounting system after each scenario.
5. Handover for operation. We finalize the settings, describe the change management procedure, and hand over instructions for standard operations to the customer's team. After launch, we remain on support — adjustments to terms and incident resolution follow a clear process.

Each stage ends with approval, so at the output the customer gets working installments in checkout and a transparent procedure for its ongoing support.

What the client receives after setup

Setting up installments is not just an enabled module, but also a set of artifacts that the system lives and evolves by after handover. Below is what remains with your team in a closed form.

• Module configurations: working installment profiles for each payment method, binding to product groups and customer categories, order amount threshold settings. Everything is placed in separate profiles — a new scenario is added by copying, without modifying the core.
• Data flow diagrams: how an installment application passes from the cart to confirmation — which fields go to the credit module, what comes back, where the status is stored. The diagram removes the question "why is the order stuck" in minutes, not hours of log analysis.
• Access policies: separation of roles for the manager, operator, and administrator — who sees personal data, who changes installment terms, who confirms the application. Permissions are described explicitly, not "by default for everyone."
• Application processing regulations: what to do when the credit module declines, how to handle stuck applications, at what point the order is switched to payment, to whom a disputed case is escalated. The regulation covers typical situations without calling a developer.
• Instructions for managers: step-by-step scenarios in the administrator interface — how to check the status, how to resend an application, how to contact the customer. Written for real screens, not abstractly.
• Integration map: a list of external services involved in installments, with failure points and system behavior when each is unavailable. Helps distinguish a failure on our side from a partner's failure.
• Change log and rollback points: what and when changed in the configuration, how to return to the previous state. Rollback takes minutes, not hours of recovery from a backup.

Each artifact is delivered in your environment — with access for the team and the ability to edit without us. Describe the task — we will come back with an estimate and a plan for your installment scenario.

Case study: how installment plans stopped losing applications

The client — a chain of electronics stores — accepted installment applications through a form on the website, and a manager made the decision on each one manually: verified the client's data against the database, checked the limit, and transferred the status to the accounting system.

At a volume of several hundred requests per month, some applications got stuck between stages: the client received no answer, and the manager did not see the stalled deal. The share of lost applications reached 18%, and manual reconciliations took 3-4 hours a day.

We broke down the application journey step by step and found the bottlenecks: the status changed only after a manual action, and some applications never even reached the accounting system due to a desync between forms and reference data.

We rewrote the application flow so that each application received a status automatically on entry, and the installment decision was pulled from the accounting system without the manager's involvement.

We replaced reconciliations with automatic status transfer — the manager sees only those applications that require their decision.

What changed in numbers

After implementation, the share of lost applications fell from 18% to 2% — the remaining cases are applications with incomplete data, which the system flags and returns to the client for completion.

Time spent on manual reconciliations dropped from 3-4 hours to 20-30 minutes a day: the manager handles only exceptions. Rejections at the application stage nearly halved — the client receives an installment decision within a minute instead of waiting for a call.

We separately addressed the issue of stalled deals: if an application does not receive a status within the allotted time, the system moves it to a separate queue and notifies the person responsible. Previously, such cases were found only during the monthly reconciliation; now — on the same day.

The project was led by our integration engineer, working on 1C-Bitrix with data exchange through the accounting system's built-in module.

We described the status logic and exception handling rules in a regulation so that support could change installment terms without editing code.

How is installment payment different from a loan at checkout?

From the checkout's point of view, these are two different payment modes with their own verification logic, not "one button with different labels." An installment plan is an agreement with a partner bank or the store's own program: the payment is split into equal parts, and the decision is made based on a simplified set of data — usually a passport, a phone, and confirmation via a code is enough.

A loan is a separate credit product: the bank requests income, employment, and credit history, and approval arrives asynchronously and not always at the moment the order is placed.

Different verification logic dictates different data requirements. For an installment plan, it's enough to pass the amount, the number of payments, the cart contents, and the customer ID to the payment module — the bank calculates the rest itself.

For a loan, you need to collect an extended application form, correctly pass it to the bank gateway, and handle a delayed response: the order may sit in an "awaiting decision" status, and the checkout must display this rather than lose the cart.

If the data is incomplete or doesn't match the user's profile, the bank will return a rejection — and the rejection scenario must be planned for in advance, otherwise the customer will simply leave.

Refund scenarios also differ. With an installment plan, the store initiates the product return, the bank recalculates the payment schedule, and the already-paid portion is returned to the customer — it's important that the order status and the agreement status are synchronized.

With a loan, the refund goes through the bank: the store confirms the return, the bank closes the agreement, and only after that is the obligation released. If this chain isn't automated, accounting will have to sort out discrepancies manually.

In practice, both modes live in a single checkout, but as separate checkout branches: different forms, different bank response handlers, different order statuses, and different cancellation rules.

We separate them at the logic level, not cosmetically — that way approval, rejection, and refund all work predictably. Describe your payment scheme — we'll come back with an estimate and an integration plan.

Technical concerns when integrating installment payments

Before integrating installment payments, the same technical questions almost always come up: will the new module break the current order logic, what happens if the bank declines the application, will the solution survive a platform update, and will the load on checkout increase. Below are short answers to each.

What happens if the bank declines the application or does not respond?

The order is not lost and does not hang in an undefined status. If the bank declines the application, the customer sees a clear message and can choose another payment method, while the order remains in the system with a correct status.

If the bank does not respond in time, the application is marked as incomplete, and resubmitting does not create a duplicate order.

Will the solution survive a platform update?

Yes, if the integration is built on standard mechanisms rather than core modifications. We do not touch system files — all changes are placed in a separate module and settings, so a platform update does not overwrite the installment payment logic. After major updates, we check that checkout works and adjust the integration if necessary.

Will the load on the site increase during checkout?

The load increases only slightly: a request to the bank is sent once when the application is confirmed, not at every step. The main work happens on the bank's side; the site only transmits data and receives the result.

During peak sales, checkout remains responsive — if necessary, we move the exchange with the bank into a separate queue so it does not affect site speed.

If you still have questions about your configuration, describe your task, and we will get back to you with an estimate and a plan.

Let's discuss your order checkout task

To come back with an accurate estimate and a plan rather than generalities, we need the source data on your store.

Tell us which edition the project runs on — "Small Business" or "Business" — whether the installment module is connected, and which payment methods are already configured. This determines whether we refine the existing scenario or build the order checkout from scratch.

Separately, clarify how the installment option should look for the customer: a separate button on the product card, a payment option at the last step of the cart, or a choice of partner bank with a monthly payment calculation. This determines which data we pull from the catalog and how we restructure the checkout template.

What to send along with the task:

• a link to the site and test access with administrator rights;
• a list of banks and installment programs you work with;
• payment calculation requirements: term, down payment, fee;
• examples of orders where an installment is needed and where it is not;
• rules for exporting orders to 1C and payment statuses;
• preferences for notifications to the customer and the manager.

Based on this data, we assess the scope of the refinement, give timelines, and show which parts of the order checkout are affected. If some scenarios already work, we record what we leave unchanged so as not to break current sales.

The next step is a short conversation about the task: we will go over your source data, resolve questions about integration with 1C and bank programs, and come back with an estimate and a work plan. Describe the task in any convenient way — we will prepare a proposal for your store.