Help Center

Chargeback comes from the English words «charge» (debit) and «back» (return), which literally means «return of funds back». This term refers to the procedure by which a bank refunds money to the payer after funds were mistakenly or fraudulently withdrawn from their account.

It is a consumer protection mechanism that allows the cancellation of credit or debit transactions and the return of funds if the customer did not authorize the purchase, did not receive the goods or services, or if billing errors occurred.

Participants in a chargeback

The chargeback process involves:

• Customer: Initiates the chargeback through the issuing bank (the bank that issued the card).
• Issuing bank: Conducts the investigation and, if necessary, refunds the money to the customer. In Israel, the issuing banks can be Isracard, CAL, MAX and few others.
• Merchant (seller): Must provide evidence of the legitimacy of the transaction. If the chargeback is justified, the merchant refunds the money to the bank.

Possible reasons for a chargeback

• The customer requested a refund because they did not recognize a charge in the bank statement or forgot about an actual payment.
• The goods or services were not provided by the merchant.
• Fraudulent charges were made on the card without the customer’s knowledge (the card was stolen or compromised).

Chargeback procedure

After the customer files a request, the issuing bank opens a case, determines the reason for the chargeback, and decides whether to return the money to the customer or leave it with the merchant. As part of the investigation, the bank will contact the merchant and request proof of service delivery.

In Israel, according to the Payment Services Law of 2020, if a transaction is considered an «insufficient documentation transaction» (i.e., made without the physical presence of the card, which applies to all online payments), the customer receives a full refund if they contact the issuing bank within 30 days of receiving the charge notification.

Thus, the law provides significant protection for the consumer but can also lead to fraud and cancellations of legitimate transactions where the customer actually received the agreed service. Therefore, merchants are advised to collect and keep evidence of goods or services provided to the customer, especially for large amounts (e.g., contracts, receipts, emails, delivery confirmations).

If the bank establishes that the funds were withdrawn from the customer’s card illegally, they will be returned to the customer and deducted from the merchant’s balance.

Risks for merchants

Frequent chargebacks can have serious consequences for merchants. The main risk is financial loss due to refunds to customers. However, that is not the only risk:

• Fines and fees: Banks may impose fines for each chargeback, increasing financial pressure on the business.
• Deterioration of banking relationships: Frequent chargebacks can damage relationships with acquiring banks. This can lead to higher fees, worse cooperation terms, or even termination of the contract.
• Risk of being blacklisted: A high chargeback rate can result in being added to blacklists of payment systems, making it difficult to work with new acquirers and other financial institutions.
• Loss of reputation: Frequent chargebacks can damage the merchant’s reputation, creating distrust among customers and partners.

Tips for prevention

To minimize chargeback risks, merchants should take the following measures:

• Use secure payment methods: Activate 3DS for payments — a two-factor authentication method where the bank asks the customer to confirm the payment via the banking app or by entering an SMS code.
• Improve communication with customers: Quick and transparent communication helps avoid misunderstandings. It is important to respond to customer inquiries promptly and provide full information about goods and services.
• Collect and store evidence: Systematically keep all documents confirming the provision of services or delivery of goods. This will help protect the business in case of a chargeback.
• Clear refund policy: A transparent and easy-to-understand return policy can reduce the number of chargebacks, as customers will know how to return a product or cancel a service.

Fee

A fee is charged by the credit card company for reviewing each chargeback case, in accordance with the pricing.

Display in the interface and documents

If a chargeback was requested for a payment, a new transaction with a negative amount and the label <span class="u-richtext-element" style="background-color: rgba(221, 94, 94, 0.4)">chargeback</span> will appear on the payments screen.

A refund document will also be created: a credit invoice and/or a receipt with a negative amount — depending on the business type and the type of the previously issued document.

