Taking payments in Israel from a Base44 app: Tranzila, Cardcom, Grow and the rest

The short version

As of October 2026, Base44’s built-in payment options don’t serve a business based in Israel. Base44 Payments powered by Wix is offered in 12 countries, and Israel isn’t one of them. Stripe, which Base44 sets up for you from the AI chat, doesn’t list Israel among the countries where a business can open an account. Base44 did add Tranzila and Max by Hyp as built-in providers for Israeli merchants in the spring of 2026, but its documentation says that, as of August 2026, both are unavailable as built-in providers.

What Base44 recommends instead is connecting the payment provider of your choice as an integration. In practice that means an Israeli processor called from your app’s backend functions, which need the Builder plan or higher. The customer pays on the processor’s own page, the processor notifies your app, and your app checks the result before marking the order paid. Tranzila publishes a guide for doing exactly this in a Base44 app.

What Base44 supports for payments, as of October 2026

Two clauses in Base44’s terms of service are worth knowing before you choose. First, you promise not to share payment card data with the platform unless Base44 has agreed to it in writing, so card numbers should never pass through your app’s tables or functions. Second, Base44 isn’t a party to your relationship with a payment provider, and it may suspend or remove any payment provider from your account, with or without notice. You’re responsible for the taxes on your sales.

How an Israeli processor connects to a Base44 app

Each processor has its own API, but the flow is the same:

1. Create the order. Your app saves an order in a table, with status “pending” and its own ID.
2. Ask the processor for a payment page. A backend function sends the amount, the order ID and your return addresses to the processor, using API keys stored as secrets. Backend functions need the Builder plan or higher (Using integrations).
3. The customer pays on the processor’s page, shown in an iframe or by redirect. Card details go to the processor, never to your app.
4. The processor notifies your app. Every Base44 backend function has its own address, https://<your-app-domain>/functions/<function-name>, which Base44’s backend functions docs describe for webhooks. Calls like this come with no signed-in user, so the function uses asServiceRole to update the order.
5. Verify before you mark it paid. Check the result with the processor’s API, match it to your order ID rather than to the amount, and ignore a notification you’ve already handled.
6. Show the result. The success page reads the order’s status from your database.

Base44’s payment FAQ adds two practical points: custom payment flows usually don’t work in preview, so test on the published app, and the success and cancel addresses must point at your published domain. Its Stripe page also warns that apps in the App Store or Google Play can’t sell digital content through their own checkout, because Apple and Google require their billing systems; see Base44 mobile apps.

The main Israeli processors, side by side

From each company’s developer documentation, as of October 2026:

A few specifics worth knowing:

• Tranzila documents a Base44 integration of its own (Tranzila Integration for Base44). It needs an active terminal, a Base44 Builder plan or higher for backend functions, and two options enabled on the payment page. Refunds can’t be made through the integration, only in my.tranzila. Its notify page guide shows how to point the notify URL at a Base44 function.
• Cardcom‘s API reference is public as an OpenAPI page (API 11.0). Its ReturnValue field exists so you can pass your own order ID and get it back in the webhook.
• Grow‘s server callback docs say requests must come from your server, not the browser, and that a transaction goes through even if ApproveTransaction isn’t called or fails, so don’t treat a missing acknowledgement as a failed payment.
• Hyp‘s developer guide recommends verifying every transaction from your server, “to make sure that no one malicious has attempted to feed you fake transaction data”. Its invoicing guide describes tax invoice-receipts or receipts issued for every successful transaction.
• Isracard powered by PayMe is the name under which Isracard’s online processing is offered, on a PayMe account, for example in Wix’s help center, which lists shekels, installments, recurring payments and Bit. PayMe’s integration options spell out the trade-off: with the hosted page, PCI DSS compliance sits with PayMe; with the direct API, the merchant has to meet PCI DSS level 1.

The trade-offs

• Hosted page, embedded fields or direct API. The processor’s own page is the least work and keeps card data away from your app, as Base44’s terms ask. Embedded fields look more like your app. A direct API puts PCI DSS on you.
• Built-in or your own integration. A built-in provider is quicker to set up, but it’s Base44’s to change: the built-in Tranzila and Max by Hyp options became unavailable a few months after they launched. An integration in your own backend functions, against your own processor account, keeps working as long as the functions do.
• What Israeli customers expect. Installments (תשלומים), Bit and recurring charges are standard requests, so check that the processor and plan you pick support them. Base44’s Israel page notes, for example, that Tranzila requires at least NIS 5 for a Bit payment.
• Refunds usually happen in the processor’s dashboard. Decide whether your app needs to hear about them.

Invoices and receipts

This is context, not tax advice; your accountant decides what your business needs.

• A receipt for every payment. Under section 5 of the Income Tax bookkeeping rules, a receipt is made out for each payment separately, with a running number, the date, the amount and what it’s for, and a copy goes to the payer. Which other documents and books you keep depends on your type of business.
• Allocation numbers. Under the “Israel invoices” model, a tax invoice needs an allocation number from the Tax Authority when the customer is a VAT-registered business that asks for one and the amount before VAT is above the threshold: NIS 10,000 from 1 January 2026, and NIS 5,000 from 1 June 2026 (VAT instruction 01/2025). Accounting software can request the number automatically.

One practical route is to let the processor’s invoicing module or a dedicated invoicing service issue these documents; several processors in the table above can. Generating numbered “invoices” from a table in your own app is a question to put to your accountant first.

What changes when you own the code

A processor integration built from backend functions is code in your app, so it moves with the app. When you move with Unbase44, your backend functions and secrets come along, and the processor account stays yours. Choosing and contracting a processor stays between you and the processor.

Three things to plan for:

• Test mode. The new copy starts in test mode, next to the Base44 app that keeps serving your users. It holds whatever it would send out, including payments and changes to other services, and logs it instead, so you can run the checkout without charging anyone.
• The notify address. The guided switch-over helps move Stripe, PayPal, Twilio and Telegram webhooks to the new address. An Israeli processor’s notify URL is yours to update: in the dashboard (Tranzila’s notify URL, for example), or in the request your function sends (Cardcom’s WebHookUrl, Grow’s notifyUrl, PayPlus’s refURL_callback). Check which one your app uses before you switch.
• Card data stays with the processor. Wherever the app runs, keep the customer’s card entry on the processor’s page.

The free analysis lists your app’s functions and integrations before you connect any account: start here. For the order of the whole move, see migrating from Base44; for plan costs, see Base44 pricing and credits.