Retourgegevens tussen webshop, ERP en betaalsysteem koppelen

Bij het koppelen van webshop, ERP en betaaldienst heeft een retour meer nodig dan één gezamenlijk veld «klaar». De integratie moet herkennen welke regel terugkomt, wat er met de voorraad gebeurt en welke status de bijbehorende terugbetaling heeft. Leg deze relaties vast voordat u de koppelingen bouwt.

Een volledige situatie koppelen

Een fictieve webshop voor woonaccessoires heeft met bestelling O-86 twee vazen geleverd en betaling ontvangen. Eén vaas komt terug met een beschadigde rand. In dit voorbeeld is voor die vaas een terugbetaling van 24 EUR afgesproken. Het team plant de volgende koppeling:

De koppeling gebruikt regel- en transactiereferenties. Alleen dezelfde productnaam of artikelcode is onvoldoende wanneer hetzelfde artikel in meerdere bestellingen voorkomt.

Een intern integratiemodel vastleggen

Het volgende record is een eigen ontwerp voor deze fictieve situatie, geen API-aanroep van een aanbieder. De hoeveelheden horen bij de retour; het bedrag staat in EUR-centen.

{
  "returnId": "R-86",
  "orderReference": "O-86",
  "shopOrderLine": "OL-86-A",
  "shopFulfillmentLine": "FL-86-A",
  "erpDeliveryLine": "DL-86-A",
  "receivedQuantity": 1,
  "saleableStockDelta": 0,
  "refund": {
    "paymentReference": "PAY-86",
    "amountMinor": 2400,
    "currency": "EUR",
    "state": "requested"
  }
}

De referenties verbinden de webshoporderregel, de webshopleverregel en de oorspronkelijke ERP-leverregel met de betaling. Sla ook de terugbetalingsreferentie van de betaaldienst bij de retour op. Is de regel niet eenduidig te koppelen, dan moet het record wachten op opheldering in plaats van automatisch via naamvergelijking te worden geboekt.

Voor elke wijziging de juiste bron gebruiken

In dit voorbeeld levert de webshop de relatie met de gekochte regel. Het ERP bevestigt ontvangst, controle-uitkomst en voorraadvrijgave. De betaaldienst levert de terugbetalingsstatus. Deze verantwoordelijkheden staan in het datacontract; een andere taakverdeling tussen systemen kan andere toewijzingen vereisen.

Shopify’s ReturnLineItem verwijst naar een Shopify-leverregel; de integratie moet de koppeling met de ERP-regel leggen. De documentatie van Refund vermeldt uitdrukkelijk dat een record op zichzelf geen geslaagde geldbeweging bevestigt. Ook Stripe beschrijft aparte gebeurtenissen voor aanmaken, wijzigen en mislukken. De integratie moet de werkelijke statussen van de gekozen aanbieder op het interne model afbeelden.

Een geslaagde terugbetaling mag in dit voorbeeld daarom alleen de betaalstatus wijzigen. Ze maakt de beschadigde vaas niet verkoopbaar. Omgekeerd maakt goederenontvangst de terugbetaling niet automatisch succesvol.

Het verwachte resultaat controleren

Controleer de situatie in een geschikte testomgeving: de deelretour hoort bij de juiste regel, de voorraadwijziging blijft 0 en 2400 cent hoort bij de juiste betaling. Na bevestiging van een geslaagde terugbetaling wijzigt de status daarvan, terwijl de goederen geblokkeerd blijven. Een onduidelijk betaalantwoord moet zichtbaar blijven als onopgelost. Een herhaald statusbericht moet dezelfde retour bijwerken. Voor de technische afhandeling van herhaalde pogingen is ook een passende idempotentiestrategie nodig.

Bronnen

• Shopify — ReturnLineItem, GraphQL Admin API

• Shopify — Refund, GraphQL Admin API

• Stripe — Refund and cancel payments