If the business disputed the chargeback and the dispute was resolved in favor of the business, the funds will be returned. In this case, a new transaction with a positive amount and the label <span class="u-richtext-element" style="background-color: rgba(68, 203, 138, 0.5)">chargeback reverse</span> will appear on the payments screen.

A new income document will also be created: a receipt or a tax invoice/receipt — depending on the business type and document settings.

To have the Bit payment button appear on your payment pages, activate the Bit module in the <span class="u-richtext-element">Settings</span> ➙ <span class="u-richtext-element">Modules</span> ➙ <span class="u-richtext-element">Bit</span> section.

Payment via Bit is only possible from a mobile device on which the Bit app is installed. When paying from a computer, the system will display a QR code for scanning and switching to payment from a mobile device.

Payments received through Bit are credited to the business's bank account along with the payout in the same way as other payments.

Bit button for foreign customers

Since Bit is an Israeli system, we make it possible to hide the Bit button for customers who pay from abroad. The system determines the client's geolocation by its IP.

The corresponding switch can be found in the module settings.

Restrictions

Up to 5000 ILS. Payment via Bit cannot exceed 5,000 shekels. The sum of all payments per month from all customers cannot exceed 20,000 shekels.

ILS. Bit only supports payments in shekels.

No installments. You can only pay with Bit in one payment.

No subscriptions. Bit does not allow you to save your customer card for future charges, so we hide the Bit button for “Subscription” payment links.

No payment from Bit balance. The charge is made from the card linked to Bit. If the card has insufficient funds or the credit limit is exceeded, the payment will fail.

Ten minutes. From the moment you press the Bit button, the customer has 10 minutes to make a payment.

Diners. Diners and Discover brand cards are not supported by Bit.

Name and email

Bit does not give us the payer's name and e-mail address, so we request them ourselves when making a payment.

The e-mail field is optional by default, and if it is not filled in by the customer, a payment confirmation will not be sent. You can make this field required in the Bit module settings.

Integrations

For payment integrations from ours catalogue The Bit button will be shown on the payment page if the module is activated and hidden if not.

API

Software integration developers documentation<span class="u-richtext-element">, can control the display of the Bit button on the payment page by using the show_bit parameter.</span> However, the Bit module must first be activated through your Allpay account.

For test payments, use the real card attached to the Bit app. At the same time, don't forget to activate the test mode for payment integration.

In Allpay, the plan is billed monthly. After registration, there is a 7-day trial period.

All paid services and modules are charged to the plan balance. Once a month, the outstanding amount is automatically paid: first from the payout balance, and if there are not enough funds there, then from the linked card.

Subscription fee vs processing fee

The subscription fee and payment processing fee are different charges.

The subscription fee is deducted once a month from your payouts or charged to the linked card. The payment processing fee is charged separately for each transaction, and the remaining amount is credited to the payout balance.

Trial period and billing date

After registration, every client gets a 7-day trial period. At the end of the trial period, the system will charge the subscription fee for the next billing period.

The date of the first charge becomes the fixed monthly billing date for the plan. It does not change in the future.

For example, if you registered on March 10, the trial period will end on March 17. On that day, the system will charge the first payment for the next billing period. The following charges will take place on the 17th of each month.

How the plan balance works

In the standard scenario, the plan balance does not need to be topped up in advance.

All paid services and modules that you activate during the month are charged to the balance in <span class="u-richtext-element">Settings</span> → <span class="u-richtext-element">Plan</span> → <span class="u-richtext-element">Billing</span>, creating an outstanding balance.

When the billing date arrives, the outstanding balance is paid using the funds available for payout, and the plan balance becomes zero again.

If there are not enough funds on the ILS payout balance, for example, if you did not accept any payments during the month, the system will charge the linked card.

If the card charge fails, an outstanding debt is created on the plan balance. In other words, the balance remains negative until the debt is paid.

If a new module with a subscription fee is activated in the middle of a billing period, its cost is calculated proportionally to the time remaining until the next billing date.

