Six Israeli payment providers compared on what public docs can verify: open documentation, sandbox, tokens, recurring charges, refunds, webhooks. No pricing.
Key takeaways
- There is no pricing here. Israeli rates are negotiated per business and per volume, and any percentage published on a blog is not your percentage.
- The variable that moves a timeline is documentation access. A provider with an open OpenAPI file is measured in days; one requiring an enquiry is measured in weeks of waiting.
- Cardcom publishes an interactive documentation page for v11 with a downloadable OpenAPI file.
- PayPlus documents an explicit split between a Staging environment and production, with different base addresses.
- Pelecard publishes separate SANDBOX gateways, and Grow points to a developer portal with a Postman collection.
- Wherever a capability could not be verified from public documentation, it says "not publicly documented". That is not a claim the capability is missing.
What decides how many development days a payment integration costs is the documentation, not the fee. A useful comparison is built on what can be verified: whether public documentation exists, whether a test environment is declared, and what is documented about tokens, recurring charges, refunds and server-to-server notifications.
What can be compared, and what cannot
Before the tables, it is worth defining the boundaries of the exercise. These are things you can check yourself in an hour, from a browser:
- Whether public documentation exists that opens without an account and without contacting sales.
- Whether the documentation declares a test environment, and where its base address is.
- Which topics get a page of their own: tokens, recurring charges, refunds, server notifications, 3DS authentication.
- Which language the documentation is written in, and how close it sits to examples you can run.
And these are the things that cannot be compared from outside, and must not be guessed: fees, settlement times, support quality, approval rates, and contract terms. Those are settled with the provider, and usually differ between two businesses that signed in the same month.
Is the documentation open to read without opening an account?
| Provider | Where the documentation is | Opens without an account | Declared test environment |
|---|---|---|---|
| Cardcom | A v11 documentation page with a downloadable OpenAPI file | Yes | Not located in public documentation |
| Tranzila | A dedicated documentation site with task-oriented guides | Yes | Yes, a quickstart guide with cURL |
| PayPlus | A dedicated documentation site with an environment URLs page | Yes | Yes, Staging separate from production |
| Grow | A dedicated developer portal with a Postman collection | Yes | Not documented on the developer page |
| Pelecard | A developer page listing four gateways | Yes | Yes, two SANDBOX gateways |
| Hyp / Yaad Sarig | An Apiary collection; the old developer page redirects to Hyp | Partially | Not located in public documentation |
The gap between the second row and the last row is the gap between a two-day estimate and an estimate that begins with waiting for an email reply.
What is documented about the capabilities you care about
| Capability | Cardcom | Tranzila | PayPlus | Grow | Pelecard |
|---|---|---|---|---|---|
| Storing a payment credential | Documented in v11 | Documented in the payments area | Not verified from official docs | Presented on the developer page | Not verified from public docs |
| Recurring charging | Documented in v11 | Documented as a recurring standing order | Not verified from official docs | Presented as a standing order | Not verified from public docs |
| Refund through the interface | Not verified from the docs page | Not located in the documentation map | Not verified from official docs | Presented on the developer page | Present in the legacy SOAP generation |
| Server-to-server notification | Yes, a dedicated field on the create-payment-page call | Not located in the documentation map | Not verified from official docs | Presented on the developer page | Not verified from public docs |
| Issuing an accounting document | Documented in v11 | Documented as issuing an invoice bound to a transaction | Not verified from official docs | Not verified from the developer page | Not verified from public docs |
"Not verified" in this table means no explicit confirmation was found in the public documentation reviewed in September 2026, not that the capability is absent. That distinction is what makes a comparison useful: what is written can be built on, and what was not checked has to be asked.
Why is "do they have an API" the wrong question?
Because they all do. Every active Israeli payment gateway has a way to charge a card from code. The difference is not whether the capability exists but three things that only surface once you start working:
- How close the documentation sits to something runnable. A cURL example you can paste is not a convenience, it is a day saved.
- Whether there is somewhere to make mistakes. Without a test environment, every iteration is a real transaction, a real refund and a real accounting entry.
- What happens when something breaks in production. An error code with a full description, versus a generic message that requires a support ticket.
The useful question is therefore: how long will it take me, from receiving credentials to a first successful transaction, in an environment that is not production.
What actually determines the scope of work?
- The integration model. Hosted page, iframe, or payment link. Each produces a different user experience and a different timeline.
- Who issues the document. If the provider issues one and your invoicing system issues one, a single transaction ends up with two documents.
- Server-side amount cross-checking. Mandatory regardless of provider, and it is the defensive layer that catches a setting that was not enabled the way you assumed.
- Idempotency on notification intake. The same notification can arrive twice, and that is not an edge case.
- Currencies and instalments. Support for instalments and foreign currency changes both the interface and the accounting reconciliation.
- The provider the business already has. Switching is a commercial decision with a contract behind it, not a developer's preference for nicer documentation.
How to run this comparison yourself in an hour
- Open each provider's documentation page in its own tab, without logging in to anything.
- Search the documentation map for four words: token, recurring, refund, webhook. Whatever has no page has no easy answer.
- Search for the word sandbox or staging, and write down the base address if one appears.
- Find one complete example of a charge call, and judge how many of its fields you do not recognise.
- Write one line per provider: what is documented, what was not found, and what has to be asked.
- Only then ask about price. The pricing conversation is shorter when you already know what you are buying.
This describes what was accessible in public documentation in September 2026, and is neither advice nor a recommendation of a provider. Capabilities and documentation change, and commercial terms are set in the agreement.
Related: integrating with the Cardcom API, integrating with the PayPlus API, Stripe versus an Israeli payment gateway.
Sources
Frequently asked questions
Why is there no fee table here?
Because Israeli clearing fees are set per business, based on volume, activity type and risk. A percentage published in an article is not the percentage you will get, and a quote built on it will mislead your client. Ask three providers in parallel, in writing, for exactly the same business scenario.
What does "not verified from public docs" mean?
That reviewing the public documentation in September 2026 turned up no explicit confirmation. It is not a claim that the capability is absent. Many providers publish fuller documentation after an account is opened, so that item moves onto the list of questions for the provider rather than a list of shortcomings.
Which provider is easiest to integrate with?
It depends on the model you need, but two signals predict it well: documentation that opens without an account, and a declared test environment with its own base address. A provider with both lets you get a first successful transaction before the contract is even signed, which shortens the project considerably.
Is it worth switching providers for a better API?
Usually not. The existing provider has a contract, agreed fees and sometimes physical terminals. The cost of moving, including retesting and accounting alignment, is almost always larger than the gap in development days. Switching is justified when a capability you need simply does not exist with the current provider.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer 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. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.