Fruugo Refund Orders

Summary of Changes: (The purpose of this table is to keep traceability and Product team to highlight the things that were changed into the scope, based on comments or discussions)

Fruugo allows us to either cancel or return an order and this can be done on line level. So in this document we will describe both cases and when/what should be used. Partial refunds are only allowed on the whole line and we cannot refund partial amount of the item(s) cost.

Both requests will again use Web Hooks so it is all the same as all other calls.

Order Cancel

API Docs : https://developer.fruugo.com/#tag/orders-v3/operation/cancelOrders API Call : POST https://order-api.fruugo.com/v3/orders/cancel

Example request :

{
  "orders": [
    {
      "type": "cancel",
      "orderId": "string",
      "itemQuantities": [
        {
          "productId": "string",
          "skuId": "string",
          "quantity": 1
        }
      ],
      "messageToCustomer": "string",
      "messageToFruugo": "string",
      "cancellationReason": "out_of_stock"
    }
  ]
}

Request mapping :

Valid values are: • out_of_stock • product_discontinued • invalid_delivery_address • customer_cancellation • legislation_restriction • other These should be added as enums in the Order Refund Reasons table with label [CANCELATION]. |

Since partial and full cancellations are allowed with the same call, we need to create internal logic :

• If we are sending a full cancellation, we will only use the fields marked as Required in the above table (only orderId and cancellationReason) .
• If we are sending partial cancellation we need to send the items that are being cancelled and include them in the payload.

Example responses :

202 Request has been accepted for processing, and update will be performed asynchronously.

This is the successful request. We should then expect a response from Fruugo via the web-hook endpoint that we have provided.

400 Bad Request

Example response :

[
  {
    "type": "field",
    "field": "productId",
    "message": "must not be null"
  },
  {
    "type": "field",
    "field": "skuIds",
    "message": "size must be between 1 and 200"
  }
]

This bad request should not happen but incase it happens we should store all errors in Order Errors with type Order Acknowledge.

429 Request has been rejected due to exceeding rate limit. Retry after delay specified in "Retry-After" response header.

Incase we receive this we should just retry the request after the specified “Retry-After” in the header.

Callback payload sample :

{
  "value": {
    "type": "CancelResponseList",
    "merchantId": 444,
    "correlationId": "c3145570-0731-45db-9c9a-33f97d588400",
    "payload": "Payload: {'transactionType':'cancel','responses':[{'success':false,'errorMessage':'BD_ILLEGAL_FULFILMENT_STATUS_TRANSITION - cancelPurchaseOrder failed, order status is NOT_REPLACED','orderId':'9164260001000444','shipmentId':null,'itemStatuses':null}]}"
  }
}

We want to be looking for the success status in the response :

• If we have success: true we act as per the Refunds send general logic . We don’t seem to be receiving transaction id or anything similar so we will have to leave the transaction id as blank.
• If we have success : false, we want to store the errorMessage in Order Errors with type Order Refundfor the relevant orderId.

Order Return

API Docs : https://developer.fruugo.com/#tag/orders-v3/operation/cancelOrders API Call : https://order-api.fruugo.com/v3/orders/return

Example request :

{
  "orders": [
    {
      "type": "return",
      "orderId": "string",
      "itemQuantities": [
        {
          "productId": "string",
          "skuId": "string",
          "quantity": 1
        }
      ],
      "messageToCustomer": "string",
      "messageToFruugo": "string",
      "returnReason": "unsatisfied_with_item"
    }
  ]
}

The mapping is the same as the Order Cancel with the only difference being the returnReason instead of cancellationReason .

The possible return reasons are :

• unsatisfied_with_item
• item_did_not_match_description
• damaged_item
• wrong_item
• other

These should be added as enums in the Order Refund Reasons table with label [RETURN]

Callback payload sample :

{
  "value": {
    "merchantId": 444,
    "correlationId": "c3145570-0731-45db-9c9a-33f97d588400",
    "payload": "{'transactionType':'return','responses':[{'success':true,'errorMessage':'','orderId':'1','shipmentId':null,'itemStatuses':[{ 'productId': 'STOCK005' 'skuId': 'STOCK-IS-1000-WITHV20' 'quantity': 1 'status': 'RETURNED'}] }]}"
  }
}

We want to be looking for the success status in the response :

• If we have success: true we act as per the Refunds send general logic . We don’t seem to be receiving transaction id or anything similar so we will have to leave the transaction id as blank.
• If we have success : false, we want to store the errorMessage in Order Errors with type Order Refundfor the relevant orderId.

All other triggers and validations are as per the Refunds send general logic