In some cases, the plan balance can be topped up in advance by bank transfer through support. This is usually used by companies that do not have a corporate card.

Canceling your Allpay subscription

You can cancel your subscription at any time. To do this, click “Disable all” in <span class="u-richtext-element">Settings</span> → <span class="u-richtext-element">Plan</span>.

After cancellation, the service will continue to work and payments will continue to be processed until the end of the paid period. After that, the service will be disabled, and no new debt will be charged for the next billing period.

The “Disable all” button disables all paid services at once:

• main payment processing service;
• Subscriptions module;
• Shopify module, if it was active;
• other paid modules, if they were active.

If you want to disable only one module, you need to do this in <span class="u-richtext-element">Settings</span> → <span class="u-richtext-element">Payment modules</span>

After the service is disabled, your account and payment history are saved. If needed, you will still be able to log in to your account and view previous transactions. The service can always be activated again to resume accepting payments.

If there is an outstanding debt on the plan balance when the service is reactivated, the system will immediately try to pay it: first from the payout balance, and if there are not enough funds, then from the linked card or a newly added card.

Failed charges

If the system cannot charge any of the payment methods, an error message will appear in the Allpay interface. An email is also sent for each failed charge.

The system makes four charge attempts in total:

• Attempt 1 — the first failed charge.
• Attempt 2 — 2 days after the first attempt.
• Attempt 3 — 10 days after the first attempt.
• Attempt 4 — one month after the first attempt.

Until the final charge attempt, the service continues to work as usual. If the debt is not paid after the fourth attempt, the service will be suspended.

The unpaid debt will remain on the plan balance. It must be paid before you can continue using the service.

Four charge attempts during the month give you enough time to fix the issue without losing the ability to accept payments or create documents.

You can view the charge attempt history in <span class="u-richtext-element">Settings</span> → <span class="u-richtext-element">Plan</span> → <span class="u-richtext-element">Payment methods</span>

How to pay an outstanding debt

To pay an outstanding debt, add a valid card in <span class="u-richtext-element">Settings</span> → <span class="u-richtext-element">Plan</span> → <span class="u-richtext-element">Payment methods</span>, or open the menu of an already linked card by clicking the three dots and select “Try again”.

Before trying again, make sure the reason for the error has been fixed. For example, check that the card has enough funds, is not blocked, and is allowed for online payments.

You can also accept new payments so that they cover the plan debt. However, it is important to remember that each payment is processed for 3–5 days before it reaches the payout balance.

Payment methods

Charging from the payout balance is the default main payment method for all users who use the payment processing service.

The bank card that you added during registration or linked later becomes the backup payment method for the plan.

In <span class="u-richtext-element">Settings</span> → <span class="u-richtext-element">Plan</span> → <span class="u-richtext-element">Payment methods</span>, you can:

• delete a card;
• add a backup card;
• set a card as the main payment method;
• manually retry the charge if there was an error.

You can add a new card and set it as the main payment method. In this case, the payout balance charge method and the previous card will become backup payment methods.

The system first tries to charge the main method, and if the charge fails, it automatically tries to charge the backup methods.

Platform developers that need a payment solution can integrate with Allpay.

This model is suitable for platforms that want to add Allpay as a payment method and be listed in the Allpay integrations catalog. It does not include partner payouts and is based on mutual promotion (other partnership models).

This integration will become available to Allpay customers as a ready-made way to connect your platform.

Requirements

To have your platform added to the Allpay integrations catalog, the following conditions must be met:

1. You do not participate in the Allpay partner or referral program.
   This integration is based on mutual promotion.
2. The integration must be approved by Allpay in advance.
   Your platform must be in demand in Israel and already used by real customers.
3. You are ready to support the integration on an ongoing basis.
   You are responsible for maintaining the integration and providing customer support on your side.

How to start

To approve the integration of your platform, contact Allpay support and briefly describe:

