Vad betalningsintegration omfattar bortom kassan
Att välja en betalväxel är ett beslut för webbutiken, och transaktionen den hanterar är ett enskilt ögonblick. Betalningsrelationen genererar data i veckor efteråt, och varje typ har en specifik destination.
- Auktorisering och dragning: webbutiken bekräftar att medel finns tillgängliga och drar sedan beloppet, ofta vid leverans snarare än vid ordertillfället
- Avräkning: leverantören samlar dragna betalningar i batchar och sätter in dem, vanligtvis netto efter avgifter och med viss fördröjning
- Återbetalningar och delåterbetalningar: pengar återförs mot en ursprunglig transaktion, ibland långt efter att ordern avslutats
- Reklamationer och tvister: medel återförs med en orsakskod och en tidsfrist för att inkomma med bevis
- Avgifter: per transaktion, per metod och per valuta, vilket är det som skiljer brutto från netto
Endast den första punkten hör hemma i webbutiken. De övriga fyra tillhör ekonomiavdelningen, och det är dessa som hamnar i ett vakuum om betalväxeln bara är kopplad till kassan och ingen annanstans.
Varför stämmer inte avräkningar överens med orderboken?
Betalningsleverantörer samlar sina transaktioner i batchar. En insättning på 48 000 EUR motsvarar inte en enskild order i affärssystemet. Den motsvarar flera hundra transaktioner utspridda över två dagar, minus avgifter, minus tre återbetalningar, plus en återföring av en reklamation från föregående månad.
Flera betalningsmetoder gör problemet ännu mer komplext. Kortbetalningar avräknas enligt ett schema, autogiro enligt ett annat och köp-nu-betala-sen-leverantörer enligt ett tredje, alla med sina egna avgiftsstrukturer och rapportformat. Ett företag som använder fyra metoder måste stämma av fyra separata flöden mot en och samma orderbok.
Valuta är den sista pusselbiten. En betalning som tas emot i en valuta och avräknas i en annan innebär en växlingskurs som affärssystemet inte har räknat med, vilket gör att det bokförda beloppet för ordern och det faktiska mottagna beloppet skiljer sig åt på ett sätt som ingen förutsett.
Vad bristfällig betalningsintegration kostar
Ingen skapar ett ärende när en avräkning inte stämmer överens med en order. Kostnaderna ackumuleras istället i det tysta och visar sig i följande ordning:
- Månadsbokslut som drar ut på tiden: Ekonomiavdelningen stämmer av avräkningar mot ordrar manuellt i kalkylark, och bokslutsdatumet beror på hur många avvikelser som dyker upp.
- Intäkter som redovisas sent: ordrar förblir oavstämda, vilket gör att de redovisade intäkterna släpar efter den faktiska försäljningen beroende på hur lång tid avstämningen tar.
- Lönsamhet per kanal som bygger på gissningar: betalningsavgifter fördelas inte per order, så marginalen per kanal och produkt är bara en uppskattning.
- Återbetalningar som sker dubbelt: när betalningssystemet och affärssystemet inte är överens om huruvida en återbetalning har genomförts, utfärdar kundtjänst en till.
- Förlorade tvister på grund av tidsbrist: Bevisunderlag för reklamationer finns utspridda mellan butikssystemet, lagret och leverantörsportalen, och tidsfristen löper ut innan någon hunnit sammanställa dem.
Betalningsintegration för en komponerbar stack
Förr använde företag en betalningsleverantör mot en plattform, och leverantörens egen plugin täckte det mesta. Det upplägget är ovanligt idag. En typisk medelstor återförsäljare använder en huvudleverantör, en regional metod för en specifik marknad, ett alternativ för faktura eller köp-nu-betala-sen, samt en marknadsplats med ett eget betalningsflöde.
Essentiel Antwerp är ett belgiskt lyxmodemärke som säljer internationellt via fysiska butiker och online. Genom att använda integrationsplattformen Alumio (iPaaS) har de byggt en komponerbar stack istället för en enhetlig svit, där de kör Microsoft Dynamics 365 Business Central för ekonomi, Adobe Commerce för butiken, Channable för marknadsföring och Adyen för betalningar.
Det relevanta för avstämning är vad den arkitekturen kräver i grunden. När betalningar, ordrar och finansiella poster finns i tre separat valda system måste kopplingen mellan dem styras snarare än tas för given, eftersom ingen leverantör äger båda ändarna.
Hur en integrationsplattform kopplar samman betalningar med affärssystemet
Att dela upp en insättning i de betalningar som utgör den är bara det första steget. Varje betalning behöver sin avgift kopplad till sig och sin orderreferens medföljande, så att affärssystemet kan bokföra den mot rätt dokument. Det arbetet kräver ett lager som ligger mellan betalningsleverantören och ekonomisystemen. Ett dedikerat avstämningsverktyg sköter matchningen väl, men måste fortfarande matas från båda håll. Leverantörernas egna insticksprogram räcker inte så långt.
Alumio iPaaS har den positionen och kopplar samman betalningsleverantören med de system som hanterar pengarna. Det arbetet tar fyra former:
- Avräkningar uppdelade: en datatransformator delar upp en samlad insättning i dess underliggande transaktioner och kopplar varje transaktion till dess orderreferens, så att affärssystemet får detaljer på radnivå istället för en klumpsumma
- Avgifter fördelade per order: en datamappare kopplar varje transaktionskostnad till den order som orsakade den, så att marginalen per kanal blir en exakt siffra istället för en uppskattning
- Återbetalningar i en riktning: en datarutt förmedlar en återbetalning i samma ögonblick som den utfärdas, till både betalningsleverantören och affärssystemet, så att de två inte kan vara oense om huruvida den har skett
- Bevis på ett ställe: detaljerade loggar håller samman order-, leverans- och betalningsuppgifter för en tvistig transaktion, så att svar på återkrav hinner skickas i tid
Dessa flöden konfigureras snarare än byggs för hand för varje leverantör, med en kodtransformator tillgänglig där konfiguration inte räcker till och kodskrivning föredras. Att lägga till en betalningsmetod innebär att man återanvänder den avstämningslogik som redan körs.
Vad en sammankopplad betalningsintegration ger
Testet för en betalningsintegration är inte om kassan konverterar. Det är om ekonomiavdelningen kan stänga månaden utan kalkylblad, och om någon kan fastställa marginalen på en order efter avgifter.
Företag som gör detta rätt slutar behandla betalningsleverantörer som ett beslut för butiken och börjar behandla dem som ett ekonomiskt beslut. Genom att köra via en integrationsplattform blir tillägget av en regional betalningsmetod ett kommersiellt val snarare än ett avstämningsproblem, vilket är avgörande när man går in på en marknad där lokala metoder avgör konverteringen.
Vad företaget får tillbaka är ett månadsbokslut som inte är beroende av manuell matchning, intäkter som räknas när de tjänas in snarare än när de matchas, och en tydlig bild av vad varje kanal genererar efter avgifter.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
