Sort payment disputes from your payment system
Start a request from your payment or order system for each disputed charge, route it, and give every fraud claim to a person.
Product screen with sample data. Intake is the previous working name.
The incoming request
A sample request:
“There is a charge of EUR 45 on my card from your shop. I paid once, but I see it twice.”
Customers dispute a charge in your payment or order system. That system already knows the order and the amount. It starts a request in ClientStack through the API, passes the customer's words as the first answer, and reads the outcome when the request ends.
ClientStack never moves money. No refund, capture or charge happens inside it. Your payment system acts on the outcome.
Set up the request type
Start from the Webshop returns template in the Support group, and adapt it.
- Rename the options of the Order request signal to Charged twice, Refund not received and Charge not recognised, and keep Other.
- Rename the outcomes to Sent to payments, Sent to refunds and Sent to card checks.
- Narrow the Individual review signal to fraud. Its question asks whether the customer says that someone else used the card or placed the order.
An owner creates a team token with the runs:write and runs:read abilities on the API tokens screen.
Collect enough detail
Your system knows the order reference and the amount. Have your server answer those follow-up questions from the order. Delete the questions about the return window and the item's condition. Remove their conditions from Hand off when, and change Complete when so it waits only for the order reference and the order value. Checks lists any rule that still names a deleted question. The run hands off when your integration cannot answer a question.
Show why the request ended
| Outcome | Outcome reply |
|---|---|
| Sent to payments (renamed) | Yes |
| Sent to refunds (renamed) | Yes |
| Sent to card checks (renamed) | Yes |
| Needs a person | No |
A fraud claim hands off. Your system reads the outcome's Key through the API and decides what to do. The API also returns the outcome reply, which your system can show to the customer. The API guide names each field.
Test before publication
Add examples for a double charge, a missing refund, an unknown charge and a fraud claim. The fraud claim expects Needs a person. Add one that says “This is not fraud” and then describes a stranger's order. Select Replay and Publish. Then start a test request with your token against the published version.
