Connecting Card Payments to Your Website in Israel (2026): A Practical Guide for WooCommerce, Shopify and WordPress

What "connecting payments to a website" actually involves

Three different companies, or three roles inside one company, sit between your customer's card and your bank account. The acquirer clears the transaction and pays you: in Israel that is Isracard, Max or CAL, and since 2017 also Tranzila, which holds its own acquirer licence from the Bank of Israel. The gateway, or terminal, is the technical layer your site talks to: Tranzila, Cardcom, Hyp (formerly Yaad Sarig), PayPlus or Pelecard. And the payment page is the form where the customer actually types the card number.

With most gateways you sign two agreements: one with the gateway for the terminal, and one with an acquirer for the clearing fee, which is negotiated per business. Bundled providers such as Grow sell both as one product with a published price. I compare those providers and their fees in a separate article on Tranzila, Cardcom and Grow; this one is about the connection itself, the part that decides whether a paid order actually shows up as paid.

What you need before you start

Most delays in a payment project are paperwork, not code. The gateway cannot go live until the clearing agreement is approved, and the plugin cannot be configured until you have the terminal number and API credentials. Get these in hand first:

• A registered business and the bank account the money will be paid into.
• An approved clearing agreement, either directly with an acquirer or through a bundled provider.
• A terminal for online (card-not-present) transactions, with its API keys, plus separate test credentials.
• HTTPS on the whole site, not only on the checkout page.
• An invoicing system that issues the receipt or tax invoice automatically after each payment.
• Decisions on installments, recurring charges and currencies — each one changes which provider and plugin fit.

Invoices and the Israel Invoices allocation number

If you sell to other businesses, the invoice side has a legal deadline attached. Under the Israel Invoices reform, since 1 January 2026 a buyer can deduct input VAT on a transaction above ₪10,000 before VAT only if the tax invoice carries an allocation number issued by the Israel Tax Authority, and since 1 June 2026 the threshold is ₪5,000. The Tax Authority tells businesses that issue invoices through software to make sure their version requests the allocation number automatically.

For a store this means the chain has to be tested as one piece: payment approved, order marked paid, document issued once, allocation number requested where the amount requires it. Morning (formerly Green Invoice) and iCount both publish WooCommerce plugins on WordPress.org, and several gateways issue documents themselves. Pick one system to issue documents — two systems both issuing a receipt for the same order is one of the most common mess-ups I clean up.

Three ways to connect: plugin, hosted payment page, or API

On WooCommerce the usual route is the gateway's own plugin. On WordPress.org, as of 30 September 2026, the Cardcom plugin shows 3,000+ active installations, Hyp's Yaad Sarig plugin 2,000+, PayPlus 1,000+, and iCount's payment plugin 500+. Tranzila and Grow do not list plugins on WordPress.org; they supply their own (Grow's fee page lists its WordPress plugin at a one-time ₪299 before VAT). A plugin that is not on WordPress.org is not a problem in itself, but you update it by hand, so ask how updates are delivered.

Under the plugin, the card form itself comes in one of three shapes. A hosted payment page sends the customer to the provider's page and back. An embedded page shows the provider's form inside your checkout in an iframe, so the customer stays on your site while the card number still goes straight to the provider. A direct API integration puts the card fields in your own code: the most control over design, and by far the most security responsibility. For almost every small or mid-size store I recommend the first or second.

PCI DSS: how much of the card-security burden is yours

PCI DSS is the card industry's security standard, and the way you connect decides which self-assessment questionnaire applies to you. The lightest one, SAQ A, is for merchants whose payment page comes entirely from a PCI-compliant provider. In a February 2025 FAQ the PCI Security Standards Council clarified that a merchant using an embedded iframe must also confirm that "their site is not susceptible to attacks from scripts". If any part of the payment form comes from your own site, SAQ A no longer applies and the questionnaire gets much longer.

The practical rule is simple: card numbers must never touch your server, your database, your logs or your email. That also means no plugin that "saves the card for next time" on your side — saving a card is the provider's job, done with a token. And because an iframe page is only as safe as the scripts around it, keep the checkout page free of chat widgets, heatmaps and marketing tags you do not strictly need.

3D Secure: the extra check and what it costs

EMVCo, the body behind the card standards, describes EMV 3-D Secure as a way for issuers and merchants to prevent card-not-present fraud: the merchant and the card issuer exchange data so the issuer can authenticate the buyer before approving. For some buyers that adds a step, such as a code from the card company's app. Providers price it differently — Grow's published fees list 3DS at ₪2.50 per transaction before VAT — so ask each provider whether it is on by default, what it costs, and what it changes when a customer disputes a charge.

Bit, Apple Pay and Google Pay

Israeli buyers increasingly expect Bit next to the card form, and mobile buyers expect a wallet button. PayPlus lists Bit, Apple Pay and Google Pay among its products, and Grow lists all three on its site as well. What matters for your store is whether they appear inside the same plugin and payment page you are already installing, or need a separate integration — and whether a wallet payment updates the order and issues the document through the same flow as a card. Ask for a demo on a phone, not a screenshot.

Recurring payments and installments

Subscriptions work through tokens: the provider stores the card and gives your store a token it can charge again. Cardcom's plugin describes general-use tokens for recurring charges, Tranzila offers Tranzila Recurring for card and bank standing orders, and Grow supports standing orders. Tokens usually stay with the provider that created them, so switching providers later often means customers re-enter their cards — decide on the provider before you sell the first subscription.

Installments are standard in Israel and priced separately. Grow, for example, publishes its own installment fee table next to its plans. Ask whether installments are charged to you or to the buyer, and test that the plugin shows the number of payments you actually allow.

Shopify: a shorter path, with one fee to check

Shopify Payments is not available in Israel, so every Israeli Shopify store uses a third-party provider. Shopify's list for Israel names Grow, Hyp, PayPlus, Tranzila PayTech and iCount, plus PayPal. On top of the provider's own fees, Shopify charges its own transaction fee when you use a third-party provider: 2% on Basic, 1% on Grow, 0.6% on Advanced and 0.2% on Plus, per its pricing page on 30 September 2026. Some providers add a Shopify surcharge of their own — Grow lists 0.6%.

The connection itself is simpler than on WooCommerce: you install the provider's app and enter the credentials. The checks are the same, though: a real test payment, a refund, and an invoice that is issued once.

Test before you go live

Every serious provider has a test mode. PayPlus says its WooCommerce plugin runs in production or sandbox mode depending on the API keys you enter; Cardcom's plugin sends transactions to a test terminal until you enter your own; Morning's API documentation offers a sandbox. Run these scenarios in test mode, then repeat the key ones with a small real payment that you refund:

• An approved payment: the order moves to paid, stock drops, and the customer gets the confirmation email.
• A declined card: the customer sees a clear message and the order does not turn into paid.
• A customer who closes the payment page halfway: no ghost order marked as paid.
• A 3D Secure challenge on a phone.
• A full and a partial refund, and the credit document that goes with each.
• One invoice or receipt per order — never zero, never two.

Where payment integrations usually break

Most "the customer paid but the order says pending" tickets come from the same few places. The provider confirms a payment by calling your site in the background, and anything that blocks that call leaves the order stuck. Check these before blaming the provider:

• A security plugin, firewall or CDN rule that blocks the provider's background call.
• Page caching on the checkout or thank-you page.
• A return address that still points to http or to an old domain after a migration.
• A currency the terminal is not set up for — Tranzila, for example, clears in shekels or dollars, and other currencies need prior arrangement.
• A plugin that is behind your WordPress version: check the "Tested up to" line on its plugin page after every major update.