Tesco Refund Orders
Version | Date | Created / Updated | Notes |
---|---|---|---|
v1.0 | Hristiyan Georgiev | Initial version |
There are two types of seller initiated refunds on Tesco - pre-shipment (cancellations) and post-shipment (returns). In terms of payloads and calls we will use the same call for both types of refunds, the differences are mentioned below.
Currently, we will support only full line item refunds, which means we do not accommodate partial quantity refunds. For example, if an order contains a product with a quantity of 2, we can refund one quantity, but we cannot refund a partial cost of a single item.
All triggers, validations etc. are as per abstraction - Refunds send general logic
GraphQL Query :
mutation RefundRequestCreate ($input: RefundRequestCreateMutationInput!){
refundRequestCreate(
input: $input
) {
refundRequest {
id
status
}
errors {
field
messages
}
}
}
Query Variables :
{
"input": {
"invoiceId": "SW52b2ljZS0xMzkxOA==",
"lineItems": [
{
"lineItemId": "TGluZUl0ZW0tNDMzMA==",
"reason": "Buyer changed their mind",
"quantity": 1,
"status": "REFUND_ACCEPTED",
"dispatched": false
}
],
"notes": [
{
"note": "Change of mind within T&Cs"
}
]
}
}
Variables Mapping :
Integration Field | Hemi Field | Notes | ||
---|---|---|---|---|
input |
||||
invoiceId |
Orders > Marketplace Order ID |
|||
lineItems |
||||
lineItemId |
Product in Order > Item Order Line ID |
|||
reason |
Order Payment > Reason |
This is a free text reason. This is a required field so if it is empty, we send a hardcoded reason of “Seller initiated refund”, otherwise we send whats filled in Order Payment > Reason |
||
quantity |
We need to calculate this since we do not do refunds based on quantity in Hemi. This would be the count of Order Refund Row Line records |
|||
status |
Hardcoded as “REFUND_ACCEPTED” | |||
dispatched |
We need a logic here and if the items we are refunding are shipped we need to send dispatched = true. |
|||
If the items we are refunding are not shipped, we send dispatched = false. |
||||
notes |
||||
note |
We need to create a logic : If we have Order Payment > Refund Note filled in, we pick from there. Otherwise we send hardcoded as “Change of mind within T&Cs” |
Example success response :
{
"data": {
"refundRequestCreate": {
"refundRequest": {
"id": "UmVmdW5kUmVxdWVzdC02OTY=",
"status": "PROCESSED"
},
"errors": null
}
}
}
Example error response :
{
"data": {
"refundRequestCreate": {
"refundRequest": null,
"errors": [
{
"field": "refund_request_line_items.quantity",
"messages": [
"All available line items have been associated to a refund request"
]
},
{
"field": "lineItems",
"messages": [
"line items must all be refundable in the requested quantity."
]
}
]
}
}
}
Response Mapping :
Integration Field | Hemi Field | Notes | ||||
---|---|---|---|---|---|---|
data |
||||||
refundRequestCreate |
||||||
refundRequest |
||||||
id |
Order Payment > Transaction ID |
|||||
status |
N/A | |||||
errors |
||||||
field |
||||||
messages |
We store the error in the Order Error table with Type = Refund Send |