Checkout for nettbutikk: planlegg hele betalingsløpet

Lås grunnlaget for den konkrete bestillingen

Definer hva som skal være fastlagt før betalingsløpet starter: ordren, beløpet, valutaen og den relevante tilgangen. Serveren bør kontrollere opplysningene ut fra bedriftens bestilling. Nettleserens visning alene bør ikke bestemme sluttbeløpet. Tenk gjennom en kunde som åpner checkout og deretter endrer bestillingen i en annen fane. Den gamle betalingen må ikke ukritisk brukes for det nye innholdet. Beskriv om endringen krever en ny betalingsoperasjon og hvordan den tidligere håndteres. En enkel regel tidlig i arbeidet gjør det lettere for både utvikleren og kundeservice å forstå hvorfor to betalingsforsøk eventuelt finnes på samme ordre.

Driftet betalingsside

Gjør overgangen til betalingsleverandøren tydelig

Kunden skal kunne kjenne igjen bedriften og forstå hvor betalingen foregår. Vis relevante ordreopplysninger og samme beløp og valuta gjennom løpet. Prøv teksten på en mobiltelefon, og kontroller at viktige beskjeder ikke forsvinner under lange forklaringer. Stripe beskriver ulike Checkout-grensesnitt i sin dokumentasjon; den konkrete løsningen avhenger likevel av produktet og integrasjonen som velges. I OrsunPays hostede betalingsløp legges sensitive kortopplysninger inn hos betalingsleverandøren. Beskriv dette faktiske løpet i kravene. Ikke anta at alle tilpasninger eller betalingsmåter fra leverandørens øvrige produkter følger med samme forbindelse eller automatisk blir tilgjengelige i butikken.

Signerte betalingsvarsler

Vurder betalingsmåtene for riktig konto

Skriv opp marked, valuta, leverandørkonto og ønsket betalingsmåte for hver salgssituasjon. Bekreft kombinasjonene før logoer eller løfter publiseres. En leverandør kan tilby en metode generelt uten at den er aktivert for den aktuelle bedriften eller integrasjonen. Vurder også hva kunden skal se dersom en metode mangler. Kunden trenger et forståelig neste steg, ikke en uventet blindvei. Start med de metodene bedriften faktisk trenger og har fått bekreftet. Flere alternativer er ikke automatisk bedre dersom oppsettet blir vanskelig å drifte. Gi en medarbeider ansvar for å holde oversikten oppdatert når konto, valuta eller leverandørkonfigurasjon endres.

Skill kundens returside fra ordrebekreftelsen

En returside gir kunden informasjon etter betalingsforsøket. Serverens verifiserte betalingsstatus avgjør hva bedriften kan gjøre med ordren. Disse opplysningene kan komme på ulike tidspunkter. Kunden kan komme tilbake før behandlingen er ferdig eller lukke nettleseren uten å besøke retursiden. Bruk derfor en egnet ventemelding når resultatet ikke er avklart. Signerte webhooks kan knytte senere endringer til ordreprosessen, men mottakeren må kontrollere og behandle hendelsene riktig. Unngå at en adresse med et positivt navn automatisk utløser levering. Den interne ordren skal kunne bli korrekt oppdatert også når kunden aldri åpner bekreftelsessiden igjen.

Planlegg avbrudd uten blinde nye betalinger

Gå gjennom et nettverksbrudd etter at kunden har startet betalingen. Hva ser kunden, hva kan support finne, og hvem undersøker resultatet? Beskjeden bør ikke automatisk be om en ny betaling når utfallet fortsatt er ukjent. Finn først den opprinnelige operasjonen. Vurder også en kunde som vender tilbake senere eller trykker på knappen flere ganger. En ny ordre, et nytt forsøk og en gjentatt forespørsel er ikke det samme. Den ansvarlige medarbeideren må kunne skille dem ved hjelp av referanser og verifisert status. Dokumenter det tillatte neste steget for hvert tilfelle, slik at løsningen ikke avhenger av hva kunden tilfeldigvis husker fra skjermen.

Avgrens leveransen og følg opp reelle problemer

OrsunPay kobler bestillingen til konfigurerte leverandører og tilgjengelige betalingsmåter. Bedriften beholder leverandøravtalene sine, og leverandøren står for behandling og oppgjør. Hosted checkout er ikke i seg selv et lager-, frakt- eller abonnementssystem. Avklar derfor hva integrasjonen skal levere tilbake til resten av virksomheten. Etter oppstart bør teamet undersøke om bekreftede betalinger fører til riktig ordrebehandling, og om kunder forstår ventetid eller avbrudd. Bruk nødvendige driftsopplysninger uten å samle kortdata i egne logger. Forbedre konkrete problemer, som uklare beskjeder eller manglende ordrehenvisning, før flere funksjoner legges oppå en prosess som ennå ikke er godt forstått.

Kilder

• Stripe Checkout
• Stripe Webhooks