Yaad Sarig and Pelecard: The Israeli Payment Interfaces Nobody Writes About

Yaad Sarig and Pelecard are two long-established Israeli payment gateways with a large installed base and a small presence in developer conversation. Yaad Sarig now operates as part of the Hyp group, and Pelecard publishes several interface generations side by side. In both cases the first job is identifying which generation you are on.

Why these come up in projects at all

Not through a provider comparison. They come up because the business already clears through them: there is a contract, defined transaction routes, and sometimes physical terminals from the same family. Switching payment gateway is a commercial move with a real cost, so the correct assumption at the start of a project is that you are connecting to what exists rather than choosing again.

That changes the order of work. Instead of comparing capabilities, you establish three things: which interface generation is live for this business, who holds the credentials, and what is already embedded in the site or system today.

What does a Yaad Sarig integration actually look like?

The dominant pattern is a hosted payment page that you send the customer to with parameters in the query string. You can see this in any live payment link from the service: the URL sits under icom.yaad.net and carries parameters such as Masof for the terminal number, Amount, Coin for currency, Tash for the number of instalments, Info for a description, Order for the order identifier, UTF8out for response encoding, and signature.

Two things worth knowing before you start:

• The brand has drifted away from the address. The historical developer page at yaadpay.yaad.net/developers/ currently redirects to the online payments page on the Hyp site. The documentation collection at yaadpay.docs.apiary.io now carries the title Hyp Pay. If you search for Yaad and land on Hyp, that is not a mistake.
• The signature is part of the interface. A signature parameter is present in calls, which means there is a server-side preparation step before you redirect the customer. Do not plan a redirect assembled entirely in the browser.

What cannot currently be verified from public documentation: whether a documented test terminal exists, exactly how the signature is computed, and whether tokens or recurring charges are documented capabilities. Establish those with the provider in writing before you commit to a date.

What does a Pelecard integration actually look like?

Pelecard's developer page at gateway20.pelecard.biz lists four gateways by name: Payment - Gateway 2.0 API, Payment - IFrame/Redirect, and alongside them Payment - Gateway API SANDBOX and Payment - IFrame/Redirect SANDBOX. So both integration models have a separate, declared test variant, which is a genuine advantage on a payments project.

Alongside that there is an older generation: a SOAP service at ws101.pelecard.biz/WebServices.asmx, with operations named things like DebitRegularType. It still appears in third-party libraries and plugins. There is also a public Postman workspace called Pelecard Public, which includes a documentation section named gateway21.

The practical conclusion: if you inherited Pelecard code, the first thing to check is which address it calls. Code hitting WebServices.asmx and code hitting the 2.0 gateway are not two styles of the same thing; they are two different integrations with different error models.

The two interfaces side by side

What costs time when documentation is not accessible up front

• An estimate built on a guess. Without seeing documentation you cannot know whether there are tokens, whether refunds run through the interface, or whether a server notification exists.
• An old library from GitHub. It works against the generation that existed when it was written, not necessarily against what the business is connected to.
• Testing in production. Without a test environment every attempt is a real transaction, a real refund and a real accounting entry.
• Credentials held by the bookkeeper. The terminal number and interface password are usually not with the person who asked for the project.
• Answers instead of errors. Older interfaces sometimes return 200 with an error field in the body, so checking the HTTP status alone will read a failure as a success.

How do you evaluate a provider whose documentation you cannot read in advance?

With written questions, before you give a timeline. These are the ones that change the estimate:

1. Which generation is active on our account, and what is the production base URL we should call?
2. Is there a test environment, and how do we get credentials for it?
3. What does a successful response look like, and a failed one, with a real example of each?
4. Is there stored payment credential support for repeat charging, and through which mechanism?
5. Do refunds run through the interface, and are they partial or full only?
6. Is there a server-to-server notification on transaction completion, or is the browser return the only signal?
7. Who is the technical contact, and what is their response time when something breaks in production?

The answer to question six is the one that decides quality. A system relying only on the browser return will lose orders every time a customer closes the tab early.

What to store regardless of provider

• Your own internal order identifier, created before you call the gateway.
• The amount and currency as sent, alongside the amount that came back.
• The provider's transaction identifier, in a dedicated field and not inside free text.
• The response code and full description as received, including on success.
• Request time and response time, so timeouts are identifiable afterwards.
• The last four digits and the card type only. Never a full card number or a security code.

This describes what is publicly accessible in September 2026. Gateway names, addresses and documentation locations change, and should be confirmed with the provider before implementation.

Related: comparing Israeli payment gateways, turning decline codes into an action, integrating with the Tranzila API.

Sources

• Pelecard - developers page
• Hyp - online payments