Checkout abandonment in Israel is usually operational: a missing payment method, no instalments, an extra field, an unclear error, or 3DS. What to fix first.
Key takeaways
- The most common cause in Israel is a missing payment method, not price.
- Instalments are an expectation, not a perk. A page without them loses the large transactions specifically.
- 3DS adds a step, and it is also what shifts some chargeback exposure. The question is how it is presented.
- You cannot fix what you do not measure: you need a report comparing transactions opened against completed.
A customer who reached the payment page has already decided to buy. If they left there, it is almost always operational rather than commercial: the payment method they wanted was missing, there was no option to split into instalments, there was an unnecessary field, the authentication step lost them, or the error they got did not tell them what to do.
The seven causes, by frequency
| Cause | How to spot it | What to do |
|---|---|---|
| Missing payment method | Enquiries asking "can I pay with Bit?" | Add Bit and digital wallets to the plan |
| No instalments | Abandonment concentrated in large transactions | Establish with the acquirer what is available, and show it |
| Unnecessary fields | Fields not required to charge | Delete every field not needed for charging or delivery |
| Authentication failure | Transactions stalling at the intermediate step | Check how 3DS is presented, and what the customer reads |
| An unclear error | A decline code shown raw | Replace with a message that offers an action: try another card |
| A slow mobile page | Load time over a few seconds | Reduce scripts on the payment page |
| Lack of trust | A page that looks unrelated to the site | Brand the provider's page, show business details and terms |
Why does 3DS lose transactions, and why do you still want it?
3D Secure is an additional authentication step against the issuer, and Shva presents it as a product in the Israeli infrastructure. It inserts a screen between the customer and approval - which makes it a place people stop: a message that never arrives, a code that arrives late, or a screen that looks suspicious to a customer who has not seen it before.
The other side: authentication is what shifts some chargeback exposure, and it is usually a requirement rather than a choice for online transactions.
What is in your hands:
- Say on the page in advance that a verification code will be sent, so the screen does not surprise anyone.
- Do not close the window automatically after a short timeout.
- Allow a retry without re-entering everything.
- Test the flow on mobile, because that is where most people pay and where switching between apps is confusing.
What to measure before changing anything
Without measurement you will fix what is most visible rather than what is most expensive. Three numbers are enough:
- How many transactions opened against how many completed, by day.
- A breakdown of failures by decline code - limit, invalid card, authentication.
- Completion rate on mobile against desktop, separately. A large gap points at the page rather than the payment method.
The breakdown by code is what aims the fix: codes about credit limits are not your problem, while codes repeating on the same card type are. The detail is in the decline code workflow and the code 12 checklist.
What to fix first, in this order
- Add the missing payment methods - Bit and digital wallets.
- Confirm instalments are shown, and in how many payments.
- Delete fields that are not required.
- Rewrite error messages so each one offers an action.
- Test the page on mobile, including with the keyboard open.
- Add a simple opened-versus-completed report.
The order is not accidental: the first four are changes measured in hours, and they are also what returns the most. Redesigning the page comes last because it is expensive and almost never the problem.
Fields: what a payment page in Israel actually needs
The fastest way to raise completion is to delete. Go through the page and ask of every field: without it, can we charge or deliver.
- Almost always needed: amount, card details, cardholder name, and one way to make contact - phone or email.
- Sometimes needed: an ID number, where the acquirer or the transaction type requires it; an address, where there is physical delivery.
- Almost never needed on the payment page: a full address for a digital product, date of birth, a company name on a consumer transaction, a "how did you hear about us" field, and notes.
- Never: a field somebody added once for marketing research whose answers nobody reads any more.
Five deleted fields are five fewer places to mistype on a mobile keyboard. And it is a change you can make today, with no developer.
What not to do
- Do not blame price before checking the operational causes. A customer who reached checkout has seen the price.
- Do not add a discount to compensate for a technical failure. It hides the problem and costs money.
- Do not send an automatic reminder to abandoners without knowing why - if the payment page is broken, the reminder returns them to the same wall.
- Do not retry the same card repeatedly from your side. It does not help and it looks anomalous to the issuer.
What to do with abandoners
Before switching on automatic reminders, separate three situations - they need completely different handling:
| Situation | What happened | What to send |
|---|---|---|
| Left before attempting payment | Hesitated, or found no suitable payment method | A reminder highlighting the available payment methods |
| Attempted and was declined | A decline code from the issuer | A message offering another card or method, without blame |
| Paid and saw no confirmation | The notification never arrived, or the page closed | Confirmation and the document, immediately - not a reminder |
The third is the worst of them: a payment reminder sent to someone who already paid damages trust rather than merely annoying. So any reminder system has to check whether payment was received before it sends.
Sources
Frequently asked questions
What is the most common cause of abandonment in Israel?
The absence of the payment method the customer wanted, led by Bit and digital wallets. It usually surfaces in enquiries rather than in reports, so it is worth asking customer service what people request - the fastest way to find the gap.
Do instalments really matter?
On large transactions, enormously. Israeli consumers are used to splitting payments, and a page that does not offer it defers the decision. What is available to you is set with your acquirer, so it is an agreement question rather than a page question - see [how instalments work operationally](/blog/installments-operations-israel).
How do I know whether the problem is the page or the payment method?
In the breakdown: many transactions opened and not completed with no decline code points at the page or authentication. Many decline codes point at cards or limits. The two look identical in a sales report and are completely different to handle.
Is redesigning the payment page worth it?
Usually not, and certainly not first. Operational changes - payment methods, instalments, fields and messages - return more and cost less. A redesign is worth it when the page is not branded at all and looks disconnected from the site, because then it is a trust question.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.