| name | tranzila-payment-gateway |
| description | Integrate Tranzila payment processing into Israeli applications -- covers iframe payments, tokenization, installments (tashlumim), refunds, 3D Secure, and Bit wallet. Use when user asks to accept payments via Tranzila, integrate Israeli credit card processing, set up "slikat ashrai", handle tashlumim (installment payments), create payment tokens, process refunds through Tranzila, or mentions "Tranzila", "tranzila API", "secure5", or Israeli online payments. Supports both legacy CGI endpoints and modern API V2. Do NOT use for Cardcom integration (use cardcom-payment-gateway), general accounting, or non-payment financial queries. |
| license | MIT |
| compatibility | Requires network access for Tranzila API calls. Works with Claude Code, Claude.ai, Cursor. |
Tranzila Payment Gateway
Overview
Tranzila is one of Israel's leading payment processors (solek), operating since 1999. It connects to the Shva network (reshet shva) -- Israel's central card processing infrastructure -- and supports all Israeli card issuers: Isracard, Visa Cal, and Max (formerly Leumi Card).
This skill guides integration with Tranzila for accepting credit card payments (slikat kartis ashrai) in Israeli applications.
Official docs: https://docs.tranzila.com/
Test credentials: Visa test card 4444333322221111, Isracard test 12312312, any CVV (e.g. 333), any future expiry. Configure your terminal for sandbox mode via the Tranzila dashboard.
Instructions
Step 1: Choose Integration Pattern
Help the user select the right approach based on their needs:
| Pattern | Hebrew | PCI Scope | Best For |
|---|
| Iframe | daf tashlum mutman | Minimal (SAQ-A) | Quick integration, minimal compliance |
| Hosted Fields | sdot mitarachim | Low (SAQ-A-EP) | Custom checkout UX with low PCI burden |
| API V2 (server-to-server) | sharat le-sharat | Full (SAQ-D) | Token charging, recurring, refunds |
Most Israeli merchants start with Iframe for collecting payments, then use API V2 for server-side operations like token charging and refunds.
Step 2: Set Up Authentication
Tranzila uses different credentials depending on the integration:
For Iframe / Legacy CGI:
supplier -- Terminal name (provided by Tranzila)
TranzilaPW -- Transaction password
For API V2 (api.tranzila.com/v1): authentication is a 4-header HMAC-SHA256 handshake, NOT a single key header. Every request must send all four:
X-tranzila-api-app-key -- your public application key
X-tranzila-api-request-time -- current Unix time in SECONDS
X-tranzila-api-nonce -- a random nonce (about 40 bytes)
X-tranzila-api-access-token -- hmac_sha256(secret + request_time + nonce, app_key) (HMAC-SHA256 of the app key, keyed with secret concatenated with the request-time and nonce)
You get both a public app key and a secret key when you enrol in API V2. A request with only X-tranzila-api-app-key is rejected. (Base URL is https://api.tranzila.com/v1; "API V2" is the auth-generation name, not a /v2 path.) Confirm the exact concatenation order in the Authentication page at docs.tranzila.com before shipping.
Remind the user to store credentials securely (environment variables, secrets manager) and never commit them to source control.
Step 3: Implement the Payment Flow
Option A: Hosted Fields (Recommended for Custom UX)
Hosted Fields let you design your own checkout form while Tranzila securely handles card inputs:
- Include the Tranzila Hosted Fields JS on your page
- Create container
<div> elements for card number, expiry, and CVV
- Initialize fields with your terminal name and styling options
- On submit, the JS generates a
TranzilaTK token without card data touching your server
- Send the token to your backend for charging via API V2
This gives full design control while maintaining SAQ-A-EP PCI compliance. Refer to the Hosted Fields section under https://docs.tranzila.com/ (deep slug paths change frequently; navigate from the Payments & Billing index).
Webhook signature verification. When Tranzila POSTs the result to your notify_url, do NOT trust it on inbound shape alone. Verify by either (a) issuing a follow-up server-to-server confirm API call against tranzila71dt.cgi to confirm the transaction id, or (b) validating the myid you provided round-trips back, or (c) signing your own checksum into the form fields and verifying it on receipt. Without this step, anyone with your notify_url can fake transaction-success callbacks.
Option B: Iframe Integration (Quick Start)
-
Embed the Tranzila iframe in your checkout page:
- URL:
https://direct.tranzila.com/{supplier}/iframenew.php
- Add query parameters:
sum, currency, cred_type
- Default mode creates a token (J5); use J4 for one-time charge
-
Handle the response via your notify_url:
- Tranzila POSTs results to your server
- Check
Response field: 000 = approved
- Store
TranzilaTK (token) for future charges
-
Confirm transaction server-side (recommended):
- Use the three-sided handshake to verify the transaction is genuine
Option C: Server-to-Server via API V2
For token charging, refunds, and operations that don't involve card entry:
Charge a token:
POST https://secure5.tranzila.com/cgi-bin/tranzila31tk.cgi
Content-Type: application/x-www-form-urlencoded
supplier={terminal}&TranzilaPW={password}&TranzilaTK={token}&expdate={MMYY}&sum={amount}¤cy=1&cred_type=1
Process a refund:
Use tranmode=C{index} with the original ConfirmationCode and index from the original transaction.
Consult references/api-parameters.md for the complete parameter reference.
Step 4: Handle Israeli-Specific Payment Types
Israeli payments have unique features that differ from international processing:
Installments (Tashlumim):
- Set
cred_type=8 for regular installments
- Parameters:
npay (number of payments minus 1), fpay (first payment), spay (subsequent payments)
- The sum of
fpay + (npay * spay) must equal the total sum
- Not all terminals are authorized for installments (you get an error if the terminal is not enabled for them; check the exact code in the official table)
Credit Types (cred_type):
| Value | Type | Hebrew |
|---|
| 1 | Regular credit | ashrai ragil |
| 2 | Visa Adif / Amex Credit | |
| 3 | Immediate debit | hiyuv miyadi |
| 5 | Leumi Special | |
| 8 | Installments | tashlumim |
| 9 | Club installments | tashlumei moadan |
Currency codes (matbea):
| Code | Currency | Hebrew |
|---|
| 1 | ILS (Shekel) | shekel chadash |
| 2 | USD | dolar |
| 3 | GBP | lira sterling |
| 7 | EUR | euro |
Israeli ID (teudat zehut):
Some transactions require myid parameter -- a 9-digit Israeli ID number (mispar zehut).
Step 5: Implement Tokenization for Recurring Payments (hora'ot keva)
Tokens (asmachta) let you charge returning customers without handling card data again:
-
Create token during first payment:
- Iframe: Default behavior (J5 mode) returns
TranzilaTK
- API: Use
tranmode=K (token only), VK (verify + token), or AK (charge + token)
-
Store the token securely:
- Token is a 19-character string (last 4 digits match the card)
- Store token, expiry date, and card last-4 in your database
- Token has no value without your terminal credentials
-
Charge the token later:
- Use the
/cgi-bin/tranzila31tk.cgi endpoint
- Include
TranzilaTK, expdate, sum, and currency
Step 6: Add 3D Secure (if required)
3D Secure V2 adds cardholder authentication. Consult references/3ds-flow.md for the full redirect-based flow. Key points:
- 3DS changes the payment flow to include a bank authentication step
- Response includes additional fields for authentication status
- Some Israeli issuers may not support 3DS for all card types
Step 7: Accept Bit Payments
Tranzila supports Bit (Israel's popular mobile payment app) through a dedicated Bit API, not a flag on the card-charge CGI. It has its own Bit - Init and Bit - Refund POST endpoints under https://api.tranzila.com/v1 using the same 4-header HMAC auth as the rest of API V2.
- Call the Bit Init endpoint via the API -- Tranzila returns a Bit payment URL
- Redirect the customer to the Bit URL or display a QR code
- Customer approves payment in the Bit app
- Tranzila sends the result to your
notify_url
- Bit refunds use the dedicated Bit Refund endpoint, not the card refund flow
Bit constraints (from the docs): NIS only, transaction sum must be above 5 NIS, and the merchant needs a Visa or Isracard identifier, Max-only merchants are not offered Bit at this time. Bit does not support Hosted Fields or 3DS. Do not assume a bit=1 / bit_url parameterization on the legacy CGI; use the dedicated Bit API. Refer to https://docs.tranzila.com/docs/payments-billing/dcljft4y7sgj2-bit.
Step 8: Generate Payment Request Links
Payment Requests (TRAPI) let you send payment links via email or SMS without building a checkout page:
- Create a payment request via API with amount, description, and customer contact
- Tranzila generates a secure payment link
- Send the link to the customer (Tranzila can send automatically via email/SMS)
- Customer clicks the link and pays on a Tranzila-hosted page
- You receive the result via webhook
This is useful for invoicing, phone orders, or any scenario where you need to collect payment without an embedded form.
Step 9: Set Up Standing Orders (Recurring Payments)
For automated recurring billing beyond simple token charging, Tranzila offers Standing Orders:
- Create a standing order with payment schedule (amount, frequency, start/end dates)
- Tranzila automatically charges the customer on schedule
- Monitor results via the Reports API or webhook notifications
- Cancel or modify standing orders via API
Standing orders are a paid feature -- contact Tranzila to enable on your terminal. Refer to Tranzila's documentation for detailed standing order setup instructions.
Step 10: Generate Invoices
Tranzila has an Invoicing API for generating digitally-signed tax documents approved by the Israeli Income Tax Authority:
- Create invoices tied to transactions or standalone
- Invoices are digitally signed for tax compliance
- Supports tax invoices, receipts, and credit notes
- Can be auto-generated with PayPal payments
Israel Tax Authority allocation number (mispar haktza'a), mandatory for B2B invoices over thresholds. Since 2025-01-01 the ITA requires every B2B tax invoice over a threshold to carry an allocation number obtained from SHAAM via API. Threshold schedule: NIS 20,000 (from Jan 2025), NIS 10,000 from Jan 2026, NIS 5,000 from Jun 2026. Without the allocation number, the buyer cannot deduct input VAT on the invoice. If you generate invoices through Tranzila's Invoicing API, confirm with Tranzila support that allocation-number requests are wired through SHAAM for invoices at or above the current threshold; if not, fall back to a separate invoicing provider (Green Invoice, Morning, etc.) that does integrate with SHAAM, or request allocation numbers directly via the ITA portal.
Refer to Tranzila's invoicing documentation for the complete invoicing API reference.
Step 11: Handle Errors
Check the Response field in every transaction result. 000 means approved -- anything else is a decline or error.
Important: the HTTP status of an API V2 call is 200 even on a declined/failed transaction. The HTTP 200 does NOT mean success; read the Response / response-code field in the body for the actual SHVA result. And there are TWO separate code spaces: the SHVA/issuer codes (hundreds of codes, e.g. card-issuer refusals are in the 300s, installment errors in the 400s) and a separate 3D-Secure code set (900-930). Do not assume codes from Stripe or other gateways.
A few confirmed codes (verify the rest against references/error-codes.md and the official "Transaction Response Codes" page at docs.tranzila.com):
| Code | Meaning | User Action |
|---|
| 000 | Approved | Transaction completed |
| 004 | Refusal / declined (contact card owner) | Ask user to try another card |
| 036 | Card expired | Ask user to update card details |
| 037 | Installment error (transaction sum must equal first payment + fixed payments times count) | Recompute the installment amounts |
| 900 | 3D Secure authentication failed (3DS code space 900-930) | Re-authenticate or retry without 3DS |
For the full reference (260+ SHVA codes plus the separate 900-930 3DS set), consult references/error-codes.md and verify against the official docs, do NOT hardcode codes from memory.
Examples
Example 1: Accept a One-Time Payment
User says: "I need to add credit card payments to my Node.js checkout page"
Actions:
- Choose: Iframe integration (minimal PCI scope)
- Guide: Embed iframe with supplier name, sum, currency=1 (ILS)
- Implement: Server-side notify_url handler to capture response
- Validate: Check Response=000, store ConfirmationCode
Result: Working checkout that accepts Israeli credit cards via embedded form.
Example 2: Set Up Monthly Subscription
User says: "I want to charge customers 99 NIS every month automatically"
Actions:
- First payment: Iframe with token creation (J5 mode)
- Store: Save TranzilaTK and expdate from response
- Monthly: Cron job calls tranzila31tk.cgi with stored token
- Handle: Check for expired cards, declined tokens
Result: Recurring monthly billing using tokenized cards.
Example 3: Process Installment Payment
User says: "My customer wants to pay 6,000 NIS in 3 tashlumim"
Actions:
- Set: cred_type=8 (installments)
- Calculate: fpay=2000, spay=2000, npay=2 (3 payments total)
- Verify: Terminal authorized for installments
- Process: Transaction with installment parameters
Result: Payment split into 3 equal installments of 2,000 NIS.
Example 4: Refund a Transaction
User says: "I need to refund transaction from last week, confirmation code 0283456"
Actions:
- Use: tranmode=C0 (cancel first transaction in batch)
- Include: Original ConfirmationCode and index
- Set: sum to refund amount (partial or full)
- Verify: Response=000 for successful refund
Result: Refund processed and linked to original transaction.
Example 5: Accept Bit Payment
User says: "I want to let customers pay with Bit on my website"
Actions:
- Call the dedicated Bit Init endpoint (api.tranzila.com/v1, 4-header HMAC auth) -- not a flag on the card CGI
- Redirect: Send customer to the Bit payment URL from the response (or show a QR)
- Handle: Receive payment confirmation at notify_url
- Verify: Check the response code for a successful Bit payment
- Note constraints: NIS only, sum > 5 NIS, merchant needs a Visa/Isracard identifier (Max-only merchants not supported)
Result: Customers can pay using Israel's Bit mobile wallet alongside credit cards.
Example 6: Send Payment Link via SMS
User says: "I need to collect payment from a customer over the phone"
Actions:
- Create: Payment request via TRAPI with amount and customer phone number
- Send: Tranzila sends SMS with payment link automatically
- Wait: Customer opens link and pays on Tranzila's hosted page
- Confirm: Receive webhook notification when payment completes
Result: Payment collected remotely without building a checkout page.
Community Libraries
- tranzilajs (TypeScript/Node.js) -- Modern SDK with HMAC auth, Bit payments, credit card ops, iframe generation. Install:
npm install tranzilajs. See: https://github.com/NirTatcher/tranzilajs
- omnipay-tranzila (PHP/Omnipay) -- Community gateway plugin
- active_merchant_tranzila (Ruby) -- ActiveMerchant gateway adapter
Bundled Resources
References
references/api-parameters.md -- Complete Tranzila API parameter reference for both legacy CGI and API V2 endpoints, including authentication headers, transaction parameters, token operations, and installment fields. Consult when constructing API requests or debugging unexpected parameter behavior.
references/error-codes.md -- Full listing of Tranzila response codes (000-999) with meanings and recommended handling. Consult when a transaction returns a non-000 response code.
references/3ds-flow.md -- Step-by-step 3D Secure V2 implementation guide for Tranzila, including redirect flow, authentication parameters, and fallback handling. Consult when adding 3DS to an existing integration.
Scripts
scripts/validate_tranzila_response.py -- Validates a Tranzila transaction response: checks response code, verifies required fields are present, and flags common issues (missing confirmation code, mismatched amounts). Run: python scripts/validate_tranzila_response.py --help
Gotchas
- Tranzila API uses form-encoded key-value pairs (not JSON). Agents default to JSON request bodies, which Tranzila will reject or ignore. Send requests as
application/x-www-form-urlencoded.
- Tranzila's test mode uses the same endpoint as production but with a different
supplier parameter. Agents may accidentally send test transactions to the production terminal or vice versa.
- The response format from Tranzila is a plain-text key=value string separated by newlines, not JSON. Agents may try to
JSON.parse() the response, which will throw an error.
- Israeli credit card numbers have different BIN ranges than US/European cards. Tranzila validates cards locally, so test cards from Stripe or other international gateways will not work.
Reference Links
Troubleshooting
Error: "Transaction rejected with a non-000 response code"
Cause: Missing or invalid parameters, a card-issuer decline, or a config/permission issue. Remember the HTTP status is 200 even on failure, read the Response field for the actual code.
Solution: Verify all required parameters are present: supplier, TranzilaPW, sum, ccno (or TranzilaTK), expdate. Check parameter names are exact (case-sensitive). Look up the exact response code in the official Transaction Response Codes page (see references/error-codes.md), do not guess its meaning.
Error: "Terminal not authorized for installments / Amex"
Cause: Your Tranzila terminal does not have installment (or Amex) permissions enabled.
Solution: Contact Tranzila support (073-222-4444) to enable installment or Amex processing on your terminal.
Error: "Token charge fails but iframe worked"
Cause: Common when using wrong endpoint or missing expdate
Solution: Token charges use /cgi-bin/tranzila31tk.cgi (not tranzila31.cgi). Include both TranzilaTK and expdate parameters.
Error: "Transaction approved in test but not production"
Cause: Test and production terminals behave differently
Solution: Verify your production terminal name and password. Some operations (like void) behave differently in production. Check with Tranzila support if behavior diverges.
Error: "Currency mismatch"
Cause: Using wrong endpoint for currency
Solution: ILS and USD use tranzila31.cgi. Multi-currency (EUR, GBP, etc.) requires tranzila36a.cgi.