PaymentHood 4 October 2026 payments orchestration

Three weeks after a sale, your store still shows it as paid and fulfilled. Nothing in your admin panel has changed. Then finance notices a debit on the payout report that doesn’t match any refund you issued, and when someone finally traces it, it turns out to be a chargeback: the customer disputed the charge with their bank, the bank pulled the money back through the card network, and the provider deducted it from your next payout along with a fee. Nobody told your store, because nothing in your store was built to listen.

That gap, between what the card network did three weeks ago and what your order record still says today, is the actual problem. The money has already moved by the time most merchants find out.

Why chargebacks are easy to miss

A refund is something you choose to do, inside your own system, so it shows up where you’d expect. A chargeback is something the customer’s bank does, inside the card network, and it reaches you as a side effect: a notification from the provider, a deduction on a payout, sometimes nothing but a line in a report you don’t check daily. A few things make this worse than it needs to be:

• It arrives at the provider, not your store. Unless you’re specifically listening for dispute events (not just payment.succeeded or charge.refunded), a chargeback can happen with zero signal inside your own system.
• The order is long gone. By the time a dispute lands, the goods have shipped, the subscription has renewed twice, the support ticket is closed. Nothing about the order looked wrong when it happened.
• Every provider reports it differently. One sends a webhook event the moment a dispute opens; another only reflects it as a negative line in the payout settlement file, days later, with no event at all. If you run more than one provider, you’re watching for a signal that doesn’t look the same twice.
• The clock is short and provider-specific. Most card networks give you a matter of days to submit evidence before the dispute is decided by default, and that window starts when the provider receives it, not when you notice.
• Representment needs evidence you may not have kept. Proof of delivery, IP address at checkout, communication history, useful only if someone decided in advance to keep it attached to the order, not scattered across three systems.

None of this means your checkout is doing anything wrong. A chargeback can follow a completely legitimate payment: the cardholder genuinely didn’t recognise the transaction, a family member used the card, or they simply found disputing faster than contacting support. It’s a cost of taking cards, not a sign of fraud.

How to diagnose it

Before assuming you have a chargeback problem, find out what shape it actually has:

• Pull dispute counts per provider, not combined. A blended chargeback rate hides a provider-specific spike, and card networks measure that ratio per acquiring relationship, not per your business as a whole.
• Separate fraud disputes from service disputes. “I didn’t authorise this” and “I didn’t receive this” need different fixes; lumping them together points you at the wrong one.
• Check how long it took you to notice, not just to resolve. If the gap between the dispute opening and someone on your side seeing it is measured in days, the detection step is the actual problem, not the response.
• Confirm you’re actually capturing dispute webhooks, where the provider supports them, rather than relying on spotting them in a settlement report after the fact.

How to fix it

• Treat dispute events as a first-class state, per provider. disputed, under_review, won, lost deserve the same handling as paid and refunded, not an afterthought bolted onto whichever field happened to be free.
• Attach evidence at the time of the order, not the time of the dispute. Proof of delivery, device and IP data, and the customer’s order history are cheap to keep attached to the order and expensive to reconstruct three weeks later.
• Respond inside the window, every time. A representment submitted on time with mediocre evidence often beats a strong case submitted late, because a missed deadline is an automatic loss regardless of merit.
• Tighten the obvious triggers. Clear billing descriptors, delivery confirmation, and a visible way to contact support before a customer gives up and disputes instead. Most disputes are a customer choosing the bank over your support inbox because it was the easier path.
• Watch your ratio against network thresholds. Visa and Mastercard both run monitoring programmes that escalate once your dispute ratio crosses a threshold, and the penalties, fees and reserves and eventually losing the ability to accept cards, are worse than any individual chargeback.

Why more than one provider makes this harder

With a single provider, dispute handling is at least contained: one dashboard, one notification format, one evidence submission flow to learn. Add a second provider for currency coverage or failover and you’ve added a second dispute process with its own event names, its own evidence format, and its own deadline, running in parallel with the first. Someone now has to check two places to be sure they haven’t missed one, and that’s the version with only two providers.

This is the same shape of problem as reconciliation across providers: each provider is internally consistent and externally incompatible with the others. The fix is the same too: normalise at the point of capture. Every payment gets one internal record the moment it’s made, and when a dispute arrives against it, from whichever provider, it updates that one record instead of starting a parallel paper trail per provider.

Where PaymentHood fits

PaymentHood keeps one transaction ledger across every connected provider, so a dispute against a payment updates the same order record regardless of which provider processed it, and there’s no separate dispute trail per provider to remember to check. Because every payment already carries your order reference and its provider-side identifier, tracing a dispute back to what was actually ordered, shipped and said to the customer doesn’t depend on reconstructing a join key weeks later.

This sits on top of the same server-side verification and webhook handling used across 30+ supported providers, through one integration, with free plugins for the major carts and billing systems. There is no per-transaction fee from PaymentHood, so a dispute does not cost you a platform cut on top of the chargeback fee itself.

Most sellers end up running more than one provider eventually, whether for currency coverage or redundancy, and chargebacks are one more process that quietly forks per provider unless something unifies it. That is the same argument as payment orchestration generally: disputes, like reconciliation, become a single process instead of one per provider.

Frequently asked questions

What is a chargeback? A chargeback is the customer’s bank reversing a card payment after the fact, at the customer’s request, through the card network. It is not a refund: you did not choose it, it arrives from outside your system, and it usually carries a fee on top of the reversed amount.

Why do chargebacks get missed? Because the notice arrives at the provider rather than in your store. Unless you are listening for dispute events specifically, a chargeback can run its whole course with no signal in your own admin, and the evidence window closes by default.

Does running several providers make chargebacks worse? It makes them easier to miss. Each provider has its own event names, its own evidence format and its own deadline, so someone has to check every provider separately to be sure nothing was missed. The dispute rate itself is driven by your customers and your delivery, not by how many providers you run.

How do I stop missing them? Capture dispute events as a first-class state per provider, attach the evidence to the order when the order is placed rather than when the dispute arrives, and normalise everything into one record so a dispute updates the payment it belongs to.

Create a free PaymentHood account, or browse the provider directory to see which providers you could bring under one ledger.

All articles