Test og feilretting av billettintegrasjoner
En grønn overføring er ikke nok. Resultatet må kunne avstemmes også når meldingen kommer to ganger.
Start med et feltkart og en eier for hver økonomisk hendelse. En ordre, en betaling og et bankoppgjør er forskjellige objekter selv om alle viser samme beløp i et enkelt testkjøp. Stabile referanser må overleve eksport, korreksjon og nytt forsøk.
Hva skal koblingen faktisk gjøre?
Avklar om løsningen bare flytter rapporter, oppretter dokumenter eller også utfører betaling/refusjon. Det siste krever strengere kontroll av utfallet før nye forsøk. Et dokumentert filimportløp kan være tilstrekkelig; et API er ingen garanti for automatisk avstemming.
| Test | Det dere må kunne vise |
|---|---|
| Samme fil importeres to ganger | Ingen doble økonomiske poster |
| Én del av en ordre refunderes | Korrekt opprinnelig del og referanse beholdes |
| Hendelser kommer i feil rekkefølge | Avvik holdes åpent fremfor å lage et nytt salg |
| Nettverket brytes etter innsending | Ukjent utfall kontrolleres før ny økonomisk handling |
| Et felt endres i leverandørens eksport | Importen stopper eller varsler forståelig, uten skjult feiltolking |
Eksempel: ordre-ID og oppgjørs-ID kan ikke byttes om
En fiktiv ordre inneholder tre billetter og betales i én transaksjon. Betalingen inngår senere i et oppgjør med 90 andre betalinger. Hvis oppgjørs-ID brukes som ordre-ID, får mange kjøp samme nøkkel. Hvis hver billett behandles som en ny betaling, kan salget bli tredoblet.
Behold derfor forbindelsen mellom ordre, ordrelinjer, betalingsreferanse og oppgjørsbatch. Et totalbeløp er en kontrollsum, ikke en unik identifikator. Bruk syntetiske kjøp og testkontoer når dere demonstrerer dette.
Avbrudd krever en avklart rutine
Skjermen kan vise feil selv om mottakeren rakk å opprette dokumentet eller sende pengene. Merk hendelsen som uavklart og slå opp hos mottakeren med den opprinnelige referansen. Start først et nytt forsøk når dere har grunnlag for at det er riktig. En ny tilfeldig referanse kan omgå duplikatkontrollen.
Loggen trenger tidspunkt, hendelsestype, referanse og status. Kundens fritekst, hele deltakerlister, betalingskortopplysninger og tilgangsnøkler skal ikke være standard innhold i tekniske feilmeldinger. Gi brukeren en vei til å finne saken uten å vise mer persondata enn nødvendig.
Avtal hva som skal være godkjent før drift
Velg forventede resultater for hvert scenario og la økonomiansvarlig kontrollere dem. Overlever feltkart, avviksrutine, ansvar og en beskrivelse av hva leverandørendringer kan påvirke. Avklar om løpende oppfølging inngår eller må bestilles separat.
Integrasjonstjenesten beskriver hva PAGU kan avtale. Kortoppgjør er en nyttig økonomisk prøve, og tilgang og leverandørbytte avklarer driften etter overlevering.