• your platform;
• who your customers are;
• how exactly you want to use Allpay payments;
• which integration method you plan to use: manual or automated;
• whether there are already customers who need this integration.

Integration methods

Integration with Allpay can be implemented in two ways:

• manual integration;
• automated integration.

Manual integration

With manual integration, you implement the connection on your side and publish instructions for customers on your website.

The customer will need to:

1. Open the integrations section in the Allpay dashboard.
2. Create API keys.
3. Copy the keys and paste them into the settings of your platform.

Technical involvement from Allpay is usually not required for this type of integration. After implementation, send us information about your platform and a link to the Allpay connection instructions on your website.

After review and approval, your platform will be added to the Allpay integrations catalog.

Automated integration

Automated integration allows the platform to be connected without manually copying API keys. The user clicks the connection button in the Allpay dashboard, confirms the connection on your platform side, and the API keys are transferred automatically.

Before implementation, Allpay provides your platform with:

<span class="u-richtext-element">partner_id</span> — the individual integration ID;

<span class="u-richtext-element">secret_key</span> — the secret key for signing and verifying server requests.

<span class="u-richtext-counter">1</span>Redirect from Allpay to your platform page

The user opens the <span class="u-richtext-element">Settings</span> → <span class="u-richtext-element">Integrations</span> → <span class="u-richtext-element">Your platform</span> section in the Allpay dashboard and clicks the connection button.

Allpay generates a one-time token for linking the accounts and redirects the user to the confirmation page on your platform side, for example:

https://your-platform.com/connect?token=TOKEN

Where <span class="u-richtext-element">TOKEN</span> is the one-time token created by Allpay.

The standard token lifetime is 1 hour.

<span class="u-richtext-counter">2</span>Confirmation on your platform side

On your side, the user confirms the connection under their account.

After confirmation, your platform redirects the user back to the universal Allpay endpoint:

https://allpay.to/services/endpoints/exchange.php?act=connect&partner_id=PARTNER_ID&token=TOKEN&external_uid=USER_ID&display_name=DISPLAY_NAME

Where:

<span class="u-richtext-element">act=connect</span> — the integration connection action;

<span class="u-richtext-element">partner_id</span> — the individual integration ID;

<span class="u-richtext-element">token</span> — the one-time token created by Allpay;

<span class="u-richtext-element">external_uid</span> — the internal user ID on your platform.

<span class="u-richtext-element">display_name</span> — a human-readable name of the account being connected (e.g. login, name or subdomain on your platform). This is the value shown in the Allpay dashboard's integrations list — pass something the user will recognize themselves, not an internal technical identifier. The value must be URL-encoded, max 255 characters.

<span class="u-richtext-counter">3</span>Creating and sending API keys to your platform

After verifying the token, Allpay links the Allpay user with the user on your platform, creates or finds the API keys <span class="u-richtext-element">api_login</span> and <span class="u-richtext-element">api_key</span>, and then sends them to your endpoint.

Example endpoint on your platform side:

POST https://your-platform.com/allpay/partner/exchange

Request body:

{
  "external_uid": "USER_ID",
  "api_login": "API_LOGIN",
  "api_key": "API_KEY",
  "sign": "SIGNATURE"
}

Where:

<span class="u-richtext-element">external_uid</span> — the user ID on your platform;

<span class="u-richtext-element">api_login</span> — the Allpay user's API login;

<span class="u-richtext-element">api_key</span> — the Allpay user's API key;

<span class="u-richtext-element">sign</span> — the request signature.

<span class="u-richtext-counter">4</span>Request signature

The server request with the API keys is signed using HMAC SHA-256.

Signature format:

hash_hmac('sha256', $payload_json, $secret_key);

Where:

<span class="u-richtext-element">payload_json</span> — the JSON request body;

<span class="u-richtext-element">secret_key</span> — the individual secret key.

<span class="u-richtext-counter">5</span>Response from your platform

After successfully receiving and saving the keys, your platform must return a successful response, for example:

{
  "ok": true
}

After this, Allpay marks the integration as active.

Disconnecting the integration

If the user disconnects the integration on your platform side, you must delete the saved API keys on your side.

In addition, your platform must send a POST request to Allpay to disconnect the integration:

POST https://allpay.to/services/endpoints/exchange.php?act=disconnect&partner_id=PARTNER_ID

Request body:

{
  "external_uid": "USER_ID",
  "sign": "SIGNATURE"
}

Where:

<span class="u-richtext-element">external_uid</span> — the user ID on your platform;

<span class="u-richtext-element">sign</span> — the request signature.

The disconnect request is also signed using <span class="u-richtext-element">secret_key</span>.

If the user disconnects the integration from the Allpay dashboard, Allpay can send a disconnect notification to your platform endpoint. To receive this notification, provide an endpoint on your side.

Security requirements

For automated integration, the following requirements must be met:

1. HTTPS only
   All requests between Allpay and your platform must be sent only over HTTPS.
2. Secure key storage
   The received <span class="u-richtext-element">api_login</span> and <span class="u-richtext-element">api_key</span> must be stored securely on your side.
3. Server request signatures
   Server requests must be signed using <span class="u-richtext-element">secret_key</span>.

<span id="info">Information for the integrations catalog</span>

After the technical part is completed and the integration is working, send us the following information to add your platform to the Allpay integrations catalog:

• platform logo in SVG format;
• short platform description of up to 200 characters;
• extended platform description of up to 360 characters;
• technical support contacts for the integration: email and WhatsApp or Telegram;
• information on whether your integration supports installments, recurring payments, and refunds;
• link to the Allpay connection instructions on your website.

Allpay branding guidelines

Use the correct brand spelling:

correct: Allpay;

incorrect: AllPay, All Pay, allpay.

Use the official Allpay logo.

In the details of a declined payment, you can view the error message and determine the reason for the decline.

Error codes

Payment failed - please contact Customer Support (20001)

The payment could not be completed due to a temporary communication issue with the national processing network (Shva). The error is not related to the card or the saved token. The card was not charged. Please try the payment again. If the error persists, contact Allpay Support.

Refusal by credit company. Please try a different card (20004)

‍The payment was declined by the card-issuing bank. For Israeli cards, this is most commonly caused by exceeding the credit limit (misgeret) or insufficient funds when using a debit card. For international cards, the bank may have declined the payment because it considered the transaction suspicious. In either case, the cardholder should contact their bank to determine the exact reason for the decline.

Payment is not approved for debit cards (20010)

‍An installment payment was attempted using a debit card. Installment payments are only supported for credit cards issued in Israel. Learn more.

Verification failed, please try again (21017)

‍The cardholder did not complete 3DS verification: they did not enter the SMS code, approve the payment in their banking app, or complete verification using another method provided by their bank.

‍

Israeli law requires accounting documents, including receipts, tax invoices, and other records, to be issued in Hebrew or Arabic.

In practice, this raises two questions: what to do if a customer prefers to receive the document in English, for example, if they are located abroad, and how to handle a customer name or product name entered in another language.

Document language

The system automatically creates each document in two versions: Hebrew and English. The Hebrew version is the original and is stored in your accounting system, while the English version is a copy. You can choose which version to send to the customer.

Issuing original documents in English requires special approval from the Israel Tax Authority. This is usually unnecessary, as foreign customers can receive an English copy.

Three options are available in the settings:

• Hebrew — all customers receive the document in Hebrew.
• English — all customers receive the document in English.
• English for international payments — customers paying with a card issued outside Israel receive the document in English, while customers paying with an Israeli card receive it in Hebrew.

Regardless of the selected setting, the original Hebrew document is always created and stored in the system.

Customer name and product name

The customer enters their name when making the payment, while you enter the product or service name when creating the payment link.

