Pelecard Payment Gateway

Problem

Pelecard is a Payment Service Provider (PSP) that aggregates Israeli merchants onto the card acquirers over Shva, but its public documentation is scattered across a Postman workspace, a sandbox UI, a WordPress plugin listing and third-party PHP libraries, with no single canonical reference. Agents integrating Pelecard end up treating the hostname as an environment switch (it is not), inventing a refund endpoint that does not exist, picking the wrong ActionType (which silently changes whether money moves), or trusting a browser-side ConfirmationKey instead of re-verifying server-side. Each mistake leaks revenue or ships an exploitable "free order" path.

Overview

Card transactions clear on the Israeli Shva network (https://www.shva.co.il/, שב"א); Pelecard handles merchant onboarding, the iframe surface, tokenization and reconciliation on top. Your acquirer, not Pelecard, answers the PCI-tier and broadcast-policy questions below.

Pelecard's dominant integration is an iframe payment page: your server posts a credentials triple (terminal + user + password) plus the transaction parameters, gets back a URL and a ConfirmationKey, and redirects or embeds it. After the customer pays, Pelecard calls your server-side feedback URL. Store the Phase-1 ConfirmationKey keyed by your order; on the callback you MUST (a) match it byte-for-byte and (b) re-call PaymentGW/GetTransaction before treating the order as paid.

Pelecard has two server-to-server surfaces with different parameter-naming conventions. /PaymentGW/* is the iframe surface and has exactly three endpoints. /services/* is where every other operation lives: charges on a saved token, authorizations, voids, tokens, lookups, settlement, 3DS, invoices. Pelecard publishes a live request builder for them at https://gateway21.pelecard.biz/services with a preset body for each; that page is the authoritative endpoint reference, ahead of any third-party wrapper.