ReBOUND Returns integration for ecommerce fulfilment

ReBOUND uses your configured carrier contracts, weight bands and destination zones to select the lowest-cost carrier that meets your service level. You must map your carrier agreements (FedEx, UPS, DHL, etc.) and weight thresholds into ReBOUND. If no carrier is configured for a return, the integration will either use a default (usually higher cost) or fail, requiring manual escalation.

If the label is not delivered to the shopper (email bounce, SMS failure, platform outage), the return request stays in ReBOUND pending label delivery. The integration should monitor for stalled labels and alert operations so you can resend or escalate. Without monitoring, the return lingers unshipped and refund is delayed.

When the warehouse scans the returned item in your WMS, that receipt event is sent to ReBOUND (via integration polling or event push). ReBOUND compares the item condition against your refund rules. If approved, ReBOUND signals refund authorisation back to your commerce platform and ERP. Your payment provider then executes the actual reversal.

Yes. If warehouse condition assessment finds damage, missing parts or wear that violates your refund policy, that condition is recorded in ReBOUND. Your refund eligibility rules (configured during integration) determine if the item is refundable. If denied, ReBOUND holds refund processing and notifies the shopper of the rejection. You must have clear communication set up for rejections.

ReBOUND can be configured with multiple return addresses and routing rules, but this requires explicit setup. Without multi-warehouse configuration, all returns route to a single default address. If you want returns to go to the nearest warehouse or a specific 3PL based on region or product, you must design that logic in the integration.

ReBOUND signals refund authorisation to your ERP and commerce platform, but does not directly call your payment provider (Stripe, Adyen, etc.). Your commerce platform or a separate payment integration must execute the actual refund capture. The integration layer must map ReBOUND authorisation to payment provider settlement IDs so accounting teams can reconcile without gaps.

Yes, but each channel must be mapped and configured. iWeb builds channel adapters so return requests from Shopify, Amazon, eBay, Adobe Commerce or your own storefront all translate into ReBOUND RMA format. Without this mapping, returns from secondary channels may be lost or routed incorrectly.

Carrier tracking can stall if the label is damaged, misrouted or the scan event does not reach ReBOUND. The integration should monitor tracking updates and alert operations if no movement is recorded for N hours. Without alerting, you do not know if the item is lost or just delayed, and the shopper remains in limbo.

ReBOUND does not enforce return windows itself. Your commerce platform must check return eligibility (30 days from purchase, etc.) before the return request is sent to ReBOUND. If a return slips past the cutoff, it may still generate an RMA in ReBOUND unless your storefront logic blocks it. You must enforce windows at the source (commerce platform) to avoid processing ineligible returns.

ReBOUND tracks labels generated, carrier used and cost for each return. The integration should expose these metrics in dashboards so you can monitor total return shipping spend, carrier cost per return and delivery performance. Without visibility, you cannot optimise carrier selection or identify cost outliers.

This is a reconciliation gap. ReBOUND may record the refund as authorised, but if the payment provider fails to capture the reversal (due to connectivity, expired card token, or provider outage), the shopper does not get credit. Your integration must monitor both ReBOUND authorisation and payment provider settlement completion, and escalate if they diverge.

When the warehouse scans the returned item, the WMS records a stock receipt. That event is sent to ReBOUND (to update refund eligibility) and to your ERP (to correct inventory counts). If the warehouse does not scan the return, stock is not corrected and inventory remains understated. Integration must verify warehouse scanning is happening before relying on ReBOUND refund signals.

Yes. Return reason codes (defective, unwanted, wrong size, etc.) are configurable in ReBOUND and typically map back to your commerce platform for reporting. Refund rules (full refund, restocking fee, no refund) are also configurable but must align with your policy and be enforced at the warehouse or integration layer. Without alignment, some shoppers may be eligible for refunds they should not receive.

This is a manual exception. ReBOUND does not approve refunds until warehouse receipt is confirmed. If you need to issue a goodwill refund before the return is received, that is handled outside ReBOUND (through your payment provider directly) and creates a reconciliation challenge. Your integration should flag such cases so finance can track them separately.