If the name is entered in a language other than Hebrew or Arabic, such as English, Russian, or French, you can choose one of two options:

• Keep as is — the text appears in the document exactly as entered.
• Translate into Hebrew — the system automatically translates the text into Hebrew before creating the document.

Automatic translation may not always accurately reproduce personal names, brand names, or product and service names. Use the preview to check the result: enter a customer name or product name to see how it will appear in the document. We recommend testing several common examples before enabling automatic translation.

If the translation service is temporarily unavailable, the document will still be created using the original text to avoid delaying its issuance.

This article does not constitute accounting or tax advice. For guidance on accounting requirements, consult an accountant or tax advisor.

Hosted Fields allow you to embed card input fields on your website or app, fully adapting them to the system's design. They create a seamless interface experience and eliminate the need to redirect the customer to an external payment page. This improves usability and conversion rates.

The input fields for the card number, expiration date, and CVC are represented as an iFrame. We provide the ability to fully customize their CSS and embed them on your site as a single frame.

Tutorial

Setup

<span class="u-richtext-counter">1</span> In the <span class="u-richtext-element">Settings</span> → <span class="u-richtext-element">Integrations</span> → <span class="u-richtext-element">My sites</span> enable Hosted Fields for the required integration.

<span class="u-richtext-counter" id="domains">2</span> Click <span class="u-richtext-element">Hosted Fields settings</span> and specify the domains where Hosted Fields will be used. Enter each domain or subdomain on a separate line without “https://”, for example: <span class="u-richtext-element">mysite.com</span>. To allow all subdomains, use the <span class="u-richtext-element">*</span> wildcard, for example: <span class="u-richtext-element">*.mysite.com</span>.

If needed, adjust the CSS styles for the input fields.

<span class="u-richtext-counter">3</span> On your website’s payment page, place an iFrame, assign any custom value to its <span class="u-richtext-element">id</span> parameter, and in the <span class="u-richtext-element">src</span> parameter specify the payment URL (payment_url) returned by Allpay in response to a payment creation request (see Payment request section in the API Reference). Payment URLs can also be generated using the Allpay API Tester.‍

<span class="u-richtext-counter">4</span> Add the following script to the payment page:

1<script src="https://allpay.to/js/allpay-hf.js"></script>
2    <script>
3    let Allpay = new AllpayPayment(
4        {
5            iframeId: 'iframe_id',
6            onSuccess: function() { alert('Payment success'); },
7            onError: function(error_n, error_msg) { alert('Payment error: ' + error_n + ' (' + error_msg + ')'); }
8        }
9    );
10    </script>

‍

In the script, replace the following parameters with your own:

• <span class="u-richtext-element">iframeId</span> — the id value of your iFrame.
• <span class="u-richtext-element">onSuccess</span> — the handler for successful payment completion (what should happen after successful payment).
• <span class="u-richtext-element">onError</span> — the handler for payment errors. For example, you can display the payment error message on the page.

<span class="u-richtext-counter">5</span> To initiate the process, execute the function <span class="u-richtext-element">Allpay.pay()</span>, for example, by assigning it to the "Pay" button:

<button onclick="Allpay.pay();">Pay</button>

Installments

If you enabled the installment option for the customer when creating the payment by passing a value in the <span class="u-richtext-element">inst</span> parameter, a field for selecting the number of payments will automatically appear in the frame.

Quick Pay Buttons

Apple Pay and Bit buttons will not be displayed in preview mode or within the iFrame if they are not activated in the <span class="u-richtext-element">Settings</span> → <span class="u-richtext-element">Modules</span>.

Additionally, these buttons are not displayed in test mode. As well as in live mode for installment or subscription payments.

Apple Pay button

For the Apple Pay button to work correctly, complete the following two steps:

<span class="u-richtext-counter">1</span> Add the <span class="u-richtext-element">allow="payment *"</span> attribute to the <span class="u-richtext-element">iframe</span> tag. Example:

