Payment orchestration: wanneer een gezamenlijke laag helpt

Zoek naar dubbel werk in de bestaande toepassing

Stel dat twee webwinkels verschillende PSP-accounts gebruiken en hun medewerkers andere schermen nodig hebben om een bestelling te onderzoeken. Schrijf op welke gegevens en beslissingen telkens opnieuw worden verwerkt. Kijk niet alleen naar de eerste integratie, maar ook naar storingen, wijzigingen en dagelijks zoeken. Daarmee wordt zichtbaar welk probleem een gezamenlijke laag moet oplossen. Eén stabiele verbinding met een helder proces heeft misschien geen extra component nodig. De architectuur moet voortkomen uit aantoonbaar werk, niet alleen uit belangstelling voor een nieuw technisch begrip.

Payment orchestration met één API

Verdeel verantwoordelijkheden tussen de partijen

Je toepassing beheert de bestelling. De PSP verwerkt betalingen en rekent af volgens je eigen overeenkomst. OrsunPay verbindt geconfigureerde PSP-accounts via een gezamenlijke API, consistente statussen en ondertekende meldingen. Accounts en overeenkomsten blijven van jouw onderneming; de softwarekosten worden afzonderlijk gefactureerd. Beschrijf deze taakverdeling voor ontwikkeling en support. Een orchestrationlaag vervangt geen acceptatie door een PSP en neemt diens voorwaarden niet over. Ook de beschikbaarheid van een specifieke betaalmethode blijft afhankelijk van de betreffende verbinding en het account.

Integratie en API

Beoordeel iedere verbinding afzonderlijk

Een lijst met aanbieders vormt het begin van onderzoek, geen volledige garantie voor je gebruikssituatie. Controleer per verbinding het account, de markt, de valuta en de functies die je nodig hebt. Vraag om een bevestiging van de beperkingen en bewaar die bij het integratieplan. Een naam op de lijst is geen aanbeveling en betekent niet dat de volledige productcatalogus van die aanbieder wordt ondersteund. Leg in de toepassing vast welke verbinding een transactie heeft verwerkt, zodat een latere vraag bij de juiste partij terechtkomt.

Gehoste betaalpagina

Maak van gezamenlijke statussen duidelijke beslissingen

Een uniforme status helpt pas wanneer je toepassing weet wat daarmee moet gebeuren. Bepaal welk gecontroleerd resultaat verzending of activering toestaat en wanneer een bestelling op onderzoek wacht. De terugkeer van de browser is geen zelfstandig betaalbewijs. Stripe en Mollie beschrijven de rol van servermeldingen en statusverwerking in hun documentatie. Ook achter een gezamenlijke laag moeten herhaalde of late gebeurtenissen goed worden verwerkt. Hetzelfde succes mag niet tweemaal leveren en een onbekend resultaat mag niet zomaar worden vertaald naar mislukt.

Veronderstel geen automatische cascade

OrsunPay gebruikt momenteel de ingestelde verbinding of de geschikte methoden in de gehoste checkout. Automatische cascades en selectie op de laagste kosten zijn geen onderdeel van het huidige aanbod. De geplande Smart Routing-functie is daarom geen basis voor een besparingsberekening vandaag. Een nieuwe betaalpoging bij een ander bedrijf is ook geen vanzelfsprekende reactie op een onbekende uitkomst. Vraag bij iedere vergelijking welke selectieregels echt bestaan en wie ze beheert. Beloof geen hogere acceptatie op grond van alleen de term orchestration.

Weeg het voordeel af tegen extra beheer

Vergelijk het vereenvoudigde integratie- en supportwerk met softwarekosten en het beheer van een extra koppeling. Een introductie kan beginnen met een afgesproken, beperkt deel van de bestellingen. Houd oude referenties beschikbaar en bepaal wie verschillen onderzoekt. Het nuttige resultaat is dat medewerkers echte taken beter kunnen uitvoeren en een incident kunnen uitleggen. Meet daarom het proces dat je wilt verbeteren. Het aantal aangesloten logo’s of een algemene belofte over omzet zegt weinig als de toepassing nog steeds onduidelijke bestellingen produceert.

• Benoem dubbel werk met concrete voorbeelden.
• Leg de verantwoordelijkheid van toepassing, OrsunPay en PSP vast.
• Bevestig het bereik van iedere verbinding.
• Oefen dubbele meldingen en onbekende resultaten.
• Laat geplande routing buiten de huidige functionaliteitsbelofte.

Bronnen

• Stripe-documentatie over webhooks
• Mollie-documentatie over betalingen