Recurring Billing in Israel: Cards, Direct Debit and the Invoice Problem

Recurring billing looks like one problem - charge the customer every month - and is actually three: charging reliably, issuing a compliant invoice for every charge, and handling failures that arrive days later. Most implementations solve the first and discover the other two in production.

The two billing routes, and why the difference is fundamental

Israel has two main ways to collect a recurring amount, and they behave entirely differently in engineering terms.

Tokenised card

The customer enters a card once, the gateway stores it and returns you an identifier - a token - and your system charges that token each cycle.

What that gives you:

• An immediate answer. The charge is approved or declined within seconds, and you know at once.
• Card data is not yours. This is the critical point - you hold a meaningless identifier, not a card number.
• Full control over timing.

Bank direct debit mandate

The customer signs a mandate with their bank, and charges are collected directly from the account.

What differs:

• No immediate answer. A rejected charge - a closed account, insufficient funds, a cancelled mandate - can come back to you days after you treated the month as paid.
• Setup is slower and requires a process with the bank.
• There is no expiry date as there is on a card.

The engineering consequence: if you support bank mandates, the system must be able to reverse a month already marked paid. That means a "pending confirmation" status distinct from "paid", and handling the late reversal. Anyone treating the submission as success will find out late.

What your system has to hold

Regardless of the vendor, these entities must exist:

The entity most often skipped is the charge attempt. Without a record per attempt - failures included - you cannot answer "why was this customer not charged this month", and you cannot build a safe resume.

The five problems that show up in production

1. The card expires

This is the largest single cause of recurring revenue loss, and the only one you can see coming.

The card carries an expiry date. If you store it alongside the token, you know months ahead that this subscription is about to break.

What to build: a process that scans active subscriptions whose card is about to expire and asks for an update before the charge that would fail. Reaching out ahead works; reaching out after a failure lands on a customer who already thinks they cancelled.

2. The silent failure

A charge fails, the system writes an error to a log file, and nobody reads it. Two months later you discover a customer has not been paying.

The rule: a failed charge is a business event, not a technical error. It has to reach somewhere a person looks - not a log file.

3. The double charge

The process runs, dies partway, and is run again. Whoever was already charged is charged twice.

The fix: a unique key per charge - subscription plus period. If a success record already exists for that combination, skip. That makes the run safe to repeat, and it is the difference between a system you can re-run and one people are afraid of.

4. A change mid-period

A customer upgrades, downgrades, or cancels on the 14th. What happens to the period already paid for?

That is a business decision, not a technical one - but it must be settled before building, because it changes the data structure. Pro-rating a period requires a different shape from "the change takes effect next cycle".

5. The refund

When money goes back, a credit document is also required - not just an action at the gateway. If refunds happen in the gateway's interface rather than your system, the books will not reconcile.

The other half: the invoice

Every successful charge requires a document. A system that charges without issuing invoices simply moves the manual work to the bookkeeper - and creates a monthly gap someone closes at month end.

The right structure: issuing the invoice is triggered by the charge succeeding, not by a separate schedule. Two independent processes running on the same schedule will diverge - and when they do, you get charges without invoices or invoices without charges.

Two Israel-specific points:

• The allocation number requirement - invoices above a threshold require approval from the Tax Authority before they are valid. What that means for recurring billing: the invoice depends on an external service that can be unavailable, so you need a queue and retry, not a synchronous issue that fails and is forgotten.
• The invoicing system is usually not the gateway - so the two have to be connected.

Why not to build the card handling yourself

Worth being explicit: you build the scheduling, the records and the documents - not the card handling.

The gateway handles the card itself, and that is precisely what keeps card data out of your system. The Israeli gateways - Cardcom, Tranzila, PayPlus and others - offer token mechanisms, each in their own way.

The request shape, the field names and how the token is returned must come from the official documentation of the chosen gateway. There is no shared standard here, and no pattern you can copy from one vendor to another.

Checklist

1. Decide: card, bank mandate, or both. A bank mandate requires supporting late reversal.
2. Store the token and the expiry date.
3. Build expiry monitoring that contacts the customer before the failure.
4. Record every attempt, not only successes.
5. A unique subscription-plus-period key so a re-run does not charge twice.
6. Settle the mid-period change policy before building.
7. Trigger the invoice from charge success, not a separate schedule.
8. Queue and retry the issuing, not a synchronous call.
9. A failed charge reaches a person, not a log file.