How The Integration Works

outline the integration has two halves raising the return authorisation when the customer lodges, and closing the loop once nri confirms what they received raising the return authorisation when a return is lodged, refundid creates a return authorisation (ra) in nri containing two reference numbers the refundid rma reference and the return id these are what nri quotes back on the confirmation, and what lets refundid match a confirmation to the right return your warehouse and client division codes , and the ra type agreed during setup one line per returned item , with the expected quantity, the item number, the barcode, a line reference and a reason code the return tracking number , recorded as the inbound consignment reference so the warehouse can identify the parcel on arrival comments summarising the return the resolution, the return reason, item title and variant, and the tracking details so warehouse staff have context without needing access to refundid item numbers that don't match your store warehouse item numbers don't always match the skus in your online store where the two differ by a predictable pattern, refundid translates the sku into the warehouse's format before sending it, so your team doesn't have to maintain a mapping table or change skus in your store if a line has neither a usable item number nor a barcode, the return isn't sent and is held for review instead of creating an ra the warehouse can't receive against return reason codes refundid return reasons are mapped to nri reason codes using the mapping agreed at setup, with a default reason code used for anything unmapped new return reasons added later fall back to the default until the mapping is updated duplicate protection every return sent to nri is recorded against a combination of its rma reference and return id if the same return is received again a webhook retry, or a status change that fires twice it's recognised as already sent and skipped, so the warehouse never sees two ras for one parcel watching for the confirmation refundid then checks nri regularly for a return confirmation against those reference numbers until one appears the return stays open and is simply checked again on the next run closing the return once a confirmation is found, refundid reads the received quantities and matches them back to the return's items by line reference first, then barcode, then item number for each item received quantity is accepted , with a note recording how many of the expected quantity arrived any shortfall is cancelled , with a note recording how many were missing so a customer who lodged two items and returned only one is refunded for the one that arrived, and the missing item is cancelled rather than silently refunded or silently ignored the return is then closed in refundid and the resolution processed acknowledging the confirmation after the return is closed, refundid acknowledges the confirmation back to nri so it isn't presented again on the next run returns that had already been closed in refundid processed manually by your team, for example are acknowledged without being closed a second time when something fails each stage records its outcome against the return a failure at any point the ra not posting, the confirmation not mapping to any items, the close not going through is recorded with the error and picked up again on the next run, so a transient outage resolves itself without anyone re sending anything by hand