Cardcom, Tranzila and PayPlus compared on what actually costs you time - the integration model, whether a test environment exists, how amount tampering is prevented, and the five things that are identical no matter which you pick.
Key takeaways
- This compares integration experience, not fees. Rates in this market are negotiated per business and per volume - any figure published on a blog is not your rate, so ask the gateways directly.
- Amount tampering is the one security question that separates them in practice. Ask each gateway how the charged amount is locked server-side before the customer sees the page.
- A documented test environment is the single biggest time saver. PayPlus documents Staging URLs per function; verify what the others offer before you commit to a timeline.
- Five things are identical everywhere: webhook over redirect, idempotency, amount cross-check, who issues the invoice, and never touching card data. Get those right and the gateway choice barely matters.
This comparison is not about fees. Rates in the Israeli market are negotiated per business, per volume and per activity type - any percentage published on a blog is not your rate, and building a quote on it will mislead you. Ask the gateways directly, and preferably ask three.
What can be compared, and what actually determines how many development days the project takes, is what it is like to integrate with them.
Integration model
| Cardcom | Tranzila | PayPlus | |
|---|---|---|---|
| Primary model | LowProfile - create a payment page, redirect or embed in an iframe | Embedded iframe | A payment link you send |
| Main endpoint | /api/v11/LowProfile/Create | direct.tranzila.com/<terminal>/iframenew.php | /api/v1.0/PaymentPages/generateLink |
| Auth | TerminalNumber + ApiName in the body | Terminal name and password; v2 Handshake uses four HMAC-SHA256 headers | api-key + secret-key headers |
| Test environment | Ask | Ask | Staging documented per function |
The difference that matters most: preventing amount tampering
This is the security question that genuinely separates them, and it is not theoretical.
If the transaction amount is passed to the payment page from the client side, it exists in the DOM. Anyone opening developer tools can change it before load, pay one shekel for a 500-shekel product, and receive a valid transaction approval. If your system does not cross-check the amount, the product ships.
- Tranzila solves this with the Handshake: your server requests a token (
thtk), Tranzila locks the amount on its side, and the charge follows the locked value rather than whatever arrived from the browser. Note: this requires purchasing the Token Module - a commercial requirement, not a line of code. - Cardcom and PayPlus create the payment page or link in a prior server call, so the amount is established server-side from the outset.
What you must do regardless: cross-check the returned amount against the order, server-side, every time. That is defence in depth and it catches a configuration that was not enabled the way you assumed.
A test environment - the biggest time saver
PayPlus documents a Staging environment, with every function in the docs listing both Staging and Production URLs. That is a real advantage.
Why it matters more than it sounds: a production mistake in a payments integration is not a row you delete. It is a real transaction - a refund, a bookkeeping entry, sometimes a call with a confused customer. Twenty development iterations against production are twenty such events.
For the others - this is a fair question to put to support before starting, and worth getting answered in writing before you commit to a client timeline.
When each fits
| Your scenario | What fits |
|---|---|
| Online store with a standard checkout | All three. Choose on fees and on who the business already uses |
| Collecting after a sales call or a quote | The link model maps directly - send by WhatsApp or email |
| Embedded payment without leaving the page | An iframe |
| Automatic document issuance from the gateway | Cardcom exposes a Document object on the create call |
| The business already uses a gateway | Do not switch. Switching costs more than the gap |
That last point matters: a payment gateway is not a developer's decision. It has a contract, negotiated rates and a relationship with the business. Recommending a switch because an API is nicer is bad advice.
Five things that are identical everywhere
Once the first call works, the differences all but vanish. What determines whether the integration holds:
1. Webhook, not redirect
The browser redirect is not reliable. A customer who closes the tab the moment payment clears never reaches your thank-you page, and the order stays "pending" while the money has been taken. State updates come from a server-to-server notification. The redirect shows a thank-you screen and nothing more.
2. Idempotency
The same notification can arrive twice. This is not an edge case. It must not mark two orders paid or ship twice.
3. Amount cross-check
Always, server-side, against the order. Even when everything looks fine.
4. Who issues the invoice
If the gateway is configured to issue a document automatically and your system also issues one through your invoicing system, one transaction produces two tax documents. This is the most common design mistake in such projects, and it surfaces at month end at the accountant's desk. Pick a side and document it.
5. Never touch card details
In all three models card details are entered at the gateway and never pass through you. That is the entire benefit, and it holds only if you do not send, log or store them. A single log line containing a card number changes the regulatory picture.
How to choose in practice
- Who does the business already use? If there is an answer, that is the answer.
- What is the collection model? Checkout, link, or embedded - that points at the right shape.
- Is there a test environment? Ask in writing.
- How is the amount locked? And if the answer requires a paid module, establish that before pricing.
- Fees. Last on this list, first for the business - but that is a conversation with the gateway, not a technical consideration.
Detailed guides: Cardcom v11 · Tranzila · PayPlus.
Frequently asked questions
Which Israeli payment gateway is best for developers?
On integration experience rather than fees, PayPlus stands out for documenting a Staging environment per function, which lets you build the whole flow without moving real money. But the strongest answer is usually whichever the business already uses - a gateway carries a contract and negotiated rates, so switching for a nicer API costs more than the gap.
Can someone change the payment amount in the browser?
If the amount is passed to the payment page from the client side, yes - it sits in the DOM and can be edited in developer tools before the page loads, producing a valid approved transaction for the edited figure. Tranzila's Handshake locks the amount server-side to prevent this, and Cardcom and PayPlus establish it in a prior server call. Regardless of gateway, cross-check the returned amount against the order server-side.
Why do some paid orders stay marked as pending?
Almost always because order status is updated on the browser redirect rather than the server notification. A customer who closes the tab as soon as payment clears, or whose connection drops, never reaches your success page - so the money is collected while the order stays pending. Drive state from the webhook and use the redirect only to show a thank-you screen.
What are typical Israeli payment gateway fees?
There is no useful published figure. Rates are negotiated per business, per monthly volume and per activity type, so any percentage quoted in an article is not your rate and should not be used to build a client quote. Get quotes directly from the gateways - preferably from three - and treat fees as a commercial conversation separate from the technical comparison.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP engineer
I'm Yehonatan Saadia, a senior engineer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.