Choosing a Provider for Recurring Charges in Israel: The Non-Negotiables

In a subscription business the system is not judged by the charge that succeeds but by the one that fails. Five things must exist: a token holding the card, a mechanism for an expired card, charge retries, a failure report somebody actually sees, and a deliberate decision between card and Masav collection. A system missing any one of them produces quiet churn.

The five capabilities not to compromise on

The second row is worth the most money and is usually not asked about. A subscriber lost to card expiry is a customer who never decided to leave - they churned because of a date. Some systems present automatic card updating explicitly; PayPlus, for example, lists it on its standing-orders page alongside handling invalid orders and bad card numbers.

Cards or Masav: how to decide?

This is not a technical question but a question about your audience:

• Collect by card when the audience is consumer, sign-up must be immediate and online, and amounts vary month to month. Sign-up is easy; the price is card expiry, credit limits and declines.
• Collect by Masav when the audience is used to bank mandates, the amount is fixed and the relationship is long-term: building committees, educational institutions, nonprofits with regular donors, professional associations. Sign-up is heavier; the price is process, and the return is stability.
• Collect by both when you have two customer types. Some providers support this in one system, which beats running two in parallel.

What to know before choosing Masav: it is a process, not a button. It needs an arrangement, mandate collection, charge files and return-file handling. The full comparison is in Masav versus card charging, and what happens when a file comes back is in the Masav return file and updating customer debt.

What to ask in a demo, instead of watching a deck

1. Show me an existing subscriber. What do I see about them on one screen.
2. Show me this month's failed-charge report.
3. What happens when a card expires - demonstrate the alert.
4. How many retries are configured, and who configures them.
5. How do I pause a subscription for two months and resume it without losing history.
6. What does changing the amount on an existing subscription look like, and what does the customer receive.
7. If I raise the price for all subscribers - what is the process.
8. Where is the invoice created, and what happens if it fails after the charge succeeded.

Question eight exposes a common gap: a successful charge with no invoice leaves a customer who paid and has no document, and that surfaces only when they ask for it. Connecting that flow is covered in payment-to-invoice automation in Israel.

Changing the price for existing subscribers: where it breaks

Raising a price is the most failure-prone operation in a subscription business, and it breaks in three places:

• Advance notice. The customer should learn about it before the charge rather than from it. Notice that arrives after the money has gone turns a price change into a complaint.
• Legacy subscribers on other terms. Almost every business discovers a group on a historical price. A system that cannot exclude a group forces you to do it by hand, and then somebody misses a row.
• A jump in the failure rate. A higher amount declines more often, especially on small credit limits. It looks like a technical fault and is actually a result of the change.

So run a price change in groups rather than all at once, and measure the success rate after the first group. If it collapses, better to find out on a tenth of your subscribers.

What must stay with you

Even with an external system, the information should be yours in an exportable copy: an internal customer identifier, start date, amount, frequency, currency, charge history, the current state of each subscription, and the record of the customer's consent to recurring charging - when, and through which channel.

The last item is the only one that cannot be reconstructed after the fact. When a customer says they never authorised a recurring charge, the answer needs to be a dated record. That is also why it is worth checking in advance how the system records consent and how you retrieve it.

What goes wrong, and how you find out

• A subscription enters with broken data and never charges. Found only by a report comparing active subscribers against charges made.
• A retry fails silently because the alert goes to a shared mailbox. Found by looking at charge counts against last month.
• A cancelled subscription still counts as active in system fees. Found only when somebody reads the provider's invoice.
• Failures rise after a price change. Found by comparing the success rate before and after.
• A refund issued outside the system with no link to the original transaction. Found in monthly reconciliation.

All five share one key: a single metric checked every month - the share of successful charges out of active subscribers. Checked monthly, it surfaces all of these before they accumulate.

Sources

• PayPlus - standing order management system
• Shva - standing orders and payment infrastructure
• Cardcom - standing order charging