How We Got Revolut Chargebacks into Monday.com and WooCommerce

Chargebacks are rare. That’s part of the problem.

An order comes in, gets picked, gets shipped, and everyone moves on. Then weeks later the payment gets disputed, and someone has to work out which sale it was, why the customer disputed it, and how long there is to respond. All of that lives in the payment provider. None of it lives where the team actually works.

That was the situation for a UK-based manufacturer we work with. Disputes sat in Revolut. Case tracking ran on Monday.com. Orders ran on WooCommerce. Three systems, no connection between them, and every dispute needing a bit of manual detective work before anyone could act on it.

So we built an n8n workflow to join them up.

The awkward part

Revolut’s Merchant API is good. It returns everything you’d want about a dispute: state and substate, response deadline, reason code and description, disputed amount and currency, related payment and order identifiers, card details, timestamps.

What it doesn’t return is the client’s own order number.

That’s the number Customer Care actually uses. It’s on the paperwork, the warehouse references it, and it’s what someone types into WooCommerce to pull up a sale. Revolut knows the order by its own UUID, which means nothing to anyone in the building.

So before any of this data was useful, the workflow had to bridge that gap.

The fix is a second API call. Take the Revolut order UUID from the dispute, fetch the full order, and read merchant_order_data.reference. That gives back the internal order number in the format the team recognises. The same call also returns the customer name at order level, with the cardholder name as a fallback when it’s missing.

One extra request, and the dispute stops being an abstract payment event and becomes a specific sale someone can look up.

What the workflow does

It runs every 30 minutes and treats Revolut as the source of truth. Five steps:

1. Pull all current and historical disputes from the Revolut Merchant API.
2. For each one, load the related Revolut order.
3. Pull out the internal order reference and customer name.
4. Create or update the matching item in Monday.com.
5. Find the matching WooCommerce order and sync the chargeback data onto it.

Why it’s read-only

Revolut access is strictly read-only. The workflow can fetch disputes and orders. That’s it. It has no ability to accept a dispute, upload evidence, issue a refund or challenge a chargeback.

This was deliberate and it’s worth being blunt about: an automation that can accept a chargeback on your behalf is a bad idea. Disputes involve money and deadlines, and a scheduled job running every half hour is exactly the kind of thing you don’t want anywhere near an irreversible financial decision. Monitoring and acting are different jobs. This one only monitors.

The Monday.com board

Every dispute becomes one item on a dedicated Revolut Chargebacks board.

The item name is the internal order number, so Customer Care can search for what they already know. Alongside it sits the dispute ID, state, substate, deadline, amounts, reason, payment references, customer name and sync timestamps.

States map to four labels people can actually filter on: Needs Response, Under Review, Won, Lost. There’s a fifth, Unknown, which catches anything Revolut introduces later that we haven’t mapped yet.

The full dispute payload also gets stored as formatted JSON in a long-text field. Partly that’s an audit trail. Mostly it’s insurance: when Revolut adds a field we haven’t built a column for, the data is still captured rather than silently dropped.

Deduplication uses the Revolut dispute UUID, not the order number. The dispute ID never changes, so the workflow can be rerun by hand without creating duplicates.

The WooCommerce side

Monday.com gives the team the overview. But when someone wants to look at one specific order, WooCommerce is where they go.

The client already had a custom authenticated endpoint that finds an order by its sequential internal number, which saved us building one. The workflow calls it, resolves the real WooCommerce order ID, and writes a controlled set of metadata: chargeback state, substate, dispute ID, reason code, reason text, response deadline, and both the Revolut update time and our last sync time.

On top of that sits a small HPOS-compatible plugin that renders it as a read-only panel on the order screen, plus a status badge in the orders list.

One thing we deliberately didn’t do: touch the WooCommerce order status. A chargeback is a payment dispute, not a fulfilment state. Folding it into order status would have meant stock movements, customer emails, reporting and fulfilment logic all reacting to something that has nothing to do with whether the goods shipped. Keeping them separate is less elegant on paper and much safer in practice.

Keeping it quiet

Running every 30 minutes means 48 executions a day. If each one wrote to both destinations regardless of whether anything had changed, the order history would be unreadable within a week.

So the workflow compares what Revolut returns against what’s already stored, and writes nothing when nothing has changed. In practice:

• State changed, so update the metadata and add a private order note.
• Substate, deadline, reason or timestamp changed, so update the metadata with no note.
• Nothing changed, so no write at all, to either system.
• A dispute that closes as Won syncs once, then stays untouched.

The notes are private, staff-only, and read like Revolut chargeback changed from Under Review to Won. Customers never see them.

What the team ended up with

All chargebacks in one Monday board, searchable by the order number they already use. Filterable by state and response deadline. Reason, amount and payment details visible without logging into Revolut. Current dispute status showing directly on the WooCommerce order. A history of state changes in the order notes.

And the boundaries stayed where they should be. Revolut is still the authoritative payment system. Monday.com handles team visibility. WooCommerce shows order-level context. Nothing pretends to own data it shouldn’t.

The stack

• n8n for orchestration, scheduling, transformation and conditional logic
• Revolut Merchant API for dispute and order data, read-only
• Monday.com GraphQL API for board items and status updates
• WooCommerce REST API for order lookup, metadata sync and private notes
• WordPress and WooCommerce HPOS for the staff-facing display

The part that took the thinking

Moving data between two APIs is the easy bit. The work that actually mattered here was deciding which system owns which piece of information, working out how identifiers in one platform map to identifiers in another, and making sure a scheduled job couldn’t quietly cause damage while nobody was watching.

If your team is tracking payment disputes, refunds or other operational exceptions across systems that don’t talk to each other, get in touch.

---

RemoteMage builds automation and integration systems for ecommerce and operations teams. We work with Magento, WooCommerce, n8n, and a wide range of business platforms.