Merchant vs acquirer - who really runs a card payment?

• The merchant is closest to the customer, but often furthest from the decision. Declines, disputes and outages can all leave the merchant dealing with the consequences without being able to see exactly what happened.

• Issuer, acquirer and merchant all see a different version of the same payment. The merchant has the basket and customer context, the issuer has the cardholder history, and the acquirer sees the transaction and settlement data. No single party sees the payment end to end.

• Acquirers have more at stake than gateways. Because they carry commercial risk on the merchant, they can respond with reserves, slower settlement, stricter terms or higher fees when that risk changes.

• Visibility becomes more valuable when it leads to action. Aevi’s orchestration platform connects payment ecosystem components that would otherwise sit separately, helping teams spot issues across providers and respond when performance changes or a provider goes down.

Don't have time to read more now? Sign up to our newsletter to get the latest insights directly in your inbox. 

When something goes wrong at a restaurant, the waiter is the person the customer turns to. They didn’t cook the meal, choose the ingredients or write the menu, but they are the one at the table - and they are the one expected to sort it out.

A declined card works the same way. The merchant gets a code on the terminal that explains nothing and is left with two options: try the payment again or ask for another card. It’s the merchant who has to handle it, even though nobody in the building did anything wrong and nobody in the building knows what actually happened.

The customer sees a failed payment, the merchant sees a problem to deal with - but neither can see where the decision came from. That gap between the party making the decision and the party dealing with the fallout isn’t unique to declines, it shows up across the payment journey: from an approval or refund to a dispute or outage. 

Like the waiter, the merchant is the one standing in front of the customer, the one who owns the relationship and the one expected to put things right when something goes wrong. It’s also the one who knows the least about what happened in the kitchen, because a card payment involves far more players than the moment at the counter would suggest.

In this article, we look at five ordinary moments in the life of a card payment and, for each one, who made the decision, who paid for it and who could actually see what happened.

The simplest place to start is a payment that goes through without a problem, because that’s where each party’s role is clearest.

The customer taps or inserts their card. The terminal captures the transaction and sends it through the payment gateway, which passes the payment data into the next part of the chain. So far nothing has moved except information.

The acquirer picks it up next, routing the transaction on behalf of the merchant and handling the merchant side of processing and settlement. It knows the merchant ID, the amount and the transaction details it needs to process the payment, but it never sees what is in the customer’s basket.

The network then carries the message to the issuer. It provides the rails between the two, but the decision on whether the payment goes through belongs to the issuer.

The issuer has the information it uses to make the call: available funds, spending patterns and other signals can all feed into an approval or decline, returned in a fraction of a second. That response travels back through the payment chain to the merchant, which gets the answer but not the reasoning behind it. If the payment is approved, the sale can go ahead and, from the customer’s perspective, that’s the end of it.

For the merchant, the transaction still has to be settled, with fees deducted before they receive the net amount. By then, what started as one very ordinary tap has passed through several different parties - each seeing a slightly different version of the same transaction.

The merchant has the basket and the customer standing in front of them: full context, but little visibility past the point of sale. The issuer has a much richer view of the cardholder, including their spending history, but far less context about the sale itself. The acquirer has the transaction, merchant ID and settlement record, but no idea what was actually sold.

Put those fragments together and you’d have the full picture. No single party has that. This is the crux of the acquirer vs issuer vs merchant problem: three different jobs, three different slices, and no one sees the transaction whole.

We explore this in more detail in our payment data whitepaper, looking at what happens when useful payment information is spread across different providers and systems.

When a payment is declined, the issuer usually knows why. It has the card’s history, the merchant category, the time of day and a range of other signals feeding into its decision. Somewhere in that calculation, something has crossed a threshold. 

The merchant gets the result as a reason code, but that code only tells it as much as the network and issuer choose to reveal, and the acquirer usually has no extra detail to add.

The odd part is that the merchant usually holds exactly the information that would help:

• The customer comes in every Tuesday.
• The basket is the same one they always buy.
• The card worked fine an hour ago.

None of that makes it into the issuer’s decision before the call is made. The merchant has the context but no way to pass it across in time, while the issuer has the decisioning system but a different view of the transaction.

And when the decision turns out to be wrong, the merchant is the one left dealing with it. The sale is lost, while the issuer gets another outcome to feed back into the exact system that just produced the decline. 

For a decision that happens in milliseconds, the consequences are anything but.

Most of the time, the merchant and the acquirer want the same thing: the payment goes through and the money arrives. It’s only when something goes wrong that you start to see they were never quite on the same side to begin with.

A dispute usually arrives weeks after the original payment. The cardholder either doesn’t recognize the charge or isn’t happy with what they received, so they raise it with their issuer, and the money comes straight back out of the merchant’s account.

The merchant then has to build its case from whatever evidence it has: the receipt, proof the order was delivered, the terminal record showing the card was physically present. That goes to the acquirer, which passes it on to the issuer, which weighs that evidence against the cardholder’s version of events and makes the final call.

The merchant was the only party there when the sale happened, so it has the clearest view of what actually took place. But it’s also the party furthest removed from the decision on whether its evidence is enough.

The acquirer has its own stake in all this. As well as moving money for the merchant, it underwrites them, putting its own name behind every transaction that merchant processes. If the merchant takes a payment it shouldn’t have, or racks up chargebacks, or, worst case, goes under with money still owed, the acquirer is the one left carrying the loss. 

That risk is built into the commercial relationship from the start - and is something we recently discussed in our article When BNPL payers can’t pay, who picks up the bill?

A refund can look a lot like a dispute, but it works very differently.

Here the merchant makes the call. There’s no issuer decision to wait for and no dispute process to work through; the merchant tells the acquirer to refund the payment, the acquirer processes it and the issuer puts the money back on the card. Done.

This is one of the few points in the payment chain where the merchant has clear control over what happens next - and it’s no coincidence that this is also the lowest-risk moment for everyone else involved.

What the merchant doesn’t get is a clear view of what that refund actually cost. If it happens before the original transaction has settled, the payment can often be voided, so there’s very little to unwind. Once the transaction has settled, though, the refund becomes a separate transaction heading back the other way - with its own timeline and costs.
Whether the original fees come back depends on the scheme, the timing and the terms of the acquiring agreement. Interchange is sometimes returned, the acquirer’s markup usually isn’t, and some acquirers add a separate fee for processing the refund on top.

The merchant sees the final number in its ledger, but working backwards from that figure to understand where the money went is a very different exercise. 

In an outage, the merchant’s own system is rarely the one that fails. The problem is usually somewhere in the infrastructure it relies on, and when that goes down, cards stop working.

This is the moment a merchant finds out just how much control it actually has. With a single acquirer and gateway, there’s nowhere else for the payment to go, so the merchant is stuck for as long as that provider is down. The queue gets longer, customers get frustrated and the merchant is left with nothing to offer them, just like with the decline.

For the merchant, it makes little difference in the moment which link has failed. Whether it’s the gateway, the acquirer or the issuer, the result is the same: a failed payment. 

The systems further up the chain can see where it happened, but the merchant is left to handle the customer long before it knows what’s actually wrong. 

There’s another part of the merchant-acquirer relationship running underneath all of this: the acquirer has its own risk to manage.

A higher-risk merchant will usually find there are more strings attached to the commercial relationship. The acquirer might hold a reserve, slow down settlement, impose stricter contract terms or simply charge more - all because it’s pricing against risk the merchant can’t even see.

This is where the difference between a merchant acquirer vs payment gateway starts to matter commercially. Some gateways do apply risk-based pricing or extra checks for higher-risk sectors such as crypto, but a gateway does not carry the same commercial risk as the acquirer, so it is not pricing against the merchant’s risk profile in the same way. The acquirer has something to lose, which changes the relationship when the risk starts to look different.

Ultimately, the merchant and the acquirer want the same result when everything is working. But once the risk changes, so do their priorities.

Five ordinary moments, and the same pattern keeps showing up: the merchant is closest to the customer, but often has the least visibility into what’s happening behind the payment.

That makes the merchant vs acquirer question the wrong one - or at least an incomplete one. It’s not really about who does which job. In a card payment, control tends to follow visibility, and that visibility is spread across the chain. No one gets the full picture. 

Each of those gaps is worth something to somebody:

• The merchant doesn’t understand the decline, but the issuer gets another outcome to feed into its decisioning model.
• The merchant can’t see enough of a dispute to know how it was decided, while an entire industry has grown around helping merchants fight them.
• The merchant sees the amount left after a refund, but not always the full detail behind the deductions - which are visible to the party that made them.

Whenever information is held somewhere the merchant can’t see, someone else has a clearer view of what happened.

That’s where orchestration can help close some of those gaps. Aevi’s orchestration platform connects payment ecosystem components that would otherwise sit separately, helping teams bring more of those fragments together. If one acquirer suddenly starts returning more declines or a provider goes down, there’s a better chance of spotting it and doing something about it.

So who really runs a card payment? Nobody, at least not on their own. But the more of the picture you can connect, the less you’re left guessing when something goes wrong.

Talk to Aevi about building a payment setup with more visibility across providers and more options when something doesn’t go to plan.