Issuer, acquirer, Shva and gateway - who approves a transaction, who holds the money, who blocks it, and who to call when a charge declines or a deposit is late.
Key takeaways
- The provider you signed with is not necessarily the one holding your money.
- Approval or decline comes from the issuer. The payment provider only relays the answer.
- Shva is the infrastructure linking points of sale, clearing interfaces, acquirers and issuers.
- A late deposit and a declined transaction are two different problems, handled by two different parties.
An Israeli card transaction involves four parties, not one: the issuer that gave the customer the card, the acquirer that passes you the money, Shva that routes the transaction through the national infrastructure, and the payment provider that gives you the checkout page and the reports. Anyone who does not know who does what calls the wrong party at exactly the wrong moment.
Who does what in the chain
| Party | What it does | What it does not do |
|---|---|---|
| The issuer | Issued the card to the customer; approves or declines the charge per limit and policy | Does not discuss your agreement with you |
| The acquirer | Receives the transaction from the merchant and moves money to the account | Does not decide whether the customer is approved |
| Shva | Routes card transactions; links POS, the Ashrait software, clearing interfaces, acquirers and issuers | Is not a party to your commercial agreement |
| The payment provider | Checkout page, API, virtual terminal, reports, tokens, modules | Is not necessarily the party holding the money |
| You | The merchant. Responsible for the customer's document and for reconciliation | Cannot see the issuer's policy |
Shva's own site also presents its products - the Ashrait clearing software to the EMV standard, 3DSecure, standing orders, Tap on Phone, closed-loop payments for food cards and gift vouchers, and an aggregate data system. That explains why some of what looks like a feature of your provider is in fact a layer in the infrastructure.
Who to call, by symptom
This is the table worth printing:
| The symptom | Who to contact | Why |
|---|---|---|
| One customer's transaction declined | The customer, with their issuer | The decision is the issuer's, usually a limit or a block |
| Every transaction is declining | Your payment provider | A sign of configuration, terminal or a fault on your side |
| Transactions clear but the deposit has not arrived | The acquirer or the provider, whoever holds the money | This is settlement timing or a delay, not approval |
| Funds held or the account frozen | Whoever holds the money - establish who that is | This is a risk decision, not a bug |
| A customer disputes a transaction | The provider, then via the acquirer | There is a process and documents to produce |
| The report total does not match the bank | Your provider, with the file in hand | The gap is usually fees, refunds or instalments |
| The checkout page will not load | The provider, or whoever maintains the store | This is the integration layer |
The fourth row is the one that creates panic. Held funds are usually a risk decision by whoever holds them, and the first step is establishing exactly who that is - and having it in the agreement in advance. So it is worth establishing on signing day who holds the money on your rail - that single question decides who you call.
Why sort this out before you are stuck?
Because in real time there is no time to work out architecture. Three questions worth answering calmly, on signing day:
- Who is my acquirer? Not the payment provider - the acquirer. Sometimes it is the same company, sometimes not.
- Does money arrive in my bank account or into a balance at the provider? Both models work, but the address in a crisis differs.
- What is the support response time, and on which channel? A business clearing on a Saturday night needs to know what happens on a Saturday night.
Those answers also change how monthly reconciliation works. A model where money sits at the provider creates two report sources, and therefore two checks - as set out in options for reconciling card transactions.
One page worth preparing in advance
Prepare a single document before there is a problem, and keep it somewhere findable by people who never signed the agreement. These are the lines:
- The acquirer's name and the payment provider's name - separately, even if they are the same company.
- The merchant number and the terminal number, per terminal.
- The support contact and channel, including what happens outside business hours.
- Who holds the money on your rail, and the deposit date in the agreement.
- Who internally is authorised to approve a refund, and who is authorised to contact the provider.
- The company or person maintaining the connection to your store or system.
- Where the agreement itself is kept, and when it renews.
The last line is the one that surprises people. A business that discovers its renewal terms on the day it wants to switch provider has discovered them too late.
Decline codes: why this is not "a clearing fault"
When a transaction declines, the returned code comes from the issuer side rather than from your provider. That is why you have no way to fix it in your system: you are seeing the result of a decision made elsewhere. What is in your hands is how the system responds - whether it offers another payment method, whether it retries, and what the customer reads on screen.
So the two things worth knowing are the codes themselves and what to do with them in process. The detail is in the Cardcom and Tranzila decline code workflow and the checklist for a transaction declined with code 12.
Three mistakes that come from confusing the parties
- Calling the payment provider when one customer declines. The provider will see exactly what you see: a code returned by the issuer. Time passes and the customer waits. The right move is to offer another payment method immediately.
- Retrying the same card repeatedly. Repeated attempts on a declined card can read as suspicious behaviour on the issuer side, and sometimes make the situation worse rather than resolving it.
- Promising a customer their refund "within a day". Refund timing is set by the rail, not by you, and it can differ from normal settlement. A promise outside your control turns an operational problem into a service problem.
All three share one root: assuming the payment provider controls the whole chain. It does not, and that is fine - you only need to know who to approach instead.
Sources
Frequently asked questions
Is my payment provider the credit card company?
Not necessarily, and that is the important distinction. The credit card company that issued the customer's card is the issuer; whoever moves the money to you is the acquirer; and whoever gave you the checkout page and the reports is the payment provider. Sometimes several roles sit in one company.
What is Shva and why does it appear in a clearing context?
Shva is Automated Bank Services, the infrastructure that routes Israeli card transactions and links points of sale, clearing interfaces, acquirers and issuers. It also develops products such as the Ashrait clearing software to the EMV standard, 3DSecure, and a standing-order solution.
A customer's transaction declined. Can I do anything?
You can change the process, not the decision. The decision belongs to the issuer and usually concerns a limit, a block or authentication. What is in your hands: offer another payment method on the same screen, avoid retrying the same card repeatedly, and show the customer a message directing them to their issuer.
The deposit has not arrived. Who do I contact first?
Whoever holds the money, which is why you need to know who that is. If funds move from the acquirer to the bank directly, contact them or the provider intermediating. If it sits in a balance at the provider, contact the provider. In both cases, start by checking the deposit date in the agreement.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
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.