Wat betaalintegratie inhoudt voorbij de checkout
Het kiezen van een betaalgateway is een beslissing voor de webshop, waarbij de transactie slechts één moment beslaat. De betaalrelatie genereert echter nog wekenlang data, waarbij elk type gegevens een andere bestemming heeft.
- Autorisatie en incasso: de webshop bevestigt dat er voldoende saldo is en incasseert het bedrag, vaak pas bij verzending in plaats van bij de bestelling
- Afwikkeling: de provider bundelt de geïncasseerde betalingen en stort deze, meestal na aftrek van kosten en met enige vertraging
- Terugbetalingen en gedeeltelijke terugbetalingen: geld wordt teruggestort op de oorspronkelijke transactie, soms lang nadat de bestelling is afgerond
- Chargebacks en geschillen: bedragen worden teruggedraaid met een redencode en een deadline voor het aanleveren van bewijslast
- Kosten: per transactie, per betaalmethode en per valuta; dit is wat het bruto- van het nettobedrag onderscheidt
Alleen het eerste punt hoort bij de webshop. De overige vier vallen onder de financiële administratie, en juist die blijven onverwerkt als de betaalprovider alleen aan de checkout is gekoppeld.
Waarom komen afwikkelingen niet meer overeen met het orderboek?
Betaaldienstverleners groeperen hun transacties. Een storting van 48.000 EUR komt niet overeen met één enkele order in het ERP-systeem. Het is het resultaat van honderden transacties over twee dagen, minus kosten, minus drie terugbetalingen, plus één teruggedraaide stornering van de vorige maand.
Meerdere betaalmethoden vergroten het probleem. Kaartbetalingen worden volgens een ander schema afgewikkeld dan automatische incasso's of 'buy-now-pay-later'-diensten, elk met hun eigen kostenstructuur en rapportageformaat. Een bedrijf dat vier methoden gebruikt, moet vier afzonderlijke geldstromen afstemmen op één orderboek.
Valuta vormt de laatste laag. Een betaling die in de ene valuta wordt ontvangen en in een andere wordt afgewikkeld, zorgt voor een wisselkoersverschil dat niet in het ERP was berekend. Hierdoor wijkt het bedrag in de orderadministratie af van het daadwerkelijk ontvangen bedrag.
Wat een gebrekkige betaalintegratie kost
Niemand trekt aan de bel als een afwikkeling niet overeenkomt met een order. De kosten stapelen zich stilletjes op en komen in deze volgorde aan het licht:
- Maandafsluiting die uitloopt: De financiële afdeling koppelt afwikkelingen handmatig aan orders in een spreadsheet, waardoor de sluitingsdatum afhangt van het aantal uitzonderingen.
- Omzet die te laat wordt verantwoord: orders blijven ongekoppeld, waardoor de gerapporteerde omzet achterloopt op de werkelijke handel, afhankelijk van hoe lang het afstemmingsproces duurt.
- Winstgevendheid per kanaal is giswerk: omdat betaalkosten niet per order worden toegewezen, is de marge per kanaal en per product slechts een schatting.
- Terugbetalingen die dubbel worden uitgevoerd: wanneer het betalingssysteem en het ERP-systeem niet op één lijn zitten over de status van een terugbetaling, verwerkt de klantenservice er per ongeluk een tweede.
- Disputen verloren door gemiste deadlines: Bewijsmateriaal voor storneringen is verspreid over de webshop, het magazijn en het portaal van de betaaldienstverlener, waardoor de termijn vaak verstrijkt voordat alles is verzameld.
Betaalintegratie voor een composable stack
Vroeger werkten bedrijven met één betaaldienstverlener op één platform, waarbij de standaard plug-in van de aanbieder het meeste werk deed. Die situatie is tegenwoordig zeldzaam. Een gemiddelde retailer in het middensegment gebruikt een primaire betaalprovider, een regionale methode voor een specifieke markt, een optie voor facturatie of BNPL, en een marktplaats met een eigen betaalstroom.
Essentiel Antwerp is een Belgisch luxemerk dat internationaal verkoopt via fysieke winkels en online. Met het integratieplatform-as-a-service (iPaaS) van Alumio bouwden ze een composable stack in plaats van één enkel pakket, waarbij ze Microsoft Dynamics 365 Business Central gebruiken voor de financiën, Adobe Commerce voor de webshop, Channable voor marketing en Adyen voor betalingen.
Het relevante punt voor de afstemming is wat die architectuur aan de achterkant vereist. Wanneer betalingen, bestellingen en financiële gegevens in drie afzonderlijk gekozen systemen staan, moet de verbinding daartussen worden beheerd in plaats van als vanzelfsprekend worden beschouwd, omdat geen enkele leverancier beide kanten van de koppeling in beheer heeft.
Hoe een integratieplatform betalingen verbindt met het ERP
Een storting opsplitsen in de individuele betalingen waaruit deze bestaat, is slechts de eerste vereiste. Elke betaling moet worden voorzien van de bijbehorende kosten en het orderreferentienummer, zodat het ERP deze aan het juiste document kan koppelen. Dat werk vereist een laag die tussen de betaalprovider en de financiële systemen in zit. Een speciale tool voor afstemming voert de matching goed uit, maar moet nog steeds vanuit beide kanten worden gevoed. Plugins van providers reiken niet zo ver.
Het Alumio iPaaS bevindt zich in die positie en verbindt de betaalprovider met de systemen die de geldstromen verwerken. Dat werk neemt vier vormen aan:
- Afwikkelingen uitgesplitst: een data Transformer splitst een gebundelde storting in de onderliggende transacties en koppelt elke transactie aan de bijbehorende orderreferentie, zodat het ERP details op regelniveau ontvangt in plaats van een totaalbedrag
- Kosten toegewezen per order: een data Mapper koppelt elke transactiekost aan de order die deze heeft veroorzaakt, zodat de marge per kanaal een exact cijfer is in plaats van een schatting
- Terugbetalingen in één richting: een data Route verwerkt een terugbetaling zodra deze wordt uitgegeven, waarbij zowel de betaalprovider als het ERP worden bereikt, zodat er geen onduidelijkheid kan ontstaan over de status ervan
- Bewijslast op één plek: gedetailleerde Logs houden de order-, leverings- en betalingsgegevens van een betwiste transactie bij elkaar, zodat reacties op chargebacks tijdig kunnen worden ingediend
Deze stromen worden geconfigureerd in plaats van per provider handmatig gebouwd, waarbij de Code Transformer beschikbaar is voor situaties waarin configuratie niet volstaat en het schrijven van code de voorkeur heeft. Bij het toevoegen van een betaalmethode wordt de reeds actieve afstemmingslogica hergebruikt.
Wat een verbonden betalingsintegratie oplevert
De echte test voor een betalingsintegratie is niet of de checkout converteert. Het is of de financiële afdeling de maand kan afsluiten zonder spreadsheets en of iemand de marge op een order na aftrek van kosten kan bepalen.
Bedrijven die dit goed aanpakken, stoppen met het zien van betaalproviders als een keuze voor de webshop en beginnen ze te zien als een financiële beslissing. Via een integratieplatform wordt het toevoegen van een regionale betaalmethode een commerciële keuze in plaats van een afstemmingsprobleem; dit is cruciaal bij het betreden van een markt waar lokale betaalmethoden de conversie bepalen.
Wat het bedrijf terugkrijgt, is een maandafsluiting die niet afhankelijk is van handmatige matching, omzet die wordt geteld wanneer deze is verdiend in plaats van wanneer deze is gematcht, en een helder inzicht in wat elk kanaal oplevert na aftrek van kosten.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