<iframe id="myPaymentIframe" allow="payment *" src="..." >

<span class="u-richtext-counter">2</span> Upload the Apple Pay certificate to your domain’s server. The certificate and installation instructions are available in the Hosted Fields settings in your Allpay account.

Embedding in a mobile app (WebView)

If you embed the payment page in a mobile app using a WebView (android.webkit.WebView or WKWebView), some payment methods may not work correctly. For example, Bit or 3D Secure verification may redirect the user to a payment or banking app using special links such as <span class="u-richtext-element">intent://</span>

Unlike a standard browser, WebView does not always handle these redirects automatically. As a result, the external app may not open, preventing the user from completing the payment.

We recommend opening the payment page using a system browser component:

• Chrome Custom Tabs on Android;
• SFSafariViewController on iOS.

These components behave similarly to a standard mobile browser and provide better support for redirects to payment and banking apps.

If you need to use WebView, handle navigation within the mobile app:

• open regular <span class="u-richtext-element">http://</span> and <span class="u-richtext-element">https://</span> links inside the WebView;
• pass links that use other schemes to the operating system so it can open the appropriate app;
• if the required app is not installed, use the provided fallback link to open the browser, App Store, or Google Play.

This limitation is related to how WebView handles external links, not to Hosted Fields itself.

By default, the amount of an installment payment is credited in monthly parts, depending on the number of payments selected by the customer at checkout.

For example, if the amount was split into 10 payments, the funds will be credited as 1/10 of the amount over 10 months, as the customer’s card is charged.

However, the business can receive the full amount upfront — together with the first payout. The customer will still be charged in parts according to the regular installment schedule.

When using the «sherut nikayon» (שירות ניכיון) service, the credit company pays the business the full amount upfront (deducts an additional commission), and then collects the funds from the customer in parts.

It will not be possible to split payments between regular installments without an additional fee and installments upfront with an additional fee. While the service is active, all installment payments will be processed through the upfront installments mechanism.

Requirements

Since receiving the full amount upfront uses a credit mechanism, three conditions must be met before the service can be activated:

1. Business owner must be at least 21 years old.
2. Allpay must be used for at least three months.
3. Total turnover for the entire period must be at least 15,000 ILS.

These criteria allow the credit company to assess the business’s payment activity and reduce chargeback risks — situations where the business receives a payout for a significant amount, and the cardholder later claims that the charge was unauthorized.

Activation

The service is activated in <span class="u-richtext-element">Settings</span> ➙ <span class="u-richtext-element">Payment modules</span> ➙ <span class="u-richtext-element">Installments upfront</span>

After the activation request, we will send the documents for signature. Once approved by the credit company, the module will be enabled. The review usually takes 5–7 business days.

All installment payments received after the service is approved will automatically be processed using the full-amount crediting mechanism.

The service does not apply retroactively, meaning it does not apply to payments made before it was activated.

Deactivation

You can deactivate the module in the same modules section. Deactivation takes 5–7 business days. After deactivation, you will receive an email notification.

The module can be reactivated only after 30 days.

<span id="fee">Fee</span>

The credit company charges an additional fee for accelerated crediting. The fee amount and calculation method are shown on the plan page.

The <span class="u-richtext-element">Customer pays the fee</span> toggle is available in the module settings. When enabled, customers who choose two or more installments will see the additional fee on the payment page. This fee is added to the original payment amount and charged to the customer.

The fee is calculated using the gross-up formula. This means that the fee is calculated based on the final amount, which includes both the original payment amount and the fee itself. The fee cannot simply be calculated based on the original amount and added on top, because increasing the total amount also changes the fee amount.

The gross-up formula determines the final amount to be charged so that, after the fee is deducted, the business receives exactly the original payment amount:

Final amount = original amount ÷ (1 − fee rate)

Customer fee = final amount